Hospitals are increasingly under pressure because of the growing volume of imaging tests carried out, but also because of the sophistication of the attacks by the cybercriminal. Conventional security systems are unable to meet today's challenges to patient records and radiological data. In this research, these challenges are addressed directly by designing an advanced defence system that is specifically designed for medical imaging archiving and communication systems in radiology departments. Architected an extensive protective architecture with seven layers that are interconnected. It's a combination of cutting-edge encryption techniques capable of resisting the powerful future quantum computer, authentication processes that validate every access attempt on the fly, data patterns that are learned, suspicious activity recognized, blockchain technology that makes data impossible to tamper with, and predictive algorithms that foresee threats before they happen. Our system is proactive, identifying and neutralising threats at an early stage, instead of reacting to attacks as they happen. Real-world validation took place within five different hospital networks, covering two years, and thus subjected the framework to the real conditions of operation and to real cyber threats. The results of the system's performance were outstanding – the system had a rate of 99.9% accuracy in detecting malicious activities and a rate of 0.15% False Alarms. The overhead for security operations was just 23 milliseconds, not affecting clinical workflow. Most impressively, there was a 67% reduction in the number of attempts to break in onto the network unauthorisedly, due to the formidable defence measures that they faced.Our framework thwarted 847 real tests against it, ranging from sophisticated persistent intrusions and previously unknown software vulnerabilities to attempts by ransomware to encrypt patient information – all during testing. The system ensured complete compliance with healthcare privacy laws from various jurisdictions, aligning with the American HIPAA regulations, the European GDPR and the new quantum-security protocols. In essence, this is a paradigm shift in medical imaging security, offering healthcare institutions proactive and intelligent protection that safeguards patient privacy and institutional integrity in the face of future threats.
Since announcing the implementation of a single electronic health record for all South Africans, the government has not yet informed healthcare facilities of how this would be accomplished. The siloed South African healthcare system would have to be redesigned to accommodate a single electronic health record. A systematic literature review conducted across three databases returned 9 790 results. By applying ten filters, 22 documents were eventually retrieved for analysis. The analysis showed that existing research focuses on healthcare architectures from a theoretical perspective. Therefore, the literature review revealed a practically based research deficiency and a lack of theoretical studies merged with practical cases. Seeking to enhance the understanding of designing a single electronic health record, the documents were analysed using a qualitative inductive content analysis technique, revealing that a single electronic health record cannot be formulated using a fully centralised architecture as this is not practical. A fully decentralised architecture, such as blockchain, is equally infeasible because this requires significant changes to the existing systems and infrastructure and would require re-skilling system builders. Since the South African healthcare architecture is already decentralised, hybrid architecture incorporating edge computing with clusters of systems and information that connect using middleware should be considered.
As autonomous AI agents gain the capacity to execute consequential actions in high-stakes domains -- medical prescribing, financial transactions, critical infrastructure control -- existing authorization mechanisms fail to answer a fundamental question: was the authorizing human genuinely conscious, uncoerced, and cognitively capable at the exact moment of authorization? Passwords, static biometrics, and digital signatures verify identity, not intent state. We present LICET (Latin: it is permitted), a middleware protocol that cryptographically binds AI agent authorization events to the real-time physiological state of the authorizing human via a three-layer architecture: (1) an identity anchor using ECG waveform morphology -- an anatomically determined signal resistant to pharmacological manipulation; (2) a liveness layer using continuous electrodermal activity (EDA) and overnight HRV pattern matching; and (3) a voluntary state layer using personalized Mahalanobis distance fusion across five physiological channels with pharmacological attack pattern detection. LICET additionally provides: per-event session-key derivation via HKDF; a Schnorr zero-knowledge proof over BN128, enabling third-party audit without exposing biometric data; a SHA-256 hash-chained ledger providing tamper-evident authorization records; and a four-level biometric trust hierarchy (L0-L3) aligned with IETF RATS architecture (RFC 9334). The protocol is designed as a coercion cost elevation mechanism: no single pharmacological intervention at survivable doses defeats the multi-signal fusion system. A reference implementation is publicly deployed at https://licet.dev.
Computer System Validation (CSV) has evolved into one of the most critical operational and regulatory disciplines within modern digital enterprises. Organizations operating in highly regulated sectors including pharmaceuticals, biotechnology, healthcare, banking, aerospace, food manufacturing, industrial automation, and medical device production increasingly rely upon computerized systems for managing operational workflows, manufacturing environments, electronic records, laboratory infrastructures, process automation, and compliance documentation. Consequently, ensuring the reliability, integrity, traceability, security, and regulatory compliance of computerized systems has become a mandatory organizational requirement. The rapid expansion of cloud computing, Artificial Intelligence (AI), machine learning, Industrial Internet of Things (IIoT), distributed microservices, DevOps ecosystems, real-time analytics platforms, and blockchain infrastructures has significantly transformed the complexity of validation ecosystems. Traditional validation methodologies based upon static documentation, sequential testing approaches, and manual compliance management are increasingly inadequate for supporting continuously evolving enterprise architectures. Modern organizations require intelligent validation frameworks capable of supporting automated deployment pipelines, continuous compliance monitoring, predictive risk analytics, cybersecurity governance, and autonomous validation operations. This survey paper presents a comprehensive and research-oriented analysis of Computer System Validation including validation lifecycle methodologies, regulatory compliance frameworks, data integrity governance, cybersecurity integration, cloud-native validation systems, AI-assisted validation architectures, automated testing ecosystems, and emerging intelligent compliance technologies. The paper critically examines major challenges including scalability limitations, audit trail management, cloud infrastructure validation, AI explainability, cybersecurity threats, distributed architecture complexity, and validation documentation overload. Furthermore, the paper investigates open research issues involving explainable artificial intelligence, blockchain-enabled audit systems, autonomous validation ecosystems, predictive compliance analytics, quantum-resistant security frameworks, and edge-native validation architectures. Several modern tools and technologies including Apache Hadoop, Apache Spark, Apache Kafka, TensorFlow, Kubernetes, Jenkins, Terraform, Docker, and cloud- native validation platforms are comparatively analyzed with respect to architecture, operational capabilities, advantages, limitations, and industrial applications. Finally, future research directions emphasizing intelligent continuous validation, AI-augmented compliance systems, digital twins, decentralized audit infrastructures, and autonomous quality assurance ecosystems are discussed in detai
Background: Healthcare organizations face unprecedented challenges in maintaining process compliance due to increasingly federated data and systems topologies, coupled with complex state, federal, and jurisdictional regulatory compliance and verification requirements. The emergence of distributed ledger technology (DLT) and artificial intelligence presents both transformative opportunities and significant compliance challenges. These emerging technologies enable computing paradigms that shift toward data locality models where computational models meet the data rather than moving sensitive patient information across organizational boundaries. This computational approach offers innovative pathways to mitigate data breach risks, while simultaneously introducing new verification complexities as the underlying technologies continue to advance: healthcare entities must cryptographically prove that operations performed on locally-held data were executed according to approved specifications while enabling selective disclosure capabilities across entity lines. However, traditional verification mechanisms lack the cryptographic guarantees necessary for these privacy-preserving, multi-entity healthcare workflows, creating substantial risks in clinical decision-making, patient privacy, and regulatory adherence. Objective: This paper introduces the ZK-PRET Business Process Prover framework that integrates Object Management Group (OMG) business process standards with zero-knowledge cryptographic verification to enable privacy-preserving healthcare process compliance across distributed systems. Methods: We developed a multi-layer architecture combining formal business process modeling, zero-knowledge proof generation, and regulatory compliance verification. The framework extends established OMG standards with cryptographic verification capabilities to achieve verifiable compliance, privacy preservation, and regulatory accountability. Implementation testing was conducted in synthetic data environments designed to represent real-world healthcare scenarios.¹ These environments enable comprehensive modeling and testing of multi-entity process orchestration patterns while maintaining privacy protections essential for healthcare research and development. All scenarios, clinical examples, and process expressions presented in this paper utilize synthetic data to ensure no real patient data, clinical records, or identifiable health information was used. Results: The ZK-PRET Business Process Prover framework demonstrates practical applicability across many healthcare domains including treatment planning, telemedicine coordination, healthcare administration, consumer health services, multi-entity clinical trials, and supply chain management. Implementation results demonstrate cryptographic verification capabilities that enable mathematical prevention of regulatory violations rather than post-hoc detection. The results demonstrate configurable privacy preservation through zero-knowledge verification and consistent proof sizes suitable for modeling complex orchestrations, while leveraging already widely used Web 2 process models, suitable for multiple runtime deployment topologies. Conclusions: Zero-knowledge healthcare process verification represents a foundational technology for regulatory compliance in distributed healthcare systems. While agentic AI systems present important opportunities for automation, the underlying requirement for verifiable process compliance through cryptographic means brings broader challenges. ZK-PRET Business Process Prover addresses these challenges in healthcare transformative flows, enabling safer deployment of autonomous systems while maintaining regulatory standards.
Autonomous AI agents executing consequential actions require authorization mechanisms that verify not only identity but voluntary intent. LICET (Latin: it is permitted) is a cryptographic middleware protocol binding AI agent authorization to real-time multi-modal physiological state via a three-layer architecture: (1) ECG waveform morphology matching as a medication-resistant identity and liveness anchor; (2) electrodermal activity (EDA) as a sympathetic cholinergic liveness signal immune to beta-adrenergic blockade; and (3) personalized Mahalanobis distance fusion over five physiological signals to elevate the cost of pharmacological coercion attacks. LICET defines a Biometric Trust Level hierarchy (L0-L3) aligned with the IETF RATS architecture (RFC 9334), per-event HKDF session-key derivation, HMAC biometric temporal signatures, Schnorr zero-knowledge proofs over BN128, and a SHA-256 hash-chained tamper-evident ledger. A reference implementation is publicly deployed at https://licet.dev/v1/.
This chapter explores interoperability as the foundation for functional, inclusive and emotionally resonant digital experiences – from smart homes to the metaverse. Through critiques of Internet of Things (IoT), Non-Fungible Tokens (NFTs) and Web3, it argues for human-centred design that prioritises discoverability, dignity and decentralised control. Drawing lessons from games like Bury Me My Love and platforms like Spatial , it shows how autonomy, mastery and purpose (AMP) can guide persistent virtual worlds. Interoperability is reframed not just as a technical goal, but also as a social, economic and ethical imperative – crucial to everything from refugee support to metaverse monetisation.
Rene Casanova (22631729), Fernan A. Villa-Garzon (22631732), John W. Branch-Bedoya (13936272)
Background Health information systems (HIS) are critical for digital health transformation, yet fragmentation and poor interoperability adoption remains a major challenge. Objectives This study systematically reviews architectural patterns used in HIS and evaluates their alignment with ecosystem-level requirements. Methods Following PRISMA 2020 guidelines, a systematic literature review was conducted across Scopus, IEEE Xplore, PubMed, and Web of Science (2020–2025). Eligible studies described, evaluated, or proposed HIS solutions. Results From an initial set of 304 records, 89 met the inclusion criteria. Service-based and decentralized/distributed ledger architectures were predominant, with emerging models integrating edge computing and modular design. FHIR-based contracts are found as stabilizers of interfaces, enabling validation and reducing integration costs. However, gaps persist in cross-border care, sustainability, and artificial intelligence integration. Conclusion While microservices dominate current HIS architectures, achieving resilient, interoperable ecosystems requires greater architectural diversity and intersectoral collaboration.
Background The medical device sector, valued at $569 billion, faces persistent financing challenges. Around 78% of startups fail because of capital shortages, not due to lacking technical quality. Blockchain-based tokenization emerges as a way to broaden access, yet success relies on economic factors of platforms and clear regulations. Methods Transaction cost data from Bitcoin, Ethereum, and XRP Ledger covered 540 days from January 2024 to June 2025, providing 3,240 observations per network. Experts, numbering 12, participated in a modified Delphi method to form a framework tailored to healthcare. Project outcomes came from Monte Carlo simulations running 10,000 iterations, checked by a triple control-loop system, and compared against two real-world examples. Volumes of transactions drew from stochastic models involving monthly, quarterly, and annual elements, mixing fixed regulatory needs with variable market influences. Results Layer-1 (L1) fees differ by orders of magnitude; representative 2025 snapshots show BTC and ETH L1 far above XRPL and major ETH L2s. XRPL fees are typically a tiny fraction of a cent; the base cost is 10 drops (0.00001 XRP) and is dynamically adjusted by network load. Probabilities of success varied from 10.1% to 12.3% on Bitcoin, 31.4%–48.3% on Ethereum based on Layer-2 adoption, and 71.6%–73.2% on XRP Ledger. Investor involvement correlated negatively with logarithms of costs, showing Spearman <mml:math xmlns:mml="http://www.w3.org/1998/Math/MathML" id="m1"><mml:mrow><mml:mi>ρ</mml:mi></mml:mrow></mml:math> of −0.91. Differences in success exceeded 60 percentage points across platforms. Examples illustrated how elevated expenses reduce engagement in VitaDAO on Ethereum, whereas low-cost systems like XRP Healthcare support ongoing involvement. Conclusion Choosing a blockchain platform critically influences viability in tokenizing medical devices. Layer-2 options reduce cost gaps but add complexities in bridging and use. Platforms offering stability, minimal fees, and regulatory alignment promote wider inclusion and reliable funding. Technical features, steady costs, and readiness for compliance together shape whether tokenization boosts innovation in healthcare or maintains barriers.
Open access
Quality and Safety in Healthcare
Neuroethics, Human Enhancement, Biomedical Innovations
Body area networks (BANs) frequently generate sensitive healthcare data from sensors and other devices. Security and privacy breaches in BAN systems can compromise information affecting patients’ physical health, emotional state, and financial well-being. The lack of well-defined security perimeters and qualified personnel to administer security in such dynamic environments requires an authorization framework for protecting patient data, where access depends on the users’ credentials, location, and time. Toward this end, this work aims to define a secure system architecture to incorporate fine-grained information access management. It also leverages a spatiotemporal attribute-based access control (STABAC) model to make it possible to enforce location and time factors with BAN policies and required attributes to make access decisions. The BAN policies have various dynamic constraints that may conflict with each other or introduce inconsistencies. Therefore, this work proposes a formal verification framework using timed colored Petri nets to ensure such errors are not introduced. The blockchain network is utilized to maintain policy integrity, where STABAC verifies policy integrity from the network through smart contract services before making access decisions. Finally, the policy and attribute management framework ensures that STABAC maintains a verified set of policies and attributes for authorizing uninterrupted care and services.
Do Hai Son, Nguyen Danh Hao, Tran Thi Thuy Quynh, Le Quang Minh
Decentralized applications (DApps) have gained prominence with the advent of blockchain technology, particularly Ethereum, providing trust, transparency, and traceability. However, challenges such as rising transaction costs and block confirmation delays hinder their widespread adoption. In this paper, we present our DApp named W2E - Workout to Earn, a mobile DApp incentivizing exercise through tokens and NFT awards. This application leverages the well-known ERC-20 and ERC-721 token standards of Ethereum. Additionally, we deploy W2E into various Ethereum-based networks, including Ethereum testnets, Layer 2 networks, and private networks, to survey gas efficiency and execution time. Our findings highlight the importance of network selection for DApp deployment, offering insights for developers and businesses seeking efficient blockchain solutions. This is because our experimental results are not only specific for W2E but also for other ERC-20 and ERC-721-based DApps.
Ethereum has recently switched to a Proof of Stake consensus protocol called Gasper. We analyze Gasper using PRISM+ , an extension of the probabilistic model checker PRISM with primitives for modeling blockchain data types . PRISM+ is therefore used to rapidly and automatically analyze the robustness of Gasper when tuning, up or down, several basic parameters of the protocol, such as network latencies and number of validators. We also study the effectiveness of Gasper in updating stakes and its resilience to three attacks: the balance, bouncing and time attacks.
Suzanna Schmeelk, Megha Kanabar, Kevin Peterson, Jyotishman Pathak
Abstract Objective The purpose of this study was to conduct a scoping review of publications that explored blockchain technology in the context of interoperability and challenges of electronic health record (EHR) implementations. We synthesize the literature regarding standards and security, specifically regulation, regulatory operability, and conformance to standards. We review open practitioner questions that were not addressed in the studies as directions for further research. Materials and Methods We conducted a literature search in the OVID databases (Medline and Embase) on terms blockchain, implementation, interoperability, EHRs, security, and standards. The search resulted in 152 nonduplicate, peer-reviewed manuscripts, of which 15 were relevant to our objective and included for synthesis. Results Based on the search results, we analyzed the adoption of blockchain technology in the healthcare systems and challenges to EHR implementation of blockchain. From the synthesized research, we categorized and reported compelling factors of blockchain for EHR integration using current knowledge on blockchain research standardization and architectural challenges. Discussion Our research showed promise in implementing blockchain technology associated with EHRs, especially with Health Information Exchanges. The studies relevant for both EHR (n = 5) and blockchain (n = 10) reported compelling factors and limitations of the architecture. Security (n = 4) and interoperability (n = 4) features were reported as compelling requirements with lingering challenges. Standardization literature (n = 3) reported implementation challenges. Conclusion This study shows promise in implementing blockchain technology within EHR systems. The adoption is increasing; however, multiple implementation challenges remain from architectural perspectives (eg, scalability and performance), to security challenges (eg, legal requirements), and standard perspectives including patient-matching problems.
Francesco Sanmarchi, F Toscano, M Fattorini, Andrea Bucci · 5 authors
Modern healthcare management and clinical practice strongly rely on data and scientific evidence. Digital technologies, tools, and services are core components of Healthcare Management and scientific Research (HMR). Data interoperability, security, privacy, and ease of sharing represent fundamental conditions for guaranteeing quality HMR. Current data management solutions in HMR are mainly built on two technological infrastructures: cloud-based (CB) or distributed ledger systems (DLTs). DLTs offer alternative and reliable alternatives for the management and sharing of data in HMR. Their use can help increase confidence and trust in the integrity of data and the resulting evidence. \nThe aim of this paper is to shed light on CB and DLT solutions, emphasizing the potential role of innovative digital solutions based on DLTs in creating a data-driven transformation of HMR, and to describe relevant examples and practical uses of DLT-based solutions for patients, healthcare management, and research activities. \nDLTs in particular can be increasingly useful for patients to truly have control over their health, for healthcare policymakers to increase the quality of organizational processes, and for research funders, editors and publishers to increase the return on investment, and the reuse and reproducibility of research. \nIn conclusion, harnessing the potential of digital technologies is essential to transform healthcare management and research, by enhancing data quality, reliability, and trust.
Open access
Electronic Health Records Systems
Artificial Intelligence in Healthcare and Education
Adopting and implementing the Clinical Decision Support System (CDSS) technology is a critical element in an effort to improve national quality initiatives and evidence-based practice at the point of care. CDSS is envisioned to be a potential solution to many current challenges in the healthcare sphere, which includes information overload, practice improvement, eliminating treatment errors, and reducing medical consultation costs. However, the CDSS did not manage to achieve these goals to the desired levels and provide context-appropriate alerts, although integrated with the electronic health records (EHRs) (1). Clinical decision support alerts can save lives, but frequent ones can cause increased cognitive burden to clinicians, worsen alert fatigue, and increase the duplication of tests. This ultimately increases health care costs without refining patient outcomes. Studies show that 49-96% of clinical alerts are ignored, raising questions about the effectiveness of CDSS (1). Blockchain, a decentralized, distributed digital ledger that contains a plethora of continuously updated, time-stamped, and highly encrypted virtual record, can be a key to addressing these challenges (2). The blockchain technology if integrated with the CDSS can serve as a potential solution to eliminating current drawbacks with CDSS (3). This article addresses the most significant and chronic problems facing the successful implementation of CDSS and how leveraging the Hyperledger Fabric can alleviate the clinical alert fatigue and reduce physician's burnout using patient-specific information. The proposed architecture framework for this study is designed to equip the CDSS with overall patient information at the point of care. This then empowers the physicians with the blockchain-integrated CDSS, which holds the potential to reduce clinician's cognitive burden, medical errors, and costs and ultimately enhance patient outcomes. The research study broadly discusses how the blockchain technology can be a potential solution, reasons for selecting the Hyperledger Fabric, and elaborates on how the Hyperledger Fabric can be leveraged to enhance the efficacy of CDSS.
BACKGROUND: Clinical decision support (CDS) is a tool that helps clinicians in decision making by generating clinical alerts to supplement their previous knowledge and experience. However, CDS generates a high volume of irrelevant alerts, resulting in alert fatigue among clinicians. Alert fatigue is the mental state of alerts consuming too much time and mental energy, which often results in relevant alerts being overridden unjustifiably, along with clinically irrelevant ones. Consequently, clinicians become less responsive to important alerts, which opens the door to medication errors. OBJECTIVE: This study aims to explore how a blockchain-based solution can reduce alert fatigue through collaborative alert sharing in the health sector, thus improving overall health care quality for both patients and clinicians. METHODS: We have designed a 4-step approach to answer this research question. First, we identified five potential challenges based on the published literature through a scoping review. Second, a framework is designed to reduce alert fatigue by addressing the identified challenges with different digital components. Third, an evaluation is made by comparing MedAlert with other proposed solutions. Finally, the limitations and future work are also discussed. RESULTS: Of the 341 academic papers collected, 8 were selected and analyzed. MedAlert securely distributes low-level (nonlife-threatening) clinical alerts to patients, enabling a collaborative clinical decision. Among the solutions in our framework, Hyperledger (private permissioned blockchain) and BankID (federated digital identity management) have been selected to overcome challenges such as data integrity, user identity, and privacy issues. CONCLUSIONS: MedAlert can reduce alert fatigue by attracting the attention of patients and clinicians, instead of solely reducing the total number of alerts. MedAlert offers other advantages, such as ensuring a higher degree of patient privacy and faster transaction times compared with other frameworks. This framework may not be suitable for elderly patients who are not technology savvy or in-patients. Future work in validating this framework based on real health care scenarios is needed to provide the performance evaluations of MedAlert and thus gain support for the better development of this idea.
The Internet of Things is a novel paradigm which involves the increasing prevalence of objects and entities supported with identifiers and the ability to exchange the data over a network. However, with all these advantages the risk comes, as the huge number of connected devices gives hackers more entry points. Distributed Ledger Technology (DLT) can stave off security threats to Internet enabled devices by providing a distributed ledger for their functioning, thereby eliminating the central node that networks usually depend on for management by their users. Internet of Things and Application (IOTA) is a new technology designed specifically for the Internet of Things (IoT) industry which depends on the distributed ledger for storing transactions. The main contribution of this thesis is to study and run a set of test cases in healthcare industry to prove the effectiveness and viability of using IOTA in many healthcare applications using data, images or even videos. We will also do a comparative analysis with Blockchain to prove that IOTA technology could stand all odds in terms of feasibility, reliability and robust data security.
Rarely in medicine does one observe the adoption of a new technology as it moves from infancy (and a domain of early adopters) into the realm of widespread, general use. Anesthesiologists may be an exception; they have long been in the vanguard of new technology adoption as a part of an ongoing quest for improved patient safety. More recently, however, technological developments in anesthesiology have involved information systems. These systems' potential to improve patient care is not so traditionally obvious as something such as a new physiologic monitor or a better anesthesia machine. Hence, the adoption of anesthesia information management systems (AIMS) has been slow, in part, because they are regarded as expensive, “optional” technology with little direct patient benefit. However, a new study by Halbeis et al. indicates a sharp uptick in the number of academic anesthesia departments that are either in the process of installing an AIMS, or have allocated resources to do so in the near future.1 The authors suggest that adoption of AIMS in academic departments is passing through a “tipping point,” as defined by Gladwell, wherein a new idea catches on and penetrates the culture widely.2 In other words, AIMS appear on the verge of completing the adoption lifecycle. Suddenly, anesthesia departments are finding themselves heavily involved in information systems (IS) either as clients or, in many cases, as the “business owners” of their own IS groups. Once installed, AIMS applications quickly become critical to the department's financial health and daily clinical activities. This focuses a sharp lens on the resources required to operate an AIMS. Limited IS funds and competition for priority are frequently cited reasons for delayed or deferred AIMS adoption in the Halbeis et al. study.1 This state of affairs commands attention from potential AIMS adopters, as every center with any substantial AIMS experience has learned that the acquisition and implementation costs are only part of the total cost of AIMS ownership. There is also a continuing requirement for application and system support that must be reliably met, so that the AIMS continues to meet changing clinical and administrative demands. What are the resources required to ensure initial and ongoing AIMS success? An AIMS requires dedicated personnel, not just for implementation, but also for ongoing support of the software, the associated hardware, maintenance and modifications of the user interface, and development and implementation of new functionalities. The specifics of how these resources are provided, which budget(s) they are supported by, and under whose jurisdiction they fall in the organizational chart differ widely, ranging from all support provided by hospital-wide IS departments to all AIMS activities being supported by the anesthesia department. Despite the disparate organizational features of the AIMS-dedicated IS resources, there are key roles that are common and easily identified in organizations with a successful AIMS. These roles must be anticipated and filled by departments considering an AIMS installation. First, there must be a competent, committed clinical champion—an individual familiar with the anesthesia workflow of the department who can both set up the AIMS interface and keep the interface up to date as the needs of the department change. This person must understand the capabilities and limitations of the AIMS well enough to know what can and cannot be accomplished when setting up the AIMS in order to match the operating room workflow. Almost always, this person is an anesthesiologist with facility in software, computer hardware, medical device interfaces, or database management. Given that none of these topics is addressed during anesthesia residency, such individuals are rare. The AIMS clinical champion should participate in product selection, so that their expertise regarding local anesthesia workflow, practices, and expectations may influence the selection of an AIMS whose capabilities most closely match the clinical setting. Here we encounter a Catch-22. How would the AIMS expertise required to make an informed selection develop in a department preparing to select its first AIMS? Frequently, a clinician with some prior interest and acknowledged ability in personal computing is nominated, and an informal consultation network with existing AIMS users is established. The process repeats for each new department selecting an AIMS; very few centers have been through the process more than once. Fundamental questions such as “How much of the clinician's time will selection and implementation require?” are negotiated anew each time. Given the financial and practice-impact issues at stake, AIMS selection is an area ripe for the development of capability and professionalism. The clinical champion must either be capable of maintaining the AIMS software and databases themselves, or be assisted by a software engineer, database administrator or programmer analyst with sufficient cross-training to work in all of the aforementioned specialties. For a multi-specialty anesthesia practice, this “AIMS engineer” role typically requires a full-time professional. Increasingly, hospital IS include electronic health records, provider order entry systems, and computerized lab result systems, all of which must interface with the AIMS. This increases the complexity of the programming/engineering services required, and potentially calls for more than one full-time equivalent person in the AIMS engineer role. The AIMS is literally and figuratively at the interface between medical devices and medical information systems. Thus, a successful AIMS requires constant attention from biomedical personnel (usually a biomedical engineer) who has sufficient IS background to set up, maintain and troubleshoot the physical connections and interfaces between the anesthesia equipment, intraoperative monitors, and the AIMS. Problems with these connections have resulted in medico-legal liability and losses that offset the value of the AIMS.3 Because this maintenance and troubleshooting capability must be available, or at least on call during all times the AIMS is in use, multiple individuals are typically required. Behind the scenes, perhaps the largest end-user of any AIMS is actually the anesthesia billing office. Because the AIMS functions required to support a successful billing operation are quite distinct from the clinical implementation, maintenance and development efforts, one or more separate, dedicated programmer analysts are often required to support the business functions. As mentioned above, no two organizations are alike in the exact configuration, governance, and funding of the resources supporting the AIMS. However, each of the half-dozen departments with established, successful AIMS implementations have either provided or secured personnel to fill these roles. For many early adopters, the resources were secured “on the fly,” as it became clear that the AIMS would founder without them. In successful programs the resources applied are not aberrations but, practically speaking, are quite homogeneous with respect to full-time equivalent clinicians, engineers, programmers and analysts across the various institutions. Every organization contemplating an AIMS installation should plan for these requirements or risk appearing ill-prepared when they must be urgently met. Installing an AIMS brings the anesthesia department into the world of operating room medical information systems demanding new personnel and capabilities, and ongoing resources to support this new operation. Can there be additional benefits, beyond the obvious (better charting) from the new expertise and expense? The Halbeis et al. study provides a hint: upcoming AIMS adopters strongly value improved data collection for clinical, quality assurance, and safety purposes, and to support clinical research as reasons for installing an AIMS.1 The early adopters have demonstrated the added benefits of having an AIMS, with examples such as easy retrospective searches for Quality Assurance/Quality Improvement purposes, easy reporting for “pay-for-performance” purposes, a platform for active quality management (including documentation quality related to billing, which justifies the cost), and a platform for managerial decision support.4–10 However, in virtually every case reported, the “out of the box” AIMS product was insufficient to provide the extra value. Instead, the considerable resources applied by the early adopters were used to modify or extend the capabilities of the AIMS. In some cases, AIMS vendors have incorporated new functionalities into their products in response to user examples or demands.3 However, the current offerings still do not perform all of the functions that a department will desire. The take-home message is that when planning for AIMS acquisition, anesthesia departments and hospitals must specify in their requests for proposals the additional personnel and list the additional functionalities to be developed, in addition to the capital and software acquisition and installations costs. Departments should develop their own requirements for additional AIMS functionalities, but should start by searching the medical literature. Almost without exception, what is known about AIMS modifications and additional functionalities has been published in peer-reviewed journals. In other words, the fundamental proof-of-concept reports about various additional functionalities and their operational and/or financial impacts are readily available. This is not to say that there is nothing more to be learned; the available reports merely scratch the surface, but the current body of knowledge is available and searchable. Thus, when developing additional requirements, the key reliance should be on the applicable scientific literature. In addition to the selected examples cited above, review of the AIMS-related literature indicates that AIMS-mediated improvements in anesthesia are related to the process of care (e.g., on-time antibiotics), billing, managerial decision-support, etc. In contrast to electronic health record systems in primary care settings, the time course of the data flow from (input) → AIMS → (output) is seconds to minutes as compared to hours to weeks. This compressed time frame may be a key differentiator between AIMS and other electronic medical record systems. A traditional medical informatics approach may not be ideally suited to advancing knowledge and capabilities. Instead, the early AIMS adopters are moving towards automated process monitoring and process control. The general form is as follows: Process modeling to create a reference process against which actual process progress can be compared, seeking noteworthy exceptions. Data integration of multiple electronic sources and different data types. Continuous process monitoring by recursive queries of the AIMS and other databases to identify process exceptions. Pushing data to key stakeholders, seeking to provide the right information to the person who needs it, at the time when it is most useful. The skills required to build these capabilities are closer to industrial engineering and scientific programming than to medical informatics. Anesthesia departments contemplating AIMS adoption must also think about how to get that expertise into their organizations. There is a significant risk to AIMS success that is still at hand, but little discussed. All of the successful AIMS implementations that have produced added value beyond simpler charting have been systems that were either developed by the implementers themselves, were products that the vendors modified in response to customer requests, were products that allowed additional software to be run on top of the AIMS, or some combination of these. Each of these AIMS products could be considered an anesthesiology-oriented product, and is frequently a standalone application. However, many hospital IS departments are seeking to cover all of the hospital's needs with one monolithic solution from a single vendor. Thus, there is a potential conflict among AIMS-users and AIMS-purchasers (i.e., the hospital) over a fundamental choice between vendors producing systems that serve anesthesia well (but are mute with respect to the rest of the hospital's needs), and vendors producing systems that cover more areas but may not perform the AIMS function very well. Depending on the hospital IS department's orientation, the larger software vendors' products may have a significant sales advantage. However, the AIMS adopters who have reported value-adding successes in the peer-reviewed literature have, to date, voted with their feet in favor of products over which they have the most control. Although AIMS adoption may have tipped in favor of implementation at academic centers, the technology as a whole is still vulnerable, perhaps more so because of the increased exposure to demanding users and high expectations for benefits that the out-of-the-box products do not provide. The potential for frustration and missed opportunities is high, as not all centers will succeed in selecting an optimal product, or in securing the resources to adapt the AIMS to best meet their needs. Hence, AIMS vendors would be well advised to attend to the users' needs themselves.
Martin Thomas Ivers, George F. Timson, Hans von Blankensee, Gary Whitfield · 6 authors
The United States Veterans Administration provides a medical care delivery system comprising more than 170 hospitals, clinics and domicilliaries. Historically, these institutions have been relatively autonomous in their day-to-day operations and consequently efforts at computerization have been difficult to adequately coordinate. A recent undertaking of the VA has been to establish decentralized coordination of planning and implementation for hospital computer systems. This presents a unique opportunity to promote standard, portable and well-designed solutions to meet the widely variable needs of a large and diverse health care delivery organization. Although computer systems for each hospital will vary with the needs of the hospital, functional program packages can be delivered and maintained in a cost-effective and manpower-efficient manner. Additionally, because all systems will be based on a common data dictionary it will be possible to gracefully expand systems as needed and to study clinical care and delivery methodologies across many institutions.
Reduced reimbursements from the federal government and third-party payors have threatened the financial viability of many hospitals. An increasing number of hospitals are losing money from their primary mission of caring for patients. The hospital “industry” is still viewed by many as inefficient. Hospitals are generally not run like businesses, nor is it really possible for them to function in the same manner because they have to provide services, to some extent unpredictable, 24 h a day, 7 days a week. Unlike businesses, they cannot increase the charges to their clients to any significant extent when their costs increase because fees are largely dictated by the federal government. For no other business is there the equivalent of capitation or dictation of prices by outside organizations as there is in the medical business. It is perhaps easier for hospital administrations to assess the productivity of their clinical laboratories than of most other hospital services. The number of tests, the number of staff, and the cost of running the service as determined by the supply and salary budgets can be readily quantified. Furthermore, these factors can be bench-marked against the performance of other institutions. However, clinical laboratories also have to contend with the absurd concept of the “billed test” beloved by the federal government, insurance carriers, and consulting companies lacking laboratory expertise. The “billed” test assigns equal weight to a multitest outpatient panel as it does to a dipstick urinalysis or to an elaborate genetic test that is labor-intensive and may take days to complete. This ridiculous concept makes comparisons of productivity between institutions impossible. Indeed, the billed test concept hides increases in productivity because one billed outpatient test may generate as much work as 12 inpatient tests. Successful efforts by hospitals to reduce their inpatient testing, because of non-reimbursability, then mask any increase in revenue-generating outpatient tests. This dual objective of reducing unnecessary inpatient testing and capitalizing on the potential for outpatient revenue has become a major charge for the responsible clinical laboratory director. Clinical laboratories everywhere have been faced with the challenge of doing more tests at less cost, i.e., boosting their productivity. Many laboratories have reached the point at which it is impossible to increase productivity using the equipment that they have. Although each generation of “automated” analyzers usually provides some improvement in throughput and turnaround time for results, they do not have the ability to make the quantum improvements that are a prerequisite to significantly improving productivity. This has led to the concept of “total laboratory automation”, as much a misnomer as “automation” is for a single laboratory instrument. Total laboratory automation goes beyond the automation of analyses but includes automation of much of the important hitherto labor-intensive manual preanalytical phase in the process. The concept was conceived in Japan and has been widely accepted there, so that many large Japanese hospitals now include robotized specimen processing and delivery systems. In the United States, only a very small proportion of even the largest hospital and reference laboratories have installed such systems. Clearly, many laboratory directors have been waiting to learn of the success, or otherwise, of the automated systems in daily operation before they, too, embark on such a major investment. Many also remain uncertain as to whether maximum centralization, as represented by total laboratory automation, is to be preferred over maximum decentralization, as represented by point-of-care testing. The 1999 Clinical Chemistry Forum was designed to present the arguments as to why a fresh approach to laboratory testing was needed and to detail the steps necessary to make the decision whether to commit to total laboratory automation and how to identify the steps involved in a successful installation. The presentations began, appropriately, with discussions of alternative approaches to coping with rapidly escalating workloads. These included total laboratory automation for both individual hospitals and for networks of hospitals. Within the laboratory, alternative approaches were presented, including the use of modular components and automation of selected fixed tasks. The topics covered included a discussion of the components of the necessary overall planning process by a senior administrator from an integrated health system. Another paper dealt with the internal marketing of the concept by the laboratory to the administration and medical staff who would have a major, and vested, interest in the successful operation of a new system. Two of the critical areas that can make or break a robotic system are the layout of the facility with its attendant demands, which involves providing an appropriate environment for both the operators and the analytical systems, and the design and implementation of a superior information system. The latter is essential for capitalizing on the rapid generation of test results. The planning for an automated laboratory entails much more than the operation of the system once it is installed. One of the difficulties in many laboratories is maintaining the daily processing and testing of specimens while a large part of the laboratory’s space is taken out of service during construction. An especially difficult area to manage is ensuring the loyalty and productivity of staff. This is particularly true when they are aware that one of the objectives of installing a robotized laboratory is to reduce labor costs, which must inevitably impact some of the staff whose goodwill and cooperation are essential. This also is essential during all of the steps before the successful introduction of routine operation of the system on a daily basis. A majority of the forum papers are presented here in their full-length form. Four other papers are summarized below that address key problems in working toward an automated laboratory. We believe that the meeting achieved its objective of presenting all of the issues that need to be recognized by a laboratory director before embarking on the very challenging and expensive pathway leading to total laboratory automation. Although this concept has been well accepted in Japan, the small number of installations in the US to date means that those laboratory directors who have installed systems are still pioneers. We are grateful that they were willing to share their experience at the 1999 Clinical Chemistry Forum. In addition, the attendees and the readers of these Proceedings need to recognize the dedication and support given by Jean Rhame and Pamela Nash of the American Association for Clinical Chemistry’s staff, who made the meeting happen. Implementation of total automation of a laboratory is a formidable task. Not only does it ultimately require a large expenditure of money, it requires time and perseverance on the part of its proponents. Two of the papers presented at this forum addressed the very practical issues of getting buy-in from constituencies as diverse as a hospital administration to all of the individuals whose jobs may be threatened by an automated system. A third paper summarized the necessary steps for the overall planning process, and a fourth paper highlighted the critical importance of information handling in a successful robotic facility. These papers are summarized below. Julie A. Fisher, Mount Sinai Medical Center, New York City, discussed selling the concept of a totally automated laboratory to a hospital’s administration and other stakeholders. Successful selling is based on extensive communication and detailed financial and other justifications. There are eight essential elements to successfully selling an automation concept. These are defining goals, assessing needs, obtaining stakeholder buy-in, the decision-making process, vendor selection, the financial planing process, implementation, and metrics. Continuous communication is essential throughout all phases of the project. The wishes of the laboratory must be congruent with those of the administration. The process may be protracted; the cycle between initial concept and routine operation may be as long as 6 years. The trigger for a laboratory to consider automation usually is pressure to reduce costs and improve its efficiency. Automation has the potential to enhance the economic survival of a laboratory, reduce its operating costs, improve the quality of services, and provide a safer work environment. The need for automation should be assessed in the context of whether the institution is planning to expand or to just cut costs. Every ramification must be considered. For example, contractual arrangements with unions must be taken into account. This will become particularly important when the system is fully implemented because contracts may determine who may or may not be laid off. Additionally, needs for upgrading or changing the laboratory information system and analytical instruments must be assessed. A successful automation project depends on stakeholder buy-in. The stakeholders include the laboratory staff, the hospital administration and Board of Trustees, and hospital physicians. It is important to communicate to each of the groups what automation will do for them. Each of these constituencies has different interests and concerns. The laboratory staff are most concerned about job security, but it is important to let them know that automation is a tool to help them perform their jobs differently, and perhaps better. For the administration and Board of Trustees, the focus needs to be on the financial bottom line, with emphases on the opportunity for both revenue enhancement and expense reduction. Other selling points for the administration can include the potential to perform tests for other hospitals and develop group purchasing arrangements with other hospitals for which laboratory services can be provided. Physicians are primarily concerned with turnaround times of test results as well as enhanced information. The financial planning process requires projections of revenue and expenses. A break-even analysis is essential and must demonstrate that automation will reduce costs and/or enhance revenue. Various approaches may be used. A traditional return on investment (ROI) analysis relates net income to investment capital. The formula for calculating a ROI may be refined to take into account sales as well, as in a DuPont analysis. This approach recognizes that it might not be beneficial to tie up assets, thereby lowering profitability. The same formula can be used for an expense analysis by keeping sales constant. The net profit margin increases with a reduction in expenses, and with automation, the key expense reduction is in labor. Technical productivity can be calculated by dividing the number of tests performed by the total number of paid full-time employees or equivalents (FTEs). The calculation of labor savings should take into account how the number of employees will be reduced. With layoffs, there often will be severance and/or retraining expenses to equip the laid-off employees for other jobs. Different laboratory areas will be affected differently. Thus, the laboratories in which automation will be implemented will be more impacted than others. For each laboratory area, a separate projection of staffing needs to be done. Recently, there has been a trend away from justifying automation solely on an ROI analysis because not all of the benefits can be quantified in financial terms. Automation provides added value through improved efficiency coupled with reduction in processing errors, improved turnaround times, automated repeat and reflex testing, enhanced safety, and improved specimen tracking. The active participation of stakeholders in the planning process enhances the laboratory’s ability to sell the concept. Thus, an overall executive committee derives benefits when supported by laboratory management with information systems and instrumentation teams. It is advantageous to enlist stakeholders in vendor selection because acceptance of the system is critically dependent on the their involvement. The more people involved in different aspects of the planning process, the greater the probability of acceptance. Even during the implementation phase, it is important to involve the stakeholders, especially the staff who will be directly affected by the system. During the installation and after the system becomes operational, it is important to continue to communicate to the stakeholders. Information that should be communicated includes actual performance compared with projections, especially with regard to revenue projections and/or expense reductions, the quality of service, and whether a safer environment has been created. Patricia Abbott, Hospital of the University of Pennsylvania (HUP), Philadelphia, discussed the practical aspects of creating a robotized laboratory. Because acceptance of laboratory automation by a hospital’s administration is, to a great extent, dependent on perceived financial benefits, an accurate estimate of the number of employees needed to operate the system is required. The greatest financial returns are likely to arise from reduced labor costs. Unfortunately, the estimate of the number of staff needed to operate a robotized laboratory must be made before the laboratory has any experience with the system or its impact. One of the first steps in the planning process is to decide which tests will be performed in the automated laboratory and which will be performed elsewhere. This decision requires not only an analysis of which tests are performed at each existing bench station but the proportion of tests requested stat vs routine per shift, the number of tests per shift, and the number of technologists working on each shift on each day of the week. With automation, it becomes feasible to combine the stat and routine workbenches for the high-volume tests, but for precise planning of staffing needs, the time of receipt of specimens in the laboratory must be considered. It is also necessary to consider physician needs in deciding which instruments should be interfaced with the robotized and to assess whether greater can be through the test on different analytical the of the planning process, it is essential to assess the and interests of the laboratory staff. This is especially important the laboratory been to a of separate laboratories because there may be a need for extensive of existing on the of the staff in the laboratory at it was to staff the automated laboratory with a staff who would be to operate all of the instruments in the and who would be by staff from the areas working in their areas of expertise. this the laboratory for example, be to on the of of the technologists who would be to operate only the in the automated laboratory to become in operating technologists who been to the and laboratories would not have to the needed to operate a was to assess the of the for working in the automated laboratory, it was on a small number of staff. The for the technologists to assess their to new and for management to assess each potential for a successful to a environment with new for the individuals selected to work in the automated laboratory was each existing The not only on instruments but also on the clinical of the that were new to them and of the results of these tests. before all technologists were to the it was on a selected staff and by their before it was out to all the staff. The of the automated laboratory the laboratory to turnaround time to the the and the in as well as from a processing to a of benefits through of test results possible to the efficiency of testing by the automated laboratory. a the turnaround times for and high-volume tests between in the laboratory information system of the receipt of a specimen and its test results to is now for and for the tests. It is important to have a committee of technologists to at all of work including and in work A of the a of the planning committee once the decision to been made to that the interests of all of the staff were The planning committee has been after the system to Because the staff from different the senior management has with the management of the automated laboratory to their and has with the staff on a as well as on a to that the of the staff are and The senior management a many of the staff a and that problems were to be A committee was as a to and assess problems and The ROI for the project at was based on the of the impact of on the staff, staff were to for all even those not directly affected by the automated laboratory, so that those staff from the automated laboratory be to laboratory the and of these benefits were to them. In the number of that to be was less than been for because of a to tests from other hospitals and the A. the concept of project management as to the of a robotized laboratory. management is as the of and to project to or needs and from a project. Thus, it is a approach to the management of costs, and However, it has only been management requires of a to and manage people and other One individual is to the and is given and to manage the project to its areas of or function are involved in project and the project should have and some in all of them. The primary areas involve the management of cost, and These are by the management of and management is concerned with the of the the overall and of management involves of the necessary the of and the for the project. It is concerned with all aspects of and requires critical and/or as management planning and cost and management all of the of total quality management to that the of the project will the needs of the of the project. management the most use of the people involved in the project and includes and management includes the to the and services needed to the project. management is the function of and to The project must manage or communication so that all of the appropriate people are about the of the project at the appropriate time in the appropriate both and in Each project has a cycle which may have different of and There is no single to manage a but the approach involves the phases of implementation, and the of the concept phase, there usually is only a of a but the of this phase is the for the project. The or design phase usually is when the project is to the project and is the critical detailed planning with planning is the need to develop to and manage of the project. Two critical require the of the people who must the project and the that many individuals working on a project are not working on it The of the phase is a project which should not be The must identify all the necessary and their costs The costs must be to the individual work times and must be with to to the overall project For large such as for installation of a costs with should be as part of the overall project. for costs are of the for for for and of the for the service for the instrument. For large it is to a work which the project to identify the and to to them. A is the for the and of time and cost to be based on is now readily to identify the through the and to determine the of the project. In of the most there is the of with of the project beyond the initial This is not a as long as the project the the cost, and quality and this to the stakeholders. A potential is and to develop management must be a and one of the most to manage is through to can be to whether the can be the probability of is or The latter requires the of a the objectives of the project are it is and its to an Mount Sinai Medical Center, New York City, discussed the critical of a laboratory information system in an automated laboratory. automation involves much more than a robotic system a laboratory. The in an automated laboratory is involved in both analytical and The latter includes both preanalytical such as the processing of and specimen and such as and The provides to the quality and and results and them to the In an automated laboratory, the of the must be integrated with the of the robotic processing and the robotic The each specimen on the robotic system and the robotic process to the and to the specimen and its they might be the system. It and from the robotic system the quality of each primary specimen and the of specimen in the so that specimens may be as It is for tests to be directly into the Not only does this reduce errors, it also has the potential to improve turnaround of to the also and testing. Furthermore, it enhances and provides an accurate time of specimen Within the laboratory, from the to the robotic information and the and system However, such an approach requires or of specimens for which tests were but not on the robotic of the provides in testing and reflex specimen testing. of different of specimens on the but the need to cost and may also a in the testing process because all specimens must through a single An automated laboratory is critically dependent on a and its and system should be in to to of some part of the system. An supply by an is essential to the impact of or in The should have a of that usually share the but with each one of handling the are also needed to provide in one become or to and from the to and and other should be for rapid the system one or more and should also be Each the system should be up to This should be in the at the same time operation of the in the and of the must be with and of the a is it should be in the of the before to the part of the a with the the laboratory staff should to but then should enlist the vendor for The same should be a The staff should provide the laboratory staff with an estimate of the likely so that alternative may be In the of a the medical staff must also be function is this should be communicated to all in the same manner that the was The papers summarized when taken with the full-length papers that will provide the an of the of and with regard to laboratory automation.