MétaCan
Menu
Retour à la cohorte
Enregistrement W2072605808 · doi:10.1097/00001888-200207000-00048

Electronic Procedure Logs

2002· article· en· W2072605808 sur OpenAlex

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

RevueAcademic Medicine · 2002
Typearticle
Langueen
DomaineComputer Science
ThématiqueICT in Developing Communities
Établissements canadiensFoothills Medical CentreUniversity of Calgary
Organismes subventionnairesnon disponible
Mots-clésMEDLINEComputer scienceChemistry

Résumé

récupéré en direct d'OpenAlex

OBJECTIVE: To create an electronic procedural logbook with enhanced user interactivity and usefulness as an educational resource. DESCRIPTION: From our own work on electronic student logbooks and other studies, it is clear that compliance with complete and valid data entry remains a challenge. Without direct and visible benefit, students are reluctant to spend time logging all their cases. We developed an interactive procedural logbook using Microsoft Embedded Visual Basic and Metrowerks CodeWarrior. Interface design focused on rapid data entry with minimum requirement for text, and field-level automation where possible. We loaded it onto a mixed platform of personal digital assistants (PDAs)--Compaq iPaq Pocket PCs and HandEra 330 PalmOS devices. Our rural residents were supplied with the devices of their choice. Various built-in educational reference resources included: (1) contextual help options about each procedure, which contained diagrams and pictures; (2) diagnostic and fee coding so they could see how poorly some procedures pay; and (3) Quick Tips relevant to each procedure, which can be easily modified by the preceptor. Preceptor evaluations and comments can be entered rapidly. Using built-in database conduits, data are automatically collected from each device on every HotSync with the desktop. Data can then be collated and analyzed using Microsoft Access or via secure Web access. DISCUSSION: Improved compliance has been dramatic-one resident logged 250 procedures in just two months. However, not all residents have been successful in establishing seamless synchronization, and the resulting data loss has caused frustration. The evidence indicates the need to implement central data collection and backup right from the outset. Central data collection provides many advantages. The program director has better information for future applications. Preceptor evaluations are now spread over many interactions and yet can be collated and analyzed. Quick Tips have been very popular-we have been able to collect the tips and redistribute them. Focus-group feedback from the residents has shown that the rich data in the logbook's reference component improved its usefulness and popularity as an educational tool. Choice of device type is important for user acceptance because devotees of one platform are reluctant to switch to another. Cross-platform development does slow the process but is increasingly easy with the latest software design tools, such as AppForge. These new tools have enabled us to explore further improvements in data entry. Digital ink provides the ability to capture annotated diagrams and preceptor signatures. Voice input is built in with these devices, and our software now allows for voice annotation for more detailed commentary by preceptors or student. The compressed digital sound file is collected along with the data and transcribed centrally (on-device voice recognition is not feasible yet). Point-of-care accessibility has been the key attraction of using these devices for logging encounter data. This project demonstrates that it is important to explore all multimodal interactive capabilities to provide a truly rich educational tool.

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,000
score de la tête « metaresearch » (Gemma)0,000
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: Sans objet · Signal consensuel: aucune
GenreSignal candidat: Empirique · Signal consensuel: aucune
Score de désaccord entre enseignants0,838
Score d'incertitude au seuil0,450

Scores Codex et Gemma par catégorie

CatégorieCodexGemma
Métarecherche0,0000,000
Méta-épidémiologie (sens strict)0,0000,000
Méta-épidémiologie (sens large)0,0000,000
Bibliométrie0,0000,000
Études des sciences et des technologies0,0000,000
Communication savante0,0000,000
Science ouverte0,0020,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,042
Tête enseignante GPT0,273
Écart entre enseignants0,231 · 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