A Mobile App Development Guideline for Hospital Settings: Maximizing the Use of and Minimizing the Security Risks of "Bring Your Own Devices" Policies
Bibliographic record
Abstract
BACKGROUND: Hospitals today are introducing new mobile apps to improve patient care and workflow processes. Mobile device adoption by hospitals fits with present day technology behavior; however, requires a deeper look into hospital device policies and the impact on patients, staff, and technology development. Should hospitals spend thousands to millions of dollars to equip all personnel with a mobile device that is only used in a hospital environment? Allowing health care professionals to use personal mobile devices at work, known as bring-your-own-device (BYOD), has the potential to support both the hospital and its employees to deliver effective and efficient care. OBJECTIVE: The objectives of this research were to create a mobile app development guideline for a BYOD hospital environment, apply the guideline to the development of an in-house mobile app called TaskList, pilot the TaskList app within Boston Children's Hospital (BCH), and refine the guideline based on the app pilot. TaskList is an Apple operating system (iOS)-based app designed for medical residents to monitor, create, capture, and share daily collaborative tasks associated with patients. METHODS: To create the BYOD guidelines, we developed TaskList that required the use of mobile devices among medical resident. The TaskList app was designed in four phases: (1) mobile app guideline development, (2) requirements gathering and developing of TaskList fitting the guideline, (3) deployment of TaskList using BYOD with end-users, and (4) refinement of the guideline based on the TaskList pilot. Phase 1 included understanding the existing hospital BYOD policies and conducting Web searches to find best practices in software development for a BYOD environment. Phase 1 also included gathering subject matter input from the Information Services Department (ISD) at BCH. Phase 2 involved the collaboration between the Innovation Acceleration Program at BCH, the ISD Department and the TaskList Clinical team in understanding what features should be built into the app. Phase 3 involved deployment of TaskList on a clinical floor at BCH. Lastly, Phase 4 gathered the lessons learned from the pilot to refine the guideline. RESULTS: Fourteen practical recommendations were identified to create the BCH Mobile Application Development Guideline to safeguard custom applications in hospital BYOD settings. The recommendations were grouped into four categories: (1) authentication and authorization, (2) data management, (3) safeguarding app environment, and (4) remote enforcement. Following the guideline, the TaskList app was developed and then was piloted with an inpatient ward team. CONCLUSIONS: The Mobile Application Development guideline was created and used in the development of TaskList. The guideline is intended for use by developers when addressing integration with hospital information systems, deploying apps in BYOD health care settings, and meeting compliance standards, such as Health Insurance Portability and Accountability Act (HIPAA) regulations.
Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.
How this classification was reachedexpand
Full frame machine prediction
Teacher imitationNot calibrated prevalence, not ground truth. Human validation pending. The Gemma side is a direct model label for every work in the frame, read from the title-only record. The Codex side is a classifier learned from the 10,348 direct Codex labels and calibrated to design-weighted sample rates; fields without enough sample support carry no Codex call. Candidate is the union of the two sides; consensus is their intersection. These outputs are machine_predicted_unvalidated and are not human labels.
Distilled classifier scores by category (both heads)
| Category | Codex | Gemma |
|---|---|---|
| Metaresearch | 0.014 | 0.044 |
| Meta-epidemiology (narrow) | 0.003 | 0.002 |
| Meta-epidemiology (broad) | 0.001 | 0.001 |
| Bibliometrics | 0.004 | 0.001 |
| Science and technology studies | 0.002 | 0.002 |
| Scholarly communication | 0.003 | 0.005 |
| Open science | 0.004 | 0.003 |
| Research integrity | 0.007 | 0.004 |
| Insufficient payload (model declined to judge) | 0.004 | 0.007 |
Machine scores (provisional)
The two teacher heads of the student model, read on this work. A score orders the frame for review; it never asserts a category, and the validation status ships verbatim with every row.
Baseline scores from an immature model (maturity gate not passed, 7 training rounds). Scores rank; they never assert a category.
score_only:v0-immature-baseline · verbatim from the scoring run: score_only means the number may rank works, and no category label ships from itClassification
machine, unvalidatedMachine predicted; a candidate call from one source (direct Gemma or distilled Codex), not a consensus.
How this classification was reached, model by model and score by score, is at the end of the page under "How this classification was reached".