Mobile Emergency, an Emergency Support System for Hospitals in Mobile Devices: Pilot Study
Notice bibliographique
Résumé
BACKGROUND: Hospitals are vulnerable to natural disasters, man-made disasters, and mass causalities events. Within a short time, hospitals must provide care to large numbers of casualties in any damaged infrastructure, despite great personnel risk, inadequate communications, and limited resources. Communications are one of the most common challenges and drawbacks during in-hospital emergencies. Emergency difficulties in communicating with personnel and other agencies are mentioned in literature. At the moment of emergency inception and in the earliest emergency phases, the data regarding the true nature of the incidents are often inaccurate. The real needs and conditions are not yet clear, hospital personnel are neither efficiently coordinated nor informed on the real available resources. Information and communication technology solutions in health care turned out to have a great positive impact both on daily working practice and situations. OBJECTIVE: The objective of this paper was to find a solution that addresses the aspects of communicating among medical personnel, formalizing the modalities and protocols and the information to guide the medical personnel during emergency conditions with a support of a Central Station (command center) to cope with emergency management and best practice network to produce and distribute intelligent content made available in the mobile devices of the medical personnel. The aim was to reduce the time needed to react and to cope with emergency organization, while facilitating communications. METHODS: The solution has been realized by formalizing the scenarios, extracting, and identifying the requirements by using formal methods based on unified modeling language (UML). The system and was developed using mobile programming under iOS Apple and PHP: Hypertext Preprocessor My Structured Query Language (PHP MySQL). Formal questionnaires and time sheets were used for testing and validation, and a control group was used in order to estimate the reduction of time needed to cope with emergency cases. First, we have tested the usability and the functionalities of the solution proposed, then a real trial was performed to assess the reduction in communication time and the efficiency of the solution with respect to a case without Mobile Emergency tools. RESULTS: The solution was based on the development of a mobile emergency application and corresponding server device to cope with emergencies and facilitate all the related activities and communications, such as marking the position, contacting people, and recovering the exits information. The solution has been successfully tested within the Careggi Hospital, the largest medical infrastructure in Florence and Tuscany area in Italy, thus demonstrating the validity of the identified modalities, procedures, and the reduction in the time needed to cope with the emergency conditions. The trial was not registered as the test was conducted in realistic but simulated emergency conditions. CONCLUSIONS: By analyzing the requirements for developing a mobile app, and specifically the functionalities, codes, and design of the Mobile Emergency app, we have revealed the real advantages of using mobile emergency solutions compared to other more traditional solutions to effectively handle emergency situations in hospital settings.
Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.
Comment cette classification a été obtenuedéplier
Prédiction machine sur la base complète
Imitation des enseignantsNi prévalence calibrée, ni vérité terrain. Validation humaine à venir. Le volet Gemma est une étiquette directe du modèle pour chaque travail de la base, lue sur la notice réduite au titre. Le volet Codex est un classifieur appris des 10 348 étiquettes directes de Codex et calibré sur les taux pondérés de l'échantillon; les champs sans appui suffisant ne portent aucun appel Codex. Le mode candidate est l'union des deux volets; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont pas des étiquettes humaines.
Scores du classifieur distillé par catégorie (deux têtes)
| Catégorie | Codex | Gemma |
|---|---|---|
| Métarecherche | 0,002 | 0,003 |
| Méta-épidémiologie (sens strict) | 0,001 | 0,000 |
| Méta-épidémiologie (sens large) | 0,000 | 0,000 |
| Bibliométrie | 0,001 | 0,000 |
| Études des sciences et des technologies | 0,001 | 0,001 |
| Communication savante | 0,001 | 0,001 |
| Science ouverte | 0,001 | 0,001 |
| Intégrité de la recherche | 0,001 | 0,001 |
| Charge utile insuffisante (le modèle a refusé de juger) | 0,004 | 0,001 |
Scores machine (provisoires)
Les deux têtes enseignantes du modèle étudiant, lues sur ce travail. Un score ordonne la base pour la relecture; il n'affirme jamais une catégorie, et le statut de validation accompagne chaque rangée tel quel.
Scores de référence d'un modèle non mature (critères de maturité non atteints, 7 itérations). Un score ordonne; il n'affirme jamais une catégorie.
score_only:v0-immature-baseline · tel quel depuis la passe de notation : score_only signifie que le nombre peut ordonner les travaux, et qu'aucune étiquette de catégorie n'en découleClassification
machine, non validéePrédiction automatique; un appel candidat d’une seule source (Gemma direct ou Codex distillé), pas un consensus.
Le détail, modèle par modèle et score par score, se trouve en fin de page sous « Comment cette classification a été obtenue ».