MétaCan
Menu
Retour à la cohorte
Enregistrement W4392516007 · doi:10.3389/fdgth.2024.1341475

Smart hospital: achieving interoperability and raw data collection from medical devices in clinical routine

2024· article· en· W4392516007 sur OpenAlex
Eimo Martens, Hans-Ulrich Haase, Giulio Mastella, Andreas Henkel, Christoph D. Spinner, Franziska Hahn, Congyu Zou, Augusto Fava-Sanches, Julia Allescher, Daniel Heid, E. Strauss, Melanie-Maria Maier, Mark Lachmann, Georg Schmidt, Dominik S. Westphal, Tobias Haufe, David Federle, Daniel Rueckert, Martin Boeker, Matthias Becker, Karl‐Ludwig Laugwitz, Alexander Steger, Alexander Müller

Pourquoi ce travail est dans la base

Une base qui oublie comment elle a trouvé un travail ne peut pas être vérifiée. Voici les voies qui ont admis celui-ci.

affAu moins un auteur déclare une institution canadienne dans l'instantané OpenAlex épinglé.

Notice bibliographique

RevueFrontiers in Digital Health · 2024
Typearticle
Langueen
DomaineMedicine
ThématiqueHealthcare Technology and Patient Monitoring
Établissements canadiensArtificial Intelligence in Medicine (Canada)
Organismes subventionnairesDeutsche Forschungsgemeinschaft
Mots-clésInteroperabilityRaw dataComputer scienceInterface (matter)Data integrationDatabaseHospital information systemSystem integrationData collectionUser interfaceMedical recordInformation systemMedicineWorld Wide WebEngineering

Résumé

récupéré en direct d'OpenAlex

Introduction: Today, modern technology is used to diagnose and treat cardiovascular disease. These medical devices provide exact measures and raw data such as imaging data or biosignals. So far, the Broad Integration of These Health Data into Hospital Information Technology Structures-Especially in Germany-is Lacking, and if data integration takes place, only non-Evaluable Findings are Usually Integrated into the Hospital Information Technology Structures. A Comprehensive Integration of raw Data and Structured Medical Information has not yet Been Established. The aim of this project was to design and implement an interoperable database (cardio-vascular-information-system, CVIS) for the automated integration of al medical device data (parameters and raw data) in cardio-vascular medicine. Methods: The CVIS serves as a data integration and preparation system at the interface between the various devices and the hospital IT infrastructure. In our project, we were able to establish a database with integration of proprietary device interfaces, which could be integrated into the electronic health record (EHR) with various HL7 and web interfaces. Results: In the period between 1.7.2020 and 30.6.2022, the data integrated into this database were evaluated. During this time, 114,858 patients were automatically included in the database and medical data of 50,295 of them were entered. For technical examinations, more than 4.5 million readings (an average of 28.5 per examination) and 684,696 image data and raw signals (28,935 ECG files, 655,761 structured reports, 91,113 x-ray objects, 559,648 ultrasound objects in 54 different examination types, 5,000 endoscopy objects) were integrated into the database. Over 10.2 million bidirectional HL7 messages (approximately 14,000/day) were successfully processed. 98,458 documents were transferred to the central document management system, 55,154 materials (average 7.77 per order) were recorded and stored in the database, 21,196 diagnoses and 50,353 services/OPS were recorded and transferred. On average, 3.3 examinations per patient were recorded; in addition, there are an average of 13 laboratory examinations. Discussion: Fully automated data integration from medical devices including the raw data is feasible and already creates a comprehensive database for multimodal modern analysis approaches in a short time. This is the basis for national and international projects by extracting research data using FHIR.

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.

Prédiction distillée sur la base complète

Imitation des enseignants

Ni prévalence calibrée, ni vérité terrain. Validation humaine à venir. Apprise à partir de 10 348 étiquettes directes de Codex et de 10 348 étiquettes directes de Gemma. Le mode candidate est l'union des têtes enseignantes seuillées; le consensus est leur intersection. Ces sorties portent le statut machine_predicted_unvalidated et ne sont ni des étiquettes humaines ni des étiquettes directes de modèles de pointe.

score de la tête « metaresearch » (Codex)0,002
score de la tête « metaresearch » (Gemma)0,001
Version: codex-gemma-dda1882f352aStatut de validation: machine_predicted_unvalidated
Catégories candidatesaucune
Catégories consensuellesaucune
DomaineSignal candidat: aucune · Signal consensuel: aucune
Devis d'étudeSignal candidat: Observationnel · Signal consensuel: Observationnel
GenreSignal candidat: Empirique · Signal consensuel: Empirique
Score de désaccord entre enseignants0,291
Score d'incertitude au seuil0,512

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0020,001
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0010,000
Bibliométrie0,0000,000
Études des sciences et des technologies0,0000,000
Communication savante0,0000,000
Science ouverte0,0000,000
Intégrité de la recherche0,0000,001
Charge utile insuffisante (le modèle a refusé de juger)0,0000,000

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.

Tête enseignante Opus0,052
Tête enseignante GPT0,394
Écart entre enseignants0,342 · la distance entre les deux têtes enseignantes sur ce seul travail
Statut de validationscore_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écoule