The research, published in Discover Artificial Intelligence, comes from Bo Xie and Ruoke Zhang, who analyzed their own experience running the Nursing AI Studio, a year-round innovation incubator created to help frontline health professionals turn real-world problems into governable AI tools. The team conducted a retrospective comparative case study of four AI-powered web applications developed through the studio between spring 2025 and spring 2026: a clinical evaluation tool for nursing education, a tailored support tool for dementia caregivers, a patient simulation tool for nursing students, and a statistical assistance tool for large-scale biomedical and social-behavioral datasets. The first three served internal university users and were built with the help of a single graduate research assistant in computer science; the fourth was an NIH-funded project involving researchers at two universities.

The authors defined deployment burden as the organizational, technical, and coordination work required to move a locally developed functional AI-powered web application into legitimate institutional use. They operationalized it across five dimensions: temporal burden measured in business days, pathway-discovery burden reflected in gaps and uncertainty about the next responsible office, dependency burden from steps that could not proceed until prior approvals were complete, enterprise integration burden covering authentication and security review, and collaboration-context burden arising from external collaborators or changing enterprise requirements. Data came from structured deployment logs and dated operational records including email confirmations, approval notifications, and internal deployment notes.

The results reveal a striking pattern. Across the three internal tools, early infrastructure steps were consistently fast and stable: obtaining cloud storage access took one business day, subdomain setup took three, and enterprise AI licenses and Information Security Office review were completed in one to two business days. Enterprise integration, by contrast, was the longest and most variable stage: six business days for the first tool, seventeen for the second, twenty-five for the third, and more than three months for the cross-institutional project. These numbers suggest that early provisioning was not the primary bottleneck. Instead, the pathway slowed most when the application needed deeper enterprise handling around authentication, institutional access, or both.

Perhaps the most revealing finding concerns what the authors call pathway-discovery burden. For the first tool, approximately two weeks separated AI-license approval on October 17, 2025, from initiation of the cloud storage request on October 31, 2025, and another roughly two weeks separated cloud storage setup from initiation of the subdomain request on November 17, 2025. These lapses were not periods of team inaction but time spent trying to discover what the next institutional step was, whom to contact, and whether any prerequisite existed. Later experience suggested that acquiring an enterprise AI license did not actually need to precede cloud storage setup, meaning at least part of the delay reflected an initially misread sequence rather than an unavoidable dependency.

Some burdens proved reusable. Once an enterprise AI license and a workable internal path were established, later internal tools did not require a new AI license request. Cloud storage access and subdomain setup became standardized enough to function as reusable assets. However, repetition did not eliminate all obstacles. The third tool showed that prior experience still did not prevent substantial delays when downstream credential and integration issues arose. The first tool’s integration was also expedited through a deliberate administrative intervention linked to an existing memorandum of understanding with the Chief Information Officer’s office, meaning it should not be treated as a neutral baseline.

The fourth tool introduced a qualitatively different problem. Although it remained a health-related research tool, this NIH-funded project involved collaborators from two universities, so the challenge was no longer only how to move through one institution’s internal pathway. It became a cross-institutional access problem involving AI and computing resources, control of deployment infrastructure, and uncertainty about how external personnel could participate in building a tool that would ultimately live under the lead institution’s domain. The case suggests that a pathway workable for internal personnel can become fragile when collaboration crosses institutional boundaries.

The pathway also proved dynamic. During the period in which the manuscript was being prepared, an additional Information Security Office compliance requirement emerged for this workstream, underscoring that the deployment pathway continues to change even after teams believe they have learned it. Deployment burden is therefore not only a steep first-team learning curve but also an ongoing maintenance burden of keeping up with a moving enterprise and compliance environment. The authors argue that deployment knowledge cannot be treated as a one-time checklist that each team learns and keeps forever.

The practical implication is not that institutions should lower standards or bypass governance. Rather, they should stop forcing each AI builder team to rediscover the same pathway independently. The authors propose adapting a studio-like model across campus for clinically relevant AI projects in the health and social sciences: a small, shared service could help teams scope projects early, identify needed collaborators and expertise, maintain reusable templates and accounts, interpret sequencing, and escalate complex integration issues. They also recommend a staged pathway that pre-provisions what can be reused, allows controlled web deployment and pilot use when appropriate, and escalates to deeper enterprise integrations only when their value justifies the added burden.

For prospective researchers and frontline health professionals, the lesson is that internally developed tools are not equivalent to creating a custom GPT or configuring a commercial chatbot for personal use. Meaningful institutional deployment requires early decisions about collaborators, access, hosting, authentication, review, maintenance, and escalation points. The study has limitations: the evidence base was brief and retrospective, the sample was small, the cases arose in one institutional environment, and the authors were participant-observers. The tools were clinically relevant but not bedside clinical decision-support systems, so the pathway may differ for higher-risk applications. Still, the findings offer a practice-informed map that similar academic health settings can examine in their own infrastructure, making visible a hidden form of implementation waste that is easy to miss if one looks only at formal review times.

Subject of Research: Deployment pathways and organizational burden for internally developed AI tools in clinical education and health research

Article Title: Analyzing and redesigning deployment pathways for internally developed artificial intelligence tools in clinical education and health research

Article References: Xie, B., & Zhang, R. (2026). Analyzing and redesigning deployment pathways for internally developed artificial intelligence tools in clinical education and health research. Discover Artificial Intelligence, 6(1), Article 1240. https://doi.org/10.1007/s44163-026-02220-0

Image Credits: AI Generated

DOI: 10.1007/s44163-026-02220-0

Keywords: artificial intelligence, health informatics, clinical education, enterprise integration, deployment burden, Nursing AI Studio, information security review, cross-institutional collaboration, health AI governance, implementation science, academic health research, e-health