Sistema di insegnamento/apprendimento adattivo indipendente da piattaforma per l'assistenza e la formazione medica

Dall'altro lato

Istituto di Biometria Medica e Informatica Dipartimento di Informatica Medica (Direttore: Prof. Dr. R. Haux)

e il

Laboratorio di formazione assistita da computer in medicina (direttore: Prof. Dr. Dr. h.c. H.-G. Sunday, Prof. F.J. Leven)

Sistema di insegnamento/apprendimento adattivo indipendente da piattaforma per l'assistenza e la formazione medica

Dissertamento inaugurale per il Doctor scientiarum humanarum (Dr. sc. hum.) della facoltà di medicina della Ruprecht-Karls-Universität Heidelberg

Presentato da Martin Haag di Brettheim

Il giorno più perso di tutti è quello in cui non hai riduto.

Dekan: Prof. Dr. Dr. h.c. H.-G. Domenica Direttore: Prof. Dr. R. Haux

I sistemi di insegnamento/apprendimento possono fornire un contributo importante a una formazione medica di alta qualità, permettendo di approfondire l'esperienza di apprendimento nella pratica reale o di preparare meglio gli studenti a questa pratica.

Il presente lavoro fornisce, tra l'altro, risposte alle seguenti domande:

• Quali caratteristiche concettuali deve avere un sistema di insegnamento/apprendimento per eliminare le debolezze dei sistemi CBT esistenti?

• Come aumentare l'utilizzo dei sistemi di insegnamento/apprendimento da parte degli studenti?

• Come migliorare l'accettazione dei sistemi didattici?

Il concetto di soluzione elaborato prevede un sistema di insegnamento/apprendimento shell, con il quale specialisti specializzati senza conoscenze informatiche possono creare e rendere disponibili sistemi di insegnamento/apprendimento di alta qualità in tutto il mondo. L'approccio di Shell scelto consente la facile riutilizzabilità sia dei contenuti di dominio che della funzionalità del sistema di insegnamento/apprendimento.

I docenti possono utilizzare il sottosistema di autore di Shell per creare sistemi di insegnamento/apprendimento che soddisfino le loro esigenze personali. I sottosistemi di insegnamento e apprendimento di Shell sono completamente basati su applicazioni Internet e standard Internet. Sono indipendenti da piattaforma. Ciò garantisce che i sistemi creati possano essere utilizzati su tutti i computer con accesso Internet, ovvero anche sui computer privati degli studenti e docenti, scegliendo tra modem o adattatore ISDN. Per risolvere i problemi di performance dei sistemi di insegnamento/apprendimento basati su Internet, si propone un'architettura a 7 strati.

I sistemi realizzati sono adattivi e adattabili, cioè si adattano ai propri utenti, ma possono essere adattati da essi stessi, a seconda delle preferenze personali.

La realizzazione dei concetti elaborati è avvenuta o avviene nell'ambito del progetto CAMPUS (Computer Assisted Education and Training in Medicine through Platform-independent Software).

1 CONCLUSIONE ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

1.1 PROBLEMATICA E MOTIVACIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.2 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.3 OBJECTIVO E QUESTIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1.4 FUNZIONE DELLA LAVORO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 PRINCIPALI 7

2.1 DEFINIZIONI DELLA COMPETENZA

2.2 Formazione medica

2.2.1 Progetto BMG

2.2.2 Programma di studio sulla riforma di Berlino

2.2.3 Riforma degli studi e CBT

2.3 Formazione basata su computer

2.3.1 Forma di interazione dei sistemi di insegnamento/apprendimento

2.3.1.1 Forma di interazione Presentazione 12

2.3.1.2 Forma di interazione Browsing

2.3.1.3 Forma di interazione Drill & Practice

2.3.1.4 Forma di interazione del dialogo tutoriale

2.3.1.5 Forma di interazione Simulazione

2.3.2 Sviluppo di sistemi CBT

2.3.3 L'apprendimento problematico con CASUS 15

2.4 Www . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.4.1 Hypertext e ipermedia

2.4.2 Svantaggi dell'ipertexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5 WBT-SYSTEME ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.1 Tipi di architettura

2.5.1.1 Architettura basata sul cliente ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.1.2 Architettura dei dati e delle conoscenze remoti 22

2.5.1.3 Architettura dell'insegnamento distribuito

2.5.1.4 Architettura basata su server

2.5.2 Comunicazione client/server

2.5.3 L'integrazione delle risorse Web disponibili . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.3.1 Diversi concetti di rappresentanza

2.5.3.2 Problema di granularità

2.5.3.3 Qualità delle risorse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.5.3.4 Dynamica del web

2.5.3.5 Gradi di integrabilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6 DIPENDENZA AL FORMATO PLATTO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6.1 Portabilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.6.2 Tecnologie di base per la realizzazione di sistemi WBT indipendenti da piattaforma

2.7 Adattabilità e adattabilità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8 Sistemi di insegnamento intellettuali 36

2.8.1 Costituzione ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

2.8.1.1 Modulo di esperti

2.8.1.2 Modulo studentesco 38

2.8.1.3 Modulo didattico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8.1.4 Modulo di comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.8.1.5 Supporto allo sviluppo 41

2.8.2 Critica degli intelligenti sistemi didattici

2.8.3 D3 e TRAINER

2.9 Modellazione dei dati semantici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10 DATENBANCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10.1 Modello di dati relativi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2.10.2 Database orientata all'oggetto e relativa all'oggetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 INTRODUZIONE E MODELLAZIONE

3.1 REGOLAMENTI AL SISTEMO WBT

3.1.1 Contenuto e didattica

3.1.2 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.1.3 Tecnologie di base

3.1.4 Decisione architettonica 56

3.2 Modello di fase per lo sviluppo dei sistemi WBT

3.2.1 Analisi didattica

3.2.2 Analisi delle esigenze

3.2.3 Progettazione della presentazione 60

3.2.4 Modellazione di dominio

3.2.5 Modellazione delle funzioni didattiche

3.2.6 Progettazione della distribuzione

3.2.7 Implementazione ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.8 Data e raccolta delle conoscenze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.2.9 Sistemi di prova 62

3.2.10 Evaluazione ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3 CONCEPTO di sistema di insegnamento e di apprendimento

3.4 CONCEPTO CAMPUSO 64

3.4.1 CAMPUS sistema di insegnamento/apprendimento

3.4.2 Modello di stratificazione

3.4.3 Modello di insegnamento

3.4.4 Modello di percorrenza dei casi

3.5 Modellazione concettuale

3.5.1 Modello di risultato normale

3.5.2 Modello di caso ... .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. ..

3.5.3 Modello di conoscenza dei casi

3.5.4 Modello di vocabolario

3.5.5 Modello di layout

3.5.6 Modello utente

3.5.7 Modello di domanda 105

3.5.8 Modello di sistema WBT

4 REALIZZIONE 111

4.1 Strutture e tecniche di base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4.2 SISTEMA di autorizzazione

4.3 Sistema di apprendimento

4.4 Sistema di istruzione

4.5 CAMPUS/PEDIATRIA E CAMPUS/INFECTIOLOGIA

5 CONSIDERAZIONE E DISCUSSIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 letteratura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ANTESI a. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I SYMBOLE UND NOTATION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II MODELLO LOGICO

III PRIVISIONE di riassunto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

IV CONSIGLIO DOMENICA ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...

V TABLETTA RICHONDENZIONE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

VI INDEX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 Introduzione

1.1 Problemi e motivazioni

Già all'inizio degli anni sessanta, dopo l'introduzione della seconda generazione di grandi computer nelle università, si è iniziato a sviluppare sistemi di formazione informatica (CBT) [OWEN, HALL et al. 65]. Anche se il prezzo della capacità informatica è diminuito di molte volte da allora e si trova ora su molti computer multimediali di scrivania, la formazione assistita da computer in medicina [LEVEN, SCHULZ et al. 95; KLAR, BAYER 90; KALLINOWSKI, MEHRABI et al. 97, BAUR, MICHAELIS (Hrsg.) 90] in Germania non ha sempre raggiunto livelli molto elevati.

L'elevata percentuale di test MC (MultipleChoice) in fisica e negli esami di Stato fa sì che l'offerta di media librerie o showrooms, che sono disponibili agli studenti come offerte di uso autonomo come le biblioteche, sia ancora poco utilizzata. Dopo l'esperienza maturata in varie università, le biblioteche sono utilizzate solo da circa due a cinque per cento degli studenti medici.

L'impiego di sistemi di CBT permette agli studenti di applicare più frequentemente e consolidare le loro conoscenze acquisite.

Anche il Consiglio scientifico si oppone positivamente all'uso dei sistemi CBT nella formazione medica:

La relazione pratica significa anche il contatto degli studenti con problemi pratici-clinici, discussioni di casusistiche e di strategie di soluzione, di diagnosi differenziali e di terapia differenziale.I media personali potrebbero essere utilizzati in modo redditizio. Anche se i programmi di apprendimento audiovisivi e informatici o i posti di lavoro non possono sostituire l'esperienza pratica, sono strumenti preziosi per preparare seminari e acquisire conoscenze su malattie rare o su oggetti particolarmente difficili.

Nelle sue recenti raccomandazioni sullo sviluppo dell'istruzione superiore attraverso i multimediali negli studi e nell'insegnamento, scrive:

Le offerte di studi multimediali approfondiscono l'esperienza di apprendimento nella pratica reale (ad esempio, il lavoro di laboratorio, l'esame del paziente attraverso una pratica virtuale); aprono nuove possibilità di preparare efficacemente tali pratiche e di supportare le possibilità di formazione in ambienti simulati.

L'esperienza del laboratorio di formazione medica assistita da computer dell'Università di Heidelberg mostra che gli studenti di medicina amano molto elaborare simulazioni multimediali di casi. I sistemi di navigazione puliti, in particolare quelli senza componenti multimediali, invece, trovano una notevole minore attenzione presso gli studenti. Purtroppo l'offerta di sistemi di insegnamento/apprendimento di qualità sul mercato commerciale non è ancora grande. Gli editori medici si affidano esclusivamente alle università e non sviluppano praticamente i sistemi di CBT da soli.

La situazione non cambierà molto in futuro, in particolare a causa dei costi di sviluppo di sistemi di insegnamento/apprendimento molto elevati e della domanda relativamente bassa, ad esempio, un impegno costoso da parte degli editori in questo settore è quindi difficile attualmente. Le università di medicina dovranno quindi investire risorse anche in futuro nella realizzazione di sistemi di CBT di alta qualità se vogliono utilizzare tali sistemi in formazione. Ciò è particolarmente necessario, in considerazione della riformulazione del regolamento di accreditamento per i medici, che è stata pianificata da molti anni (ad esempio [BM GESUNDHEIT (Hrsg.) 93]), che prevede, tra gli altri, una ridotta quota di gruppi di esperti di specialità MCT per gli esami.

(Hrsg.) 98) offrono un forum appropriato per questo. Anche progetti interuniversitari come il VIROR (Virtual University of Oberrhein) [VIROR], in cui il laboratorio è coinvolto nella formazione medica assistita dal computer, offrono ottime opportunità per lo scambio di informazioni.

Inoltre, il World Wide Web [LOWE, LOMAX et al. 96] offre prospettive completamente nuove per la realizzazione di sistemi di insegnamento/apprendimento basati su rete indipendenti da una piattaforma e spesso solo su questa piattaforma. Rispetto ai sistemi di CBT convenzionali [AUHUBER 98, HOOPER, J. O'CONNOR et al. 95, PASTERKAMP 91], creati su una determinata piattaforma informatica con un'autorizzazione operativa lì, tali sistemi offrono importanti vantaggi [AUHUBER 98, MAYLEIN et al. 98].

1.2 Problemi

I sistemi convenzionali di CBT disponibili sul mercato presentano vari punti deboli di concetto e presentano problemi di accettazione da parte di molti medici. I sistemi convenzionali di CBT comprendono i sistemi di insegnamento/apprendimento che operano su computer stand-alone senza connessione a rete e che si diffondono su portatili di dati, per lo più tramite pubblicazioni mediche specializzate.

Il problema 1 è che i sistemi CBT convenzionali dipendono dalle piattaforme, quindi gli studenti o le università hanno bisogno della giusta piattaforma hardware e software per poter lavorare con un sistema di insegnamento/apprendimento.

Problema 2: i sistemi CBT convenzionali devono essere installati. L'installazione richiede tempo e spazio sul disco rigido locale del computer. Inoltre, le installazioni, in particolare per i PC Windows, possono causare instabilità. Molti utenti sono quindi riluttanti a installare un sistema CBTS solo per scopi di prova.

Il problema 3: l'aggiornamento dei sistemi CBT convenzionali è impegnativo perché tutti gli utenti devono ricevere e riprodurre aggiornamenti sui loro computer.

Problema 4: L'uso di sistemi CBT convenzionali per l'autodidazia lascia gli studenti da soli se non possono risolvere da soli le questioni con le conoscenze contenute nel sistema.

Il problema 5: i sistemi CBT convenzionali non sono generalmente adattivi. L'adattabilità, cioè l'adattamento del sistema di insegnamento/apprendimento all'utente, si trova praticamente solo nei sistemi didattici intelligenti (cfr. capitolo 2.8).

Problema 6: La progettazione dei sistemi CBT esistenti non ha prestato molta attenzione alla riutilizzabilità dei contenuti didattici/apprendistici (dominio, multimediale di insegnamento/apprendimento, ecc.) e della funzionalità del sistema didattico/apprendistico. Spesso i dati di dominio e la conoscenza del dominio non sono strettamente separati dalla funzionalità del sistema didattico/apprendistico.

Il problema 7 è che la realizzazione di sistemi di insegnamento/apprendimento richiede molto tempo e costi e richiede conoscenze informatiche oltre alle competenze mediche.

Problema 8: Molti docenti hanno un atteggiamento critico nei confronti dei sistemi CBT, in particolare di quelli che non sono stati sviluppati in collaborazione con essi.

1.3 Obiettivo e questione

Per risolvere i problemi di cui sopra e quindi favorire l'impiego e lo sviluppo dei sistemi CBT, è necessario sviluppare sistemi con un'architettura radicalmente nuova.

Il lavoro pone gli obiettivi e le questioni seguenti:

Obiettivo 1: elaborare un concetto innovativo per la realizzazione dei sistemi di insegnamento/apprendimento utilizzati per l'istruzione e la formazione medica.

In relazione a tale obiettivo, si intendono rispondere alle seguenti domande:

Domanda 1.1: Quali sono le caratteristiche concettuali che un sistema di insegnamento/apprendimento deve avere per

• risolvere i problemi descritti nel capitolo 1.2 dei sistemi CBT convenzionali?

Domanda 1.2: Come si può ottenere un uso più frequente dei sistemi di insegnamento/apprendimento da parte degli studenti?

Domanda 1.3: Come può l'accettazione dei sistemi di insegnamento/apprendimento tra i docenti di medicina

Domanda 1.4: Come far sì che i docenti utilizzino più efficacemente i sistemi CBT nei loro insegnamenti e che i loro studenti lavorino con i sistemi CBT?

Domanda 1.5: In che misura il concetto può essere mantenuto indipendente?

Obiettivo 2: Attuazione esemplare dei concetti sviluppati in forma di prototipo

La medicina pediatrica e l'infezione.

1.4 Distribuzione del lavoro

Il capitolo 3 descrive in dettaglio il concetto di soluzione elaborato per i problemi descritti nel capitolo 1. Il capitolo 4 presenta brevemente la realizzazione dei concetti nell'ambito del progetto CAMPUS (Computer Supported Training and Continuing Education in Medicine through Platform-Free Software).

2 Principi

2.1 Definizioni del termine

Computer-based training (CBT): la formazione basata su computer è una forma di formazione in cui il computer viene utilizzato non come oggetto di apprendimento, ma come mezzo di insegnamento.

Sistema CBT: un prodotto software di applicazione e eventualmente hardware aggiuntivo necessario da utilizzare su un computer per l'istruzione e la formazione.

Sistema CBT convenzionale: sistema CBT in grado di funzionare su un computer stand-alone senza connessione con la rete e diffuso su portatili di dati, per lo più tramite vie di distribuzione tradizionali (spesso pubblicatori di specialità mediche).

Sistema WBT: sistema CBT basato su Internet o World Wide Web (WWW) e sui standard utilizzati.

Formazione basata sul web (WBT): formazione basata su computer utilizzando sistemi WBTS.

Funzionalità del sistema di insegnamento/apprendimento: Funzionalità del sistema di insegnamento/apprendimento comprende tutti i componenti che sono caratteristici dei sistemi di insegnamento/apprendimento e che rendono un sistema adatto alla formazione, compresi, tra gli altri, i componenti di insegnamento (strategiche di insegnamento implementate), i componenti di presentazione e le funzioni di navigazione (per i sistemi di navigazione).

Cliente di sistema di insegnamento/apprendimento: parte di un sistema di insegnamento/apprendimento che, per i sistemi di insegnamento/apprendimento con architettura client/server, si trova sul computer cliente e comunica con il server di sistema di insegnamento/apprendimento tramite rete informatica.

Server del sistema di insegnamento/apprendimento: parte di un sistema di insegnamento/apprendimento che, per i sistemi di insegnamento/apprendimento con architettura client/server, si trova sul computer del server e comunica con il cliente del sistema di insegnamento/apprendimento tramite rete informatica.

Tecnologia di base: tecnologia o linguaggio di programmazione per la creazione di sistemi WBT.

Sistema di insegnamento/apprendimento: sistema di CBT in cui esiste solo la funzionalità del sistema di insegnamento/apprendimento e in cui viene creato un sistema di CBT mediante l'aggiunta di dati di dominio e conoscenze di dominio.

2.2 Formazione medica

La conoscenza medica oggi è così ampia che, anche con una forte specializzazione in un determinato campo, la quantità di conoscenza disponibile è ancora poco visibile [WEED 89]. Inoltre, questa conoscenza cambia relativamente velocemente, in modo che durante la durata di uno studio di medicina è praticamente impossibile trasmettere agli studenti una quantità sufficiente di conoscenza medica [ARBEITSKREIS MEDIZINERAUSLEDUNG 95 S. 73].

Esistono quindi una serie di diverse proposte di riforma [LORKERKREIS MEDICINE EDUCATION 95, SCIENCE COUNCIL 92, BUNDESMINISTERIUM FOR HEALTH (Hrsg.) 93, MFT-PRESIDENTALKOMISSION 96] in cui sembrava emergere un consenso su molti punti sui provvedimenti necessari [EITEL 93a]. Nel 1989 il cosiddetto Murrhardter Kreis (un gruppo di lavoro di formazione medica finanziato dalla Robert Bosch Foundation) ha pubblicato uno studio sul futuro dell'architettura.

• Gli studi medici si concentrano sulla trasmissione di conoscenze di fatto, con una comprensione e una capacità di risolvere problemi meno intensi.

• Gli esami scritti condotti a livello nazionale richiedono troppe conoscenze dettagliate, che spesso non sono di grande importanza nella pratica professionale e vengono rapidamente dimenticate.

• Gli studenti di medicina non sono preparati a continuare a studiare in autonomia, cosa che sarebbe necessaria a causa della rapida evoluzione delle condizioni scientifiche, tecnologiche e sociali dell'istruzione professionale medica (CREATURE OF MEDICINE EDUCATION 95 p. 273).

• La gestione dei pazienti e dei loro problemi non viene adeguatamente esercitata; la pratica in materia di formazione medica è insufficiente.

• L'utilizzo dell'informazione non è sufficientemente comunicato e le competenze comunicative non sono sufficientemente formate.

• Gli aspetti scientifici hanno priorità negli studi medici rispetto agli aspetti psico-sociali, etici ed emotivi.

• La formazione clinica fornita nello studio non è sufficiente per un'attività in medicina generale.

• I contenuti didattici dei diversi corsi e livelli di formazione sono poco coordinati.

• La ricerca e l'assistenza sanitaria sono una priorità per la maggior parte degli insegnanti universitari rispetto all'insegnamento, il che spesso comporta un'insoddisfacente qualità didattica dei corsi.

• Le offerte di formazione con particolare attenzione agli aspetti scientifici, biomedici o psico-sociali non sono sufficientemente accettate dagli studenti o non sono offerte dalle università.

I requisiti per un curriculum di riforma derivano dai punti critici elencati:

• Gli studenti dovrebbero essere meglio formati per l'attività medica primaria.

• L'apprendimento indipendente, problematico e attivo dovrebbe essere incoraggiato.

• Si dovrebbe eliminare la rigida separazione tra formazione clinica e preclinica.

• Il contatto con i pazienti deve essere possibile al più presto possibile.

• Gli aspetti psico-sociali ed etici dovrebbero essere maggiormente considerati nel corso degli studi.

• Gli studenti dovrebbero avere più libertà di scelta nella progettazione degli studi.

• Gli esami dovrebbero essere più pratici e ridurre la percentuale di esami MC.

2.2.1 Progetto BMG

Il progetto del Ministero della Salute federale per la riforma dell'istruzione medica non soddisfa certamente in tutti i punti i requisiti di un curriculum di riforma [GÖBEL, REMSTEDT (Hrsg.) 95] sopra citati e non è conforme alle raccomandazioni del Consiglio scientifico [WISSENSCHAFTSRAT 92].

• Studi di sei anni, dividuti in tre parti (5+5 semestri, PJ), completati da un periodo di PI di 1,5 anni.

• connessione di preclinica e clinica.

• riassunto delle materie.

• Il contenuto dello studio deve essere diffuso, per quanto possibile, interdisciplinariamente e connesso allo studio.

• miglioramenti nella formazione pratica, ad esempio attraverso seminari, insegnamento in letto e gruppi di studio relativi agli oggetti nel primo ciclo di studio.

• L'apprendimento orientato ai problemi [ALBANESE, MITCHELL] HASMAN 89] come nuova forma di insegnamento in aggiunta all'infermeria.

• Exame di Stato in tre parti: la prima parte dell'esame dopo 5 semestri (fusione di fisica e 1° esame di Stato); la seconda parte dell'esame aumenta di dimensioni; l'esame orale-prattico è maggiormente ponderato; la terza parte si svolge continuamente come esame collegiato orale in quattro materie.

• Una clausola di sperimentazione dovrebbe consentire l'istituzione di corsi di modello di studio.

• Riduzione del 20% dei volumi di omologazione.

Il progetto non ha ottenuto l'approvazione necessaria nelle commissioni competenti, pertanto l'ottava novella del regolamento è stata rinviata a tempo indeterminato, ma è probabile che venga introdotta una clausola di sperimentazione che permetterà la realizzazione di corsi di modello come il programma di studi di riforma previsto a Berlino.

2.2.2 Programma di studio sulla riforma di Berlino

A Berlino, dopo un sciopero studentesco della WS 1988/89, è stato istituito un gruppo di lavoro per studiare la medicina sulla riforma. Il compito di questo gruppo di lavoro era quello di progettare contenuti e organizzare un programma di studi sulla riforma.

Lezioni interdisciplinari orientate al problema Gruppo di insegnamento

Figura 1: Distribuzione delle ore al corso di riforma di Berlino

2.2.3 Riforma degli studi e CBT

A differenza delle forme di insegnamento/apprendimento, il contenuto di insegnamento/apprendimento nei curricula di riforma (ALBANESE, MITCHELL, HASMAN 89) deve rimanere in gran parte invariato e una maggiore percentuale di autodipendenza deve comunque essere costantemente modificata a causa dei progressi nella ricerca medica.

2.3 Formazione informatica

2.3.1 Forma di interazione dei sistemi di insegnamento/apprendimento

Per i sistemi di CBT nel settore medico si possono distinguere cinque diverse forme di interazione (vedi Figura 2) [HAAG, MAYLEIN et al. 98]. Un sistema di insegnamento/apprendimento reale può avere contemporaneamente più delle forme di interazione indicate. Ad esempio, se in un sistema di insegnamento/apprendimento, oltre a una simulazione di caso (interazione form simulation, ecc.), esiste anche un lexicon elettronico (interazione browsing, ecc.) in cui gli utenti possono trovare le conoscenze necessarie per un trattamento di caso di successo.

Figura 2: Forme di interazione e architetture di sistemi CBTS

Il modulo di interazione presentazione rappresenta l'argomento del sistema in forma lineare, in forma elettronica di un discorso di diapositivo o di un'immagine sonora, le possibilità di intervento dell'utente sono limitate a andare avanti o indietro nella presentazione e a fermarla in caso di presentazione automatica.

La navigazione fornisce agli utenti i contenuti del sistema di insegnamento/apprendimento sotto forma di un ipertesto in cui possono navigare liberamente. La decisione su quale contenuto è visto in generale e in quale ordine è lasciata all'utente. In genere esiste un directory di contenuti e/o un elenco di parole chiave che può essere saltato su contenuti specifici. I contenuti sono collegati tra loro tramite link, creando una rete di elementi informativi.

I libri di testo elettronici [KNAUP 94] sono un esempio tipico di questa forma di interazione.

2.3.1.3 Forma di interazione Drill & Practice

La forma di interazione Drill & Practice serve per approfondire le conoscenze di fatto apprese con altri mezzi di insegnamento (ad esempio libri). Questo avviene rispondendo alle domande poste dal sistema di insegnamento/apprendimento o modificando gli esercizi. Viene fornito un feedback su se la domanda è stata risolta correttamente o no o se l'esercizio è stato eseguito correttamente o no. In questa forma di interazione, tuttavia, il sistema non cerca di determinare perché una domanda è stata risolta erroneamente.

2.3.1.4 Forma di interazione del dialogo tutoriale

A differenza delle forme di interazione presentazione e navigazione in cui il sistema didattico/apprendimento assume un ruolo passivo, il sistema CBT assume un ruolo attivo nella forma di interazione Tutorial Dialogue. Di solito, dopo la presentazione di singole unità didattiche/apprendimento vengono poste domande di controllo delle conoscenze, con le quali il sistema CBTS cerca di determinare se e fino a che punto la precedente unità didattica/apprendimento è stata compresa. Se le domande sono risposte erroneamente, il sistema fornisce precisazioni specifiche e presenta ulteriori informazioni e ulteriori conoscenze per eliminare il deficit individuato.

Una forma speciale del dialogo didattico è l'intelligente dialogo didattico, in cui vengono utilizzati metodi di intelligenza artificiale [WENGER 87] per controllare il dialogo tra sistema CBT e utenti in modo da promuovere l'apprendimento in modo ideale, attraverso l'analisi continua dei comportamenti di apprendimento, delle conoscenze precedenti, delle preferenze dell'utente, e sulla base di queste informazioni viene controllato il corso successivo del programma (ad esempio [FONTAINE, LE BEUX et al. 94]).

Il sistema di insegnamento/apprendimento si comporta in modo passivo, presentando all'utente il modello più realistico possibile di una sezione di realtà e mostrando le reazioni del modello alle azioni degli utenti. Tuttavia, il sistema non fornisce risposte dirette alle azioni degli utenti. Si può distinguere tra simulazioni di base (es. [HIRSCH, BRAUN et al. 93]) e simulazioni di caso (es. [PUPPE, REINHARDT 95]).

2.3.2 Sviluppo di sistemi CBT

Per lo sviluppo di sistemi CBT convenzionali con le forme di interazione presentazione (cfr. capitolo 2.3.1.1) e browsing (cfr. capitolo 2.3.1.2) sono disponibili un maggior numero di vari sistemi di autore commercialmente disponibili, che possono essere suddivisi in tre diverse categorie [HAAG 95]:

Scripto o sistemi basati su schede: per i sistemi basati su schede o su schede, l'autore crea i cosiddetti script che vengono elaborati in caso di avvenimenti specifici (ad esempio, selezione di un pulsante con il mouse, inserimento di testo, ecc.). Le lingue script sono generalmente molto potenti e supportano la creazione di ipertestuali. Per Windows, il PC è molto diffuso e è utilizzato. Per l'Apple Macintosh, HyperCard [APPLE 93] e SuperCard sono molto spesso utilizzati per la creazione di sistemi CBTS.

Icon-based systems: i sistemi basati su icone consentono la creazione di sistemi di insegnamento/apprendimento senza dover essere programmati nel senso tradizionale. gli autori possono creare il percorso di programmazione tramite la programmazione grafica posizionando e collegando icone tra loro. Le diverse icone rappresentano ciascuna delle strutture di base (loop, se-indicazione, ecc.), come si conosce da linguaggi di programmazione come Pascal. Con questo tipo di sistemi, gli esperti di settore senza grandi conoscenze informatiche possono creare rapidamente presentazioni e semplici sistemi di insegnamento/apprendimento. Tuttavia, la flessibilità nella programmazione è limitata.

I sistemi basati sul tempo: i sistemi basati sul tempo sono molto idonei per la creazione di presentazioni. Lungo un raggio di tempo possono essere organizzati diversi azioni, come ad esempio l'immagine di un'immagine, un campo di input o la riproduzione di un file audio. Le animazioni possono essere realizzate molto facilmente arrangiando singole immagini lungo il raggio di tempo. È possibile controllare l'inserimento degli utenti. Probabilmente il sistema basato sul tempo più frequentemente utilizzato è Macromedia Director [MACROMEDIA 94]. È disponibile per diverse piattaforme.

I sistemi di autore commerciali di cui trattasi presentano alcuni tipici deboli. Gli autori non possono separare strettamente il contenuto del dominio e le funzionalità del sistema di insegnamento/apprendimento, rendendo possibile la riutilizzabilità del contenuto difficilmente o solo con un sforzo relativamente elevato. Per esempio, per i sistemi di autore basati su scrittore e carta, su una mappa vengono registrati sia i contenuti del dominio che le funzionalità del sistema di insegnamento/apprendimento sotto forma di scritture installate sugli oggetti presenti sulla mappa (bottoni, campi di testo, ecc.).

2.3.3 L'apprendimento problematico con CASUS

Uno dei gruppi di lavoro attualmente più attivi nel settore della CBT medica in Germania lavora presso la Ludwig-Maximilians-Universität München, guidata da Martin Fischer. Con il sistema di insegnamento/apprendimento CASUS [FISCHER, GRÄSEL et al. 95] sviluppato in questo gruppo di lavoro, gli studenti di medicina possono imparare a partire da esperienze di insegnamento/apprendimento. Il sistema è composto da due componenti: un sistema di autore e un modulo di gioco o un player. Il sistema di autore facile da usare consente di creare esperienze di apprendimento con un confronto di impegno. Queste esperienze di insegnamento/apprendimento vengono memorizzate in modo opzionale su un computer locale o in una base di database di esperienze di base. L'utilizzo di questo tipo di dati può essere iniziato in un ulteriore progetto denominato MICH e un modulo di gioco o un player.

• Prima impressione del paziente

• Anamnesi

• Esame fisico

• controlli di laboratorio

• Esame tecnico

• Diagnosi

• Terapia e percorso Figura 3: Struttura schematica di un programma di insegnamento CASUS

Per la presentazione di caso, gli autori hanno a disposizione diversi layouts di cartoline (in totale 6) che consentono loro di presentare un caso di insegnamento/apprendimento. Tra le singole carte di presentazione, le carte possono essere integrate nella cartoline di caso, alle quali gli studenti devono rispondere alle domande relative al caso di insegnamento/apprendimento. Poiché gli autori inseriscono i contenuti (multimedia) delle carte da soli in freitext, è difficilmente possibile riutilizzare singoli componenti di caso senza riutilizzare le grandi componenti di un caso di insegnamento/apprendimento in altri casi di insegnamento/apprendimento.

Le attività di insegnamento/apprendimento possono attualmente essere archiviate in due database: in un database NeoAccess orientato all'oggetto e in un database Oracle relazionale. L'accesso al database NeoAccess avviene tramite un server di dati CASUS specificamente sviluppato. L'ORACLE è accessibile tramite il protocollo SQL (Structured Query Language) Net.

2.4 Www

Fino all'inizio degli anni '90, l'Internet era stato utilizzato quasi esclusivamente da scienziati e appassionati di tecnologia in tutto il mondo. Con la disponibilità del World Wide Web [BERNES-LEE, CAILLEAU et al. 92], iniziato nel 1989 al CERN (European Laboratory for Particle Physics), questa situazione è cambiata radicalmente.

Il World Web offre una serie di strumenti per la creazione di applicazioni in ambito medico (CIMINO, SOCRUS et al. p. 282). Applicazioni già esistenti possono essere inserite in tempi relativamente brevi utilizzando l'interfaccia CGI (Communicate Source Gateway) oppure possono essere facilmente accessibili all'interno dell'interfaccia CGI (Software per l'accesso all'interfaccia e le immagini).

Gli indiscutibili punti di forza del World Wide Web, come la facilità di utilizzo e la vasta disponibilità di software, hanno anche alcune debolezze:

• L'Hypertext Transmission Protocol (HTTP) è un protocollo senza stato. Quindi non viene costruita una connessione continua tra browser e server, ma per ogni azione dell'utente viene costruita una nuova [IBRAHIM, FRANKLIN 95]. Ciò provoca problemi nei dialoghi uomo-macchina a più livelli, perché il server non possiede informazioni sui passaggi di interazione precedenti. Come soluzione a questo problema possono essere utilizzati campi di input nascosti. Qui il server memorizza le informazioni in documenti HTML. Tuttavia, questa soluzione genera traffico di rete inutile.

• Se gli utenti hanno inserito dati nelle zone di inserimento e, successivamente, hanno aperto il pulsante "Back" o tornato alla pagina di inserimento tramite la lista di storia, si accorgono che i dati inseriti sono ancora nelle zone di inserimento e che possono essere tentati di inviare i dati di nuovo.

• Nel World Wide Web non è possibile stabilire se un determinato tipo di informazione è presente nel sistema [RAMM 95], quindi non può essere considerato come un sistema informativo. Si lamentano anche la mancanza di qualità di molte offerte nel World Wide Web (ad esempio [STOLL 96]). Un altro autore mette in guardia in questo contesto dal rischio che il Web possa facilmente diventare la più grande vanity press1 [LLAURADO 97] del mondo, perché chiunque possa essere autore, redattore e editore contemporaneamente con computer. Questi ruoli possono essere compiuti tutti in modo anonimo. Il rischio per i nuovi arrivati è la difficoltà di separare utili da dannosi.

• Un altro problema sono gli URL (Uniform Resource Locator). Quando si cambiano i nomi dei documenti o dei server o quando si ristrutturano, tutti i riferimenti esterni ai documenti interessati sono necessariamente vuoti.

Il World Wide Web mostra quindi dei punti deboli: approcci più ampi come Hyper-G [KAPPE, MAURER] DALITZ, HEYER 95, in cui i punti deboli tecnici sono almeno attenuati, non presentano grandi opportunità al momento, tuttavia, perché per il Web ora esiste un'enorme offerta di software e spesso anche gratuito.

2.4.1 Hypertext e ipermedia

Il concetto di ipertesto fu descritto per la prima volta nel 1945 da Vannevar Bush, un consulente dell'allora presidente degli Stati Uniti Roosevelt [NIELSEN 95]. Anche se il sistema Memex descritto da Bush per le pagine a grandi volumi di testo rimase irrealizzato, divenne sempre più evidente che la visione di Bush doveva essere realizzata.

Secondo Spiro e Jehng [SPIRO, JEHNG 90, citato in SCHULMEISTER 96 S. 248] i sistemi ipertestuali sono particolarmente adatti a ill-structured domains. Invece, i metodi dell'intelligenza artificiale sono finora largamente limitati a applicazioni ben strutturate, ad esempio matematica, fisica o linguaggi di programmazione.

I sistemi ipertestuali possono essere suddivisi in tre livelli [CAMPBELL AND GOODMAN 1988, citato in NIELSEN 95]:

Presentation level: a livello di presentazione si definiscono i comandi accessibili all'utente, l'aspetto dei nodi e dei riferimenti, ecc.

Hypertext Abstract Machine (HAM) level: al livello HAM è definita la struttura dei nodi e dei link presenti nel sistema, ad esempio diversi tipi di link, attributi di nodi (proprietari, ultima modifica...). Per l'importazione e l'esportazione di ipertestuali, il livello HAM è più adatto in quanto indipendente dalla piattaforma (a differenza del livello di database) e inoltre il livello di presentazione varia notevolmente da sistema a sistema. Tuttavia, lo scambio di ipertestuali non è molto semplice, poiché non solo i testi, ma anche diversi formati grafici, audio e video devono essere scambiati. Inoltre, i diversi tipi di link possono anche essere trasmessi senza perdita di informazioni.

Database level: il livello della banca dati ha poco a che fare specificamente con l'ipertex. Si tratta di memorizzare i dati in modo che le piccole parti di essi possano essere richieste in un tempo molto breve.

Attualmente sono pochi i sistemi che, nella loro struttura interna, si orientano a questo modello, ma il modello è utile per gli sforzi di standardizzazione e mostra interessanti prospettive per il futuro [NIELSEN 95].

2.4.2 Svantaggi dell'ipertesto

Hypermedia is a non pedagogical technology, one which is open to learning through browsing, but which must count on the students own intelligence for learning guidance. [DUCHASTEL 92, citato in SCHULMEISTER 96 S. 185]

Pertanto, i sistemi ipertestuali possono essere utilizzati solo per le persone in grado di individuare i propri bisogni di apprendimento e di soddisfare sistematicamente attraverso la navigazione in ipertesto; tuttavia, i sistemi ipertestuali possono facilitare la navigazione e la ricerca attraverso diversi approcci [NIELSEN 95]:

• Tour guidati: gli autori definiscono percorsi di apprendimento per determinati gruppi di utenti. Le persone del gruppo di utenti possono seguire i percorsi di apprendimento indicati in sequenza senza dover affrontare la navigazione. Il percorso di apprendimento può generalmente essere lasciato in qualsiasi luogo.

• Backtrack: possono essere utilizzati diversi metodi di backtrack. La soluzione più semplice per richiamare i nodi in ordine inverso non è certamente molto intelligente. In particolare se un utente ha visitato alcuni nodi più volte. Il backtrack singolo è un'alternativa utile. I nodi vengono richiamati in ordine inverso, ma i nodi che sono stati visitati più volte vengono richiamati solo una volta.

• Lista di storia: in una lista sono inseriti gli ultimi nodi saltati x. L'utente può scegliere da questa lista dove voler saltare.

• Bookmark: i bookmark consentono all'utente di selezionare le pagine ipertestuali, permettendo di saltare rapidamente su una pagina selezionata se necessario, eliminando eventuali ricerche prolungate.

• Grafici di panoramica: i grafici di panoramica mostrano, ad esempio, a diversi livelli di astrazione, una panoramica dei contenuti disponibili. Un'alternativa è la cosiddetta fisheye view, in cui singole aree e nodi sono rappresentati in modo più dettagliato più vicini all'attuale posizione dell'utente nell'ipertesto.

• Metaphorie: le metaphorie dovrebbero essere applicate in modo coerente in tutto il sistema e non mutare in modo da confondere l'utente.

L'overhead cognitivo è inteso come lo sforzo che si deve compiere nel leggere un ipertesto, oltre allo sforzo di acquisire conoscenze, per riuscire a recuperare la propria identità nella rete di riferimento [CONKLIN 87]. I lettori di un ipertesto devono sempre riflettere su ciò che hanno già letto, su ciò che li interessa ancora e su dove si trovano in questo momento.

Gli utenti di un sistema ipertestuale non sono guidati, ma possono muoversi completamente liberamente nell'iperspazio. È facile che un utente perda la visione di dove si trova attualmente. Questo fenomeno è chiamato lost in hyperspace [HALASZ 88].

2.5 sistemi WBT

2.5.1 Tipi di architettura

Il World Wide Web dispone di un'architettura client/server [NIEMANN 96] che consente di creare sistemi di insegnamento/apprendimento distribuiti basandosi su di essi. I sistemi di insegnamento/apprendimento possono generalmente essere divisi in tre livelli: livello di presentazione, livello di logica del sistema di insegnamento e livello di dominio dati e conoscenze. Il livello di presentazione rappresenta l'interfaccia di utilizzo tra l'utente e la logica del sistema di insegnamento. Le attività dell'utente (azioni di massa, input, ecc.) vengono elaborate dal sistema di insegnamento/apprendimento e la risposta al livello di presentazione viene ulteriormente ampliata. Il trattamento di questi livelli è basato sulle caratteristiche di conoscenze di ritorno che sono presenti nel sistema di insegnamento. Il sistema di insegnamento contiene dati che possono essere utilizzati in modo appropriato in un sistema di insegnamento, come un sistema di insegnamento e dati multimediali, che può essere utilizzato per determinate situazioni, come l'archivio e il sistema di insegnamento.

Servidori

Nel complesso, si possono distinguere quattro diversi tipi di architettura nei sistemi WBT [HAAG, MAYLEIN et al. 98]. Tre tipi di architettura (Remote Data & Knowledge, Distributed Teaching e Server-based) si trovano solo nei sistemi WBT, mentre il client-based è il tipo di architettura dei sistemi CBT convenzionali.

Cliente

presentazione presentazione presentazione presentazione

Figura 4: Architettura dei sistemi WBT

Per avviare e avviare un ambiente di durata necessario (ad esempio browser plug-in o macchina virtuale) occorre tempo, ma in genere solo pochi secondi e prima del lancio del sistema di insegnamento/apprendimento. Questo tempo è quindi di solito non critico. Inoltre, la performance delle tecniche di base utilizzate ha un ruolo. Tuttavia, i sistemi CBT non richiedono generalmente una potenza di calcolo particolarmente elevata, quindi la maggior parte delle tecniche di base offre prestazioni sufficienti.

I sistemi WBT del tipo client-based hanno l'architettura dei sistemi CBTS convenzionali. Per lo sviluppo di sistemi WBT basati sul client, l'intero sistema WBT è trasmesso e eseguito tramite un network di computer al client. Il server serve solo come file server, non ha altre funzioni. Tutti e tre i livelli del sistema di insegnamento/apprendimento sono quindi situati sul client (vedi Figura 4 [HAAG, MAYLEIN et al. 98]). Per lo sviluppo di sistemi WBT basati sul client, sono disponibili una serie di tecniche di base (vedi Capitolo 2.6.)

2.5.1.2 Architettura dei dati e delle conoscenze remoti

In questo tipo di sistema, non tutti gli elementi multimediali disponibili nel sistema e l'intera conoscenza del dominio esistente devono essere trasferiti dal server al client (vedi Figura 4). Inoltre, la logica del sistema didattico accede durante il corso del programma applicando le conoscenze contenute nel sistema didattico logico. Il vantaggio di un'architettura di questo tipo rispetto all'architettura basata sul cliente è che non tutti gli elementi multimediali disponibili nel sistema e l'intera conoscenza del dominio esistente devono essere trasferiti dal server al client (vedi Figura 4).

Ci sono una serie di diversi fornitori che offrono strumenti per l'accesso trasparente al livello di dati e conoscenze del dominio. Lo sviluppo di sistemi con un'architettura di questo tipo è quindi poco più difficile di quello di un'architettura basata sul cliente. Symantec, per esempio, con Visual Database Development Edition [SYMANTEC] offre un ambiente di sviluppo che permette di accedere facilmente a dati relazionali remoti.

2.5.1.3 Architettura dell'insegnamento distribuito

In questo tipo di architettura, il livello di logica del sistema didattico è diviso. Una parte della logica del sistema didattico è situata sul client, l'altra parte sul server (vedi figura 4). Le richieste al livello di dati e conoscenze del dominio possono essere generate qui in base alle precedenti azioni degli utenti sul server. Anche i risultati delle richieste possono essere analizzati lì.

La selezione di una domanda di controllo delle conoscenze appropriata da una serie di domande disponibili è un buon esempio per illustrare i vantaggi di questa architettura. Le domande adatte a un utente dovrebbero avere un grado di difficoltà adeguato, dovrebbero rispondere all'attuale situazione di apprendimento e dovrebbero essere nuove per l'utente. Se non è possibile trovare una domanda di controllo delle conoscenze nella prima interrogazione al livello di dati e conoscenze del dominio, una domanda di controllo delle conoscenze può essere trovata attraverso ulteriori interrogazioni con il miglior approccio possibile ai requisiti. Se più domande soddisfano i requisiti, una delle domande può essere selezionata e inviata al cliente in base alle conoscenze del server.

Come per i sistemi Remote Data & Knowledge WBT, è possibile caricare dati e conoscenze di dominio prospettici indipendentemente dalle attività dell'utente dal server. Se sono necessari, questi dati e conoscenze sono già disponibili sul client e non devono più essere richiesti solo dal server. La velocità di reazione di un sistema può quindi essere ottimizzata. I sistemi WBT con questa architettura offrono le migliori prestazioni e il minimo carico di rete di tutte le altre architetture, ma sono anche necessari per l'implementazione. Bisogna creare due applicazioni, un'applicazione client e un'applicazione server, che devono comunicare tra loro tramite reti informatiche.

In questo tipo di architettura, solo il livello di presentazione è situato sul client. Le conoscenze di insegnamento, i dati di dominio e le conoscenze di dominio si trovano sul server. Il livello di presentazione trasmette tutte le input utente al server. Lì vengono elaborate e il risultato del trattamento viene restituito al client. Questo avviene normalmente sotto forma di un file HTML. Il vantaggio dell'architettura basata su server è che su server si possono utilizzare qualsiasi strumento di dati perso sul sito del server, senza l'indipendenza dalla piattaforma sul sito del client. Gli sviluppatori possono quindi avviare il livello di conoscenze di dominio e il sistema di insegnamento tramite questi strumenti familiari e non devono inviare nuovi strumenti in un file.

Tuttavia, i sistemi WBT con l'architettura server-based non sono molto performanti perché tutte le attività dell'utente devono essere valutate dal server (la creazione di una connessione di rete è necessaria ogni volta) e per troppi utenti contemporanei il computer del server può essere facilmente sovraccaricato, portando a scarse prestazioni dell'insieme del sistema. Un esempio di un sistema WBT con l'architettura server-based è il Interactive Patient della Marshall University [HAYES, LEHMANN 96].

L'architettura basata su server è molto adatta per rendere disponibili sistemi di tutorial intelligenti già esistenti su Internet: l'interfaccia di utilizzo di un sistema CBT convenzionale esistente deve essere sostituita da un'interfaccia di utilizzo creata con HTML, ad esempio, e deve essere collegata al livello di logica del sistema di insegnamento esistente.

Applicazione

2.5.2 Comunicazione client/server

Per la realizzazione di sistemi WBT con architettura di insegnamento distribuito occorre sviluppare meccanismi di comunicazione tra server di sistema di insegnamento/apprendimento e cliente, in particolare RMI (Remote Method Invocation) e CORBA (Common Object Request Broker Architecture).

RMI per i meccanismi di comunicazione di base sono disponibili in Java i cosiddetti socket. I socket sono molto flessibili e soddisfacenti per la comunicazione generale. Tuttavia, sia sul lato client che sul lato server i messaggi da trasmettere devono essere codificati e decodificati. Quindi deve essere progettato e implementato un protocollo per lo scambio di dati. Un'alternativa sono le chiamate di procedura remota (RPC). Ciò astraisce l'interfaccia di comunicazione al livello delle chiamate di procedura.

Gli scheletri di RMI Stubs

System Transport Layer Remote Reference Layer

Java-RMI è stato sviluppato appositamente per l'ambiente Java. Mentre altri sistemi RMIS possono essere adattati al fine di gestire oggetti Java, questi sistemi hanno svantaggi nell'ottima integrazione di Java, poiché devono mantenere l'interoperabilità con altre lingue.

Il sistema RMI è composto da tre strati:

1° strato stub/skeleton: il strato stub/skeleton è costituito da un lato client di stubs (proxies) e da un lato server di skeletons. Il loro compito consiste, tra l'altro, nel comporre e risolvere gli argomenti per il marshal stream che viene trasmesso tra i computer.

2. strato di riferimento remoto: il strato di riferimento remoto rappresenta il strato di connessione tra strato di trasporto e strato di stub/skeleton, indipendente da questi strati e responsabile dell'esecuzione della semantica di una chiamata.

3° livello di trasporto: il livello di trasporto è responsabile della costruzione della connessione e della gestione della connessione. Si basa sul protocollo TCP (Transmission Control Protocol) e utilizza Java Sockets.

Tutti e tre i strati sono completamente indipendenti tra loro e possono essere scambiati singolarmente.

Dynamic Dynamic IDL Object IDL ORB Invocation Skeleton Skeleton Adapter Stubs Interface Interface

Figura 6: CORBA (Common Object Request Broker Architecture) CORBA (Common Object Request Broker Architecture) [REDLICH 96, SAYEGH 97] si basa su un ambiente eterogeneo, multilingue, e quindi deve possedere un modello di oggetto indipendente dalla lingua. Lo standard CORBA dell'OMG (Object Management Group) definisce tra l'altro interfacce per la comunicazione tra oggetti.

L'elaborazione di un'applicazione CORBA avviene in più fasi [REDLICH 96 S. 3] ed è più impegnativa della gestione di RMI:

1. creare una descrizione dell'interfaccia per l'oggetto distante 2. tradurre la descrizione dell'interfaccia 3. implementare i server 4. registrare i server 5. implementare i clienti 6. attivare tutti i componenti (executare l'applicazione)

Poiché CORBA possiede un modello di oggetto indipendente dalla lingua, le interfacce tra gli oggetti devono essere definite con un linguaggio specifico chiamato Interface Definition Language (IDL). Da una descrizione di interfaccia viene quindi generata l'interfaccia per il linguaggio di programmazione utilizzato.

2.5.3 Integrazione delle risorse WWW esistenti

L'University of Iowa Family Practice Handbook (UNIVERSTITY OF IOWA FAMILY PRACTICE HANDBOOK) contiene anche The Whole Brain Atlas (THE WHOLE BRAIN ATLAS), collezioni di case descriptions (PITTSBURGH CASE INDEX), manuali e libri di riferimento (University of Iowa Family Practice Handbook (UNIVERSTITY OF IOWA FAMILY PRACTICE HANDBOOK) e diverse linee guida (HSHSTEL WHOLE BRAIN ATLAS) destinate a forzare l'utilizzo di sistemi virtuali e terapeutici (WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB • WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB WEB

2.5.3.1 Concetti di rappresentazione diversi Da sistemi tradizionali di ipertesto, il Web non è differente solo per la sua dimensione, la distribuzione mondiale e l'offerta spesso ridondante di conoscenze e informazioni. Una differenza importante è anche la grande varietà di concetti che utilizzano per rappresentare unità di informazione e conoscenza su nodi e bordi della base di ipertesto. Gli autori di risorse Web possono attuare i propri concetti senza limitazioni. Inoltre, possono definire qualsiasi riferimento che possa anche superare i limiti dei diversi concetti di rappresentazione e di integrazione.

2.5.3.2 Problema della granularità L'integrazione delle risorse esistenti deve evitare che gli studenti abbiano problemi di ricerca indipendente di informazioni e di conoscenze derivanti dalla descrizione insufficiente di oggetti nel Web attraverso l'ausilio alla ricerca in relazione alla grande eterogeneità dei concetti utilizzati. Sebbene il Web disponga di molte conoscenze mediche (ad esempio [HERSH, BROWN et al. 96], la ricerca di conoscenze di qualità e pertinenti risulta spesso frustrante [DETMER, SHORTLIFE 97].

Per poter guidare gli studenti al meglio, è di solito necessario un'analisi dettagliata a livello di singoli documenti, eventualmente tenendo conto dell'accesso alle risorse basato su risorse. Ma anche un'analisi della risorsa nel suo complesso serve come base di fiducia per quanto riguarda la qualità delle conoscenze esistenti tra ricercatore di conoscenze e risorsa. Poiché un cambio di risorse è spesso accompagnato da un cambio di rappresentazione e concetti di presentazione, gli studenti possono accedere consapevolmente a questi e ai nuovi concetti.

2.5.3.3 Qualità delle risorse Poiché nel Web ogni persona con un computer può essere simultaneamente autore, redattore e editore [LLAURADO 97] e mancano gli standard di qualità come quelli applicati ai mezzi di comunicazione cartacei, la qualità delle risorse mediche è molto diversa.

Molti documenti sono incompleti, fuorvianti o erratici, e spesso è difficile distinguere la farina dal grano, il utile dal dannoso [SILBERG, LUNDBERG et al. 97]. Tuttavia, in futuro il Web potrebbe imporre certificazioni di qualità come il HON Code of Conduct [HON] o il Medical Matrix Code of Conduct come standard o standard universale. Almeno questi possono fornire indizi per valutare la qualità di una risorsa da integrare. La qualità attesa di una risorsa convenzionale è il criterio più importante per la cui consultazione nel settore medico [COVELL, UMAN et al. 85].

2.5.3.4 Dynamica del Web Il Web, in quanto peculiarità, ha una dinamica molto elevata. Anche se si utilizzano solo risorse per l'integrazione che cambiano relativamente raramente, occorre comunque garantire che i cambiamenti di contenuto e di struttura pertinenti possano essere riconosciuti e presi in considerazione. Per questo, il Web dispone di un numero piuttosto elevato di strumenti tecnici (cfr. ad esempio [LINKS CHECKERS]), ma il semplice riconoscimento dei cambiamenti non è sufficiente.

2.5.3.5 Gradi di integrabilità Il grado di integrazione delle risorse esterne in WBT dipende principalmente dal metodo di accesso al documento utilizzato e si possono distinguere tre categorie:

Strutture di accesso gerarchico (strutture menù): questo gruppo di risorse è costituito da documenti di conoscenza statici e, in genere, da altri documenti ordinati gerarchicamente che consentono l'accesso tramite la navigazione. A seconda del concetto di rappresentazione utilizzato, tali risorse possono essere facilmente integrate. È possibile indirizzare e descrivere direttamente i singoli documenti. L'efficienza per l'integrazione è piuttosto elevata in quanto per determinate situazioni di apprendimento occorrono assegnare i documenti appropriati.

Meccanismi di richiesta sul lato del server: in queste procedure di accesso, un processo su un server WWW produce documenti utilizzando i parametri di richiesta. I singoli documenti non possono essere indirizzati direttamente. Tuttavia, le domande appropriate possono essere collegate a determinate situazioni di apprendimento o generate da esse. Un esempio di questa forma di integrazione è fornito dall'Atlas dermatologico online dell'Università di Erlangen-Nürnberg [BITTORF, BAUER et al. 95].

Application-driven: Application-driven document access sono applicazioni web basate, ad esempio, su linguaggi di programmazione come Java [RODGERS 96; MIDDENDORF, SINGER et al. 96] o JavaScript [FLANAGAN, KUHNERT 98]. Tuttavia, l'uso di HTML frames, plug-ins o ActiveX [SCHMITT 96] generalmente comporta anche che i singoli documenti non possano più essere descritti e indirizzati direttamente.

2.6 Indipendenza delle piattaforme

2.6.1 Portabilità

Per Balzert [BALZERT 96 S. 776] portabilità significa che i concetti utilizzati per la creazione del software di applicazione sono disponibili su diverse piattaforme di computer (di diversi produttori).

Portabilità di codice oggetto (portabilità binaria): l'applicazione fluida può essere eseguita senza ulteriori misure su diverse piattaforme. Le applicazioni Java sono caratterizzate dalla portabilità binaria. La compilazione di codice programmatico Java genera codice byte indipendente dalla piattaforma, che può essere interpretato da una Java Virtual Machine disponibile per quasi tutte le piattaforme, senza che siano necessarie modifiche al codice programmatico al momento di cambiare la piattaforma del computer.

Portabilità del codice sorgente: il codice sorgente di un'applicazione può essere trasferito da una piattaforma all'altra, dove il codice sorgente viene compilato e eseguito.

Portabilità del progetto: un'applicazione è progettata in modo che i concetti possano essere facilmente trasformati in diverse implementazioni.

L'indipendenza di piattaforma è sempre intesa nel senso di portabilità binaria, cioè che i sistemi WBT indipendenti da piattaforma devono essere in grado di funzionare su diverse piattaforme di computer senza modifiche al codice sorgente e senza ricompilazione.

2.6.2 Tecnologie di base per la creazione di piattaforme indipendenti

I sistemi WBT

In seguito, si intendono affrontare brevemente le principali tecniche di base attualmente disponibili per la creazione di sistemi di insegnamento/apprendimento indipendenti da piattaforma.

HTML: HTML [RAGGETT 97] è il linguaggio di descrizione delle pagine del World Wide Web. Serve come base per la creazione di pagine Web. Le tecniche di base di cui sopra sono incorporate nel codice HTML nei sistemi WBT. I sistemi creati vengono quindi eseguiti nella finestra del browser Web. HTML è disponibile su praticamente tutte le piattaforme e esistono strumenti molto potenti e spesso gratuiti per la creazione di documenti HTML [SCHULZ, SCHRADER et al. 97]. Anche persone senza esperienza di programmazione possono creare sistemi di presentazione senza problemi.

Java: Java [FLAGANAN 98] è un nuovo linguaggio di programmazione orientato agli oggetti con sintassi simili a C. Per l'indipendenza della piattaforma è garantito dall'interprete di byte code virtual machine (VM). Java source code viene compilato da compilatore di Java a byte code ed eseguito dalla macchina virtuale. Uno dei principali vantaggi di Java è l'eccellente supporto di rete.

JavaScript: JavaScript [FLANAGAN, KUHNERT 97] è un linguaggio di scrittura compatto, basato su oggetti2 che è stato parte integrante del browser Netscape WWW dalla versione 2.0 ed è disponibile in una piccola quantità anche nell'Internet Explorer di Microsoft. Il linguaggio JavaScript ha grandi somiglianze con Java e quindi con C, ma è più facile da imparare e programmare, poiché è necessario solo richiamare gli oggetti e le funzioni già esistenti. JavaScript è adatto solo per problemi relativamente limitati, in quanto non è arbitrariamente estensibile e di gran lunga non è flessibile come Java.

Plug-ins: i plug-ins consentono di riprodurre programmi esterni in una finestra del browser Web. Un esempio è il plug-in Shockwave di Macromedia. In questo modo i programmi creati con il Macromedia Director possono essere eseguiti anche nella finestra del browser Web. Un grosso inconveniente dei plug-ins è che devono essere scaricati e installati dalla rete prima di essere utilizzati per la prima volta.

ActiveX: Microsoft definisce le estensioni Internet del suo Component Object Model (COM) con ActiveX [SCHMITT 96]. Componenti ActiveX possono essere creati abbastanza comodamente con linguaggi di programmazione visivi come Visual Basic di Microsoft. Componenti già esistenti possono essere utilizzati senza grande sforzo anche nel Web. ActiveX ha anche diversi grossi svantaggi. Per esempio, i componenti ActiveX sono attualmente operativi solo nella piattaforma Internet Explorer di Microsoft su Windows.

CGI: la Common Gateway Interface (CGI) è un'interfaccia standardizzata dei server Web. Questa interfaccia consente di chiamare programmi esterni sul server Web. Ciò consente di ampliare la funzionalità di un server Web in qualsiasi modo. Il principale inconveniente delle applicazioni CGI è che non sono molto performanti, in quanto per ogni reazione dell'utente è necessario costruire una connessione al server. Il suo grande vantaggio è che sul lato server si possono utilizzare qualsiasi linguaggio di programmazione (dipendente dalla piattaforma) senza perdere l'indipendenza della piattaforma sul lato client.

2 JavaScript non è orientato agli oggetti. Può essere utilizzato solo gli oggetti predefiniti. Non è possibile ereditare.

2.7 Adaptività e adattabilità

L'adattabilità in relazione ai sistemi CBT comprende l'adattamento di un sistema di insegnamento/apprendimento ai suoi utenti. I sistemi di insegnamento/apprendimento adattivi sono, quindi, sistemi che si adattano automaticamente ai cambianti bisogni di apprendimento degli studenti nel corso di un processo di insegnamento/apprendimento.

I sistemi adattivi possono essere classificati in tre gruppi [KROGSÄTER, THOMAS 94]:

• Aiuti adattivi: l'aiuto è adattato al contesto del compito o a particolari preferenze degli utenti.

• Interfacce di utilizzo adattive: l'interazione uomo-computer si adatta alle particolari esigenze e preferenze di un utente.

• Applicazioni adattive: tali sistemi adattano la loro funzionalità o il modo di funzionare interno a seconda delle precedenti attività dell'utente o dell'ambiente di stato attuale.

Prima di approfondire le possibilità di adattamento dei sistemi di insegnamento/apprendimento, occorre definire i quali sono i buoni insegnanti:

Buoni istruttori sono abili a adattare il loro comportamento al particolare livello di abilità degli studenti e sia alla qualità che alla quantità delle conoscenze degli studenti. Questo adattamento assume diverse forme, tra cui: - varying the information content of descriptions and explanations; - varying the degree of detail of descriptions and explanations; - varying the aspects of the problem they focus on during a given exercise; - gradually broadening and deepening the student's knowledge in a way that builds on and refines the student's existing knowledge; - overlooking student mistakes that involve principles that the instructor judges the student to be unprepared to comprehend. [CHEIKES, RAGNEMALM 95 S. 95]

Tuttavia, la capacità degli insegnamenti/apprendimento di adattarsi ai propri studenti come un insegnante competente può essere messa in dubbio [cfr. YETIM 94 p. 34f.]. Anche Wenger [WENGER 97 p. 426] ammette che l'adattabilità, anche nei migliori sistemi di insegnamento/apprendimento attualmente disponibili, è piuttosto modesta rispetto agli insegnanti umani.

La seguente descrizione descriverà come si può caratterizzare l'adattabilità nei sistemi CBT e quali misure di adattamento sono realizzabili per i sistemi di insegnamento/apprendimento. Leutner sceglie una classificazione per tre aspetti [LEUTNER 92]:

Rate di adattamento: il tasso di adattamento indica la frequenza di tentativi di adattamento del sistema didattico ai suoi utenti.

Tipo di misura di adattamento: nell'insegnamento si possono adattare l'obiettivo di insegnamento (materiale e competenze da acquisire), il metodo di insegnamento e il tempo di insegnamento.

Metodo tempo (esempio) fisso fisso fisso selezione progressiva

Variabile Mastery Learning

Fabbricazione interna (subterranea)

Variabile insegnamento di supporto / insegnamento di supporto adattato fisso

Adattato (a fissa differenziazione esterna (scuola)

Sistema scolastico integrato adattato (metodico)

Tabella 1: Classificazione delle misure di adattamento

Se l'obiettivo, il metodo e il tempo di apprendimento sono stati fissati, l'adattamento può comportare solo l'esclusione continua degli studenti che non raggiungono gli obiettivi di apprendimento in tempo determinato. Se il tempo di apprendimento non è limitato, l'apprendimento può essere condotto fino a quando tutti gli studenti hanno raggiunto l'obiettivo di apprendimento (apprendimento che raggiunge gli obiettivi o apprendimento masterico). Se sono disponibili diversi metodi di insegnamento, allora in tempo limitato si può utilizzare il metodo di insegnamento più adatto ai bisogni dell'individuo.

Propósito di adattamento: il propósito di adattamento descrive l'uso di una misura di adattamento in generale. Salomon [SALOMON 72, citato in LEUTNER 92 S. 13] delinea tre modelli heuristici per ottenere ipotesi di interazione. Quando si utilizza una misura di adattamento per eliminare i deficit individuali dei requisiti di apprendimento attraverso l'addestramento, Salomon parla di un modello di sostegno.

Un metodo per adattare il livello di difficoltà di esempi di esercizio al livello attuale della conoscenza degli studenti suggerisce Lichtfeld, Driscoll e Dempsey [LICHTFELD, DRISCOLL, DEMPSEY 90, citato in LEUTNER 92 S. 53]: se l'utente elabora un esempio di esercizio correttamente, il sistema seleziona nel prossimo esercizio un esempio del livello di difficoltà più elevato. Se non elabora il compito correttamente, questo esempio di esercizio viene selezionato come il prossimo esempio del livello di difficoltà più basso. Gli esercizi all'interno di un livello di difficoltà sono selezionati per caso.

Molti sistemi adattivi sono non solo adattivi ma adattabili, cioè non solo il sistema si adatta ai propri utenti, ma questi possono anche adattare il sistema alle loro esigenze se non sono soddisfatti dell'adattamento automatico. Oppermann e Simm distinguono tra l'adattabilità della funzionalità e l'adattabilità dell'interfaccia utente [SCHNEIDER-HUFSCHMIDT, KÜHME et al. 93] in un sistema [OPPERMANN, SIMM 94]:

• portata delle funzioni (non tutte le funzioni sono sempre disponibili)

• Comandi personalizzati (ad esempio macros)

• Add-ins (ad esempio, chiamate tramite menù)

• Valori predefiniti per l'esecuzione di funzioni e attributi di oggetti

• Trigger: quando si verificano stati del sistema determinati dall'utente, il sistema inizia le funzioni

• accesso alla funzionalità (può essere omessa una singola funzione)

• Comportamenti di dialogo (ad esempio, soppressione di dialoghi, accensione dell'aiuto come balloon help sul Macintosh)

• Layout (es. colore delle finestre, ecc.)

• L'adattabilità delle interfacce tra piattaforme (ad esempio, il massimo tempo di doppio clic, il percorso percorso dal mouse a seconda del percorso percorso dal mouse) è un approccio per risolvere i problemi derivanti dall'insufficiente adattamento del sistema al comportamento dell'utente [PAETAU 1990 p. 271]. Gli utenti dovrebbero quindi essere in grado di attivare e attivare l'adattamento dell'insieme del sistema o di singole parti. Gli adattamenti del sistema dovrebbero essere inizialmente offerti come proposte che possono essere accettate o rifiutate.

2.8 Sistemi didattici intelligenti

Il termine "adattabilità" è usato più spesso in relazione ai sistemi di insegnamento intelligenti (ITSen) [LUSTI 92; WINKELS, BREUKER 92].

Negli anni '70, i sistemi di insegnamento/apprendimento sono stati sviluppati con l'obiettivo di programmare le regole decisionali, cioè le conoscenze decisionali, e non solo i risultati decisionali.

Tuttavia, sia ai sistemi CBT non intelligenti che ai sistemi tutoriali intelligenti devono essere presentati requisiti comuni [LARKIN, CHABAY (ed.) 92 p. 6f.]:

• Promuovere l'apprendimento attivo attraverso il sistema di insegnamento/apprendimento: gli studenti non devono prendere passivamente le informazioni leggendo testi sullo schermo o osservando animazioni, ma devono invece elaborare attivamente i contenuti di insegnamento/apprendimento, questo può avvenire attraverso la necessità di rispondere a domande o risolvere compiti (Ask, dont tell).

• realizzare interfacce di utilizzo adeguate: l'interfaccia di utilizzo di un sistema di insegnamento/apprendimento deve essere adeguata ai contenuti da trasmettere.

• apprendere a confrontarsi con i compiti pertinenti e a risolverli in modo adeguato.

• In caso di errori di inserimento, è necessario un feedback da parte del sistema.

• Le conoscenze individuali degli studenti devono essere prese in considerazione dal sistema.

2.8.1 La costruzione

I sistemi didattici intelligenti sono di solito divisi nella letteratura in quattro componenti: modulo di esperti, modulo di studenti, modulo di insegnamento e modulo di comunicazione (cfr LUSTI 92).

2.8.1.1 Modulo di esperti Il modulo di esperti rappresenta le conoscenze di un esperto umano in un settore specifico.

Se tutte le condizioni di una regola sono soddisfatte, tutte le azioni indicate vengono eseguite. Le regole sono relativamente semplici da implementare, ad esempio nel prologio, mentre la rappresentazione della conoscenza in regole presenta anche problemi su [STRASSER 92 p. 21]:

• Mancanza di flessibilità: si creano regole per una determinata classe di problemi. Le classi di problemi modificate non possono più essere risolte nonostante la conoscenza necessaria sia presente nella base di conoscenze.

• Inadeguatezza di spiegazione: le spiegazioni formulate in base alle regole sono spesso insufficienti.

• Problemi di acquisizione delle conoscenze: è molto difficile creare un sistema di regole robusto e versatile, anche perché gli esperti spesso non sono più consapevoli delle conoscenze utilizzate per risolvere un problema concreto.

• Strutture di controllo implicite: la conoscenza di dominio e la struttura di controllo sono spesso inseparabili tra loro. Di conseguenza, la chiarezza e la riutilizzabilità della base di conoscenza in altri sistemi e problemi simili sono difficilmente possibili. Le regole spesso codificano la conoscenza superficiale (shallow knowledge).

Reti semantiche: nelle reti semantiche la conoscenza è rappresentata sotto forma di un grafico composto da nodi e bordi. I nodi sono collegati tra loro attraverso i bordi. I bordi possono essere etichettati e quindi tipizzati. Come esempio, KL-ONE è un linguaggio di rappresentazione della conoscenza basato su reti semantiche. Gli oggetti sono chiamati concetti le cui proprietà sono ruoli. L'idea centrale di KL-ONE è la severa separazione di ruoli definitivi e opzionali e la distinzione tra concetti e istanze generiche.

Constrinzioni: Constrinzioni permettono di specificare le relazioni tra quantitativi mediante equazioni matematiche. Constrinzioni sono condizioni che devono essere soddisfatte dalla soluzione desiderata. Constrinzioni possono essere utilizzate solo in domini di carattere numerico.

Frames: il concetto di frame viene da Minsky [MINSKY 75]. Frames rappresentano analogie con la conoscenza dell'esperienza umana. Frames sono oggetti descritti da slot (proprietà dei frames) e facette (proprietà delle slot). Ci sono facette per il valore predefinito, il valore effettivo, la gamma di valori, ecc.

2.8.1.2 Modulo studentesco I sistemi di tutoraggio intelligenti possono essere individualizzati se sono progettati per tenere conto delle differenze tra studenti. Il processo di farlo è chiamato modellazione studentesca. Sfortunatamente, la modellazione studentesca è difficile e sempre più ricercatori stanno cercando di evitare il bisogno. [MCCALLA 92 S. 107]

Il modulo studentesco sorveglia il comportamento problem-solving di uno studente e rileva i cambiamenti. La componente principale di molti moduli studentesci è la diagnosi degli errori. Confrontando le soluzioni del modulo esperto e dell'apprendente si cerca di capire se si tratta di un errore casuale o sistematico. Se accade l'ultimo, si tenta di dare aiuta e spiegazioni mirate all'apprendente.

I principali modelli studenteschi sono gli stereotipi, i modelli di sovrapposizione, le teorie degli errori, la riparazione degli errori, la generazione degli errori e una combinazione dei modelli precedenti [REINHARDT, SCHEWE 95 S. 84] Gli stereotipi [RICH 89] sono quantità di espressioni di caratteristiche che spesso si verificano in comune nelle persone. Sono importanti perché consentono di fare molte supposizioni plausibili con relativamente poche osservazioni. Tuttavia, deve essere possibile superare queste supposizioni (inferenze) attraverso osservazioni reali. Pertanto, è necessario utilizzare tecniche per escludere ognuna di esse non monotone.

Il modello di sovrapposizione vede la conoscenza degli studenti come una parte della conoscenza degli esperti contenuta nel sistema. Poiché i modelli di sovrapposizione non richiedono conoscenza al di là del modello esperto, sono relativamente facili da implementare. Per flat knowledge nel modello esperto è necessario semplicemente abbattere i concetti conosciuti agli studenti. Qui possono anche essere attribuiti probabilità che indichino come secure il sistema sia che un concetto sia stato effettivamente compreso dall'utente. Tuttavia, è più difficile valutare se il modello esperto contiene conoscenze approfondite, come ad esempio il modello esperto NEOMYCIN per il modello GUIDON2 (Celle 89 S. 391).

I modelli di perturbazione (in inglese to perturbate = disturbare, preoccupare) servono a riflettere la visione dello studente sul modello esperto, mantenendo al contempo una stretta relazione tra studente e esperto. Il modello studente differisce dal modello esperto per errori contenuti e mancanza di conoscenza, che è anche considerato come errori contenuti nel modello. Molti ITSE utilizzano questo tipo di modello.

Secondo Woolf [WOOLF 90] i modelli studenteschi non sono ancora efficacemente integrati nei sistemi esistenti. Il problema principale della modellazione studentesca è quello di sfruttare le caratteristiche di un utente solo dall'interazione con il sistema. Spesso nei prototipi esistenti vengono identificati i parametri in cui è più facile farlo [KROGSÆTER, THOMAS 94].

Self, uno dei ricercatori più conosciuti in questo campo, raccomanda, per la creazione di un modello studentesco, di abbandonare le visioni, di scegliere obiettivi realistici e di osservare i seguenti punti [SELF 90]:

• Evitare di indovinare - far sì che lo studente ti dica ciò che devi sapere

• Dont diagnosi what you cant treat

• Empathize with students beliefs, dont label them as bugs

• Dont feign omniscience - adopt a fallible collaborator role nell'utilizzo di modelli di studenti si sono formati due punti di vista: una pagina raccomanda l'utilizzo riservato di informazioni sugli utenti di un sistema [BIERMAN, KAMSTEEG et al. 92] in quanto è difficile costruire modelli di studenti completi e corretti e utilizzarli anche correttamente. L'utilizzo riservato di informazioni sull'utente può ridurre la probabilità di errori nel sistema didattico, ad esempio la presentazione di informazioni inappropriate. L'altra pagina raccomanda un'intenso utilizzo di modelli di studenti.

2.8.1.3 Modulo didattico Il modulo didattico è incaricato, tra l'altro, di scegliere la forma di insegnamento/apprendimento più adatta e di interrompere gli insegnanti se necessario.

• apprendistato cognitivo: l'apprendista si rivolge a un esperto per risolvere compiti e può porre domande. gradualmente l'esperto consente all'apprendista di risolvere da solo compiti più piccoli. questi compiti diventano sempre più complessi fino a quando l'apprendista è finalmente in grado di risolvere con successo un compito completo.

• Successivo raffinamento: questa strategia di insegnamento è particolarmente adatta ai settori di conoscenza complessi.

• Discovery Learning: un insegnante sceglie un ambiente di apprendimento adatto alle conoscenze precedenti dell'allievo. Questo è un compito molto impegnativo. DOMINIE può solo scegliere un campo di conoscenza in cui l'allievo è nuovo ma che ha similitudini strutturali con un campo che lo studente ha già imparato.

• Discovery Assessment: questa strategia è connessa a discovery learning. Dopo aver selezionato un ambiente di apprendimento appropriato, è necessario osservare gli studenti e, se del caso, fornire assistenza.

• Abstrazione: si intende fornire agli studenti un'idea delle possibilità offerte dal sistema.

• Diagnosi Socratica: l'apprendente ha già costruito un modello del dominio della conoscenza, ma che contiene errori. Il insegnante individua questi errori e spiega al apprendente che il suo modello genera conclusioni errate e quindi errate.

• Pratica: l'allievo viene osservato mentre risolve un compito; se si allontana dal giusto modo di risolvere, riceve suggerimenti dal tutore.

• Assessment diretto: gli studenti vengono intervistati direttamente.

DOMINIE sceglie ciascuna delle otto strategie descritte in base a criteri diversi. Il sistema cerca sempre di ottenere una ragionevole ripartizione del tempo disponibile tra lezioni e prove. Da una parte, si vuole elaborare il maggior numero di materiale possibile in un breve periodo di tempo, ma dall'altra, si deve garantire che gli studenti abbiano compreso e memorizzato correttamente il materiale presentato finora. La strategia di insegnamento applicata è adeguata alla materia da insegnare e il successo dell'allievo in diverse strategie di insegnamento viene preso in considerazione dal sistema.

Nel complesso, ci sono tre modalità per raggiungere un modello di insegnamento [LEUTNER 92 p. 66]:

• L'intuizione del programmatore: gli sviluppatori di un sistema CBT si basano sull'intuizione e si basano sulle proprie esperienze con le situazioni di insegnamento/apprendimento, per esempio durante il periodo scolastico.

• Intervistare gli insegnanti esperti: eseguire un'intervista, simile a quella di intervistare e osservare gli esperti nella creazione di sistemi e sistemi di esperti basati sulla conoscenza (SPITZER, BÜRSNER 95; CHIZZALI-BONFADIN, ADLASSNIG et al. 97; PUPPE 93).

• Formazione teorica dell'istruzione: opzione di ampliamento di una teoria di apprendimento esistente a una teoria dell'istruzione o di riprogettazione di una teoria dell'istruzione.

2.8.1.4 Modulo di comunicazione Il modulo di comunicazione specifica la forma in cui il sistema comunica con gli operatori.

L'ideale è un'interfaccia utente con ingresso libero, ma l'inserimento libero è molto costoso da implementare. L'implementazione di un'interfaccia utente in lingua naturale in Sophie I richiedeva da sola due anni [LUSTI 92 S. 227]. Come alternative più facili da implementare, l'utente può anche essere offerto risposte alternative o menu di selezione.

2.8.1.5 supporto allo sviluppo L'elaborazione molto laboriosa di sistemi didattici intelligenti può essere semplificata e accelerata in due modi [LUSTI 92 S. 197]. Gli sviluppatori possono riutilizzare moduli indipendenti da oggetti di un sistema didattico esistente, come un modulo didattico o un modulo di comunicazione, e devono solo adattare il modulo esperto ai cambiamenti di compito. L'altra possibilità consiste nell'utilizzo di un shell ITS [PUPPE, GAPPA et al. 96].

2.8.2 Critica dei sistemi didattici intelligenti

Nel suo libro Basics of Hypermedial Learning Systems [SCHULMEISTER 96] il maestro di scuola esprime una dura critica agli intelligenti sistemi didattici e ai loro ricercatori e sviluppatori:

Il settore degli intelligenti sistemi didattici è apparentemente rimasto bloccato nella fase di programmazione: anche se si considerano solo gli articoli di una singola rivista sul tema ITS, si ripetono continuamente le stesse affermazioni, sistematizzazioni e riferimenti alla letteratura AI. Raramente ho visto tanta ridondanza su un gruppo, e raramente una piccola comunità di ricercatori che pubblicano continuamente la stessa cosa sullo stesso livello di sviluppo (Anderson, Brown, Duchastel, Jonassen, Lesgold, OShea, Self, Sleeman).

• Ogni sistema viene completamente rinnovato senza utilizzare vecchi componenti.

• La modularità (per il riutilizzo) non è molto diffusa negli ITS, a differenza del software commerciale.

• Lo sviluppo è ampiamente inteso come un processo di miglioramento iterativo.

• l'implementazione di pacchetti software già disponibili è impedita dal fatto che essi offrono solo un'interfaccia software esterna limitata o non esistente affatto.

• La valutazione è ostacolata a causa della mancanza di sistemi completi.

Lusti definisce le distanze di implementazione, la distanza di pratica e l'impudenza come problemi importanti nello sviluppo di ITS [LUSTI 92]. Un problema centrale è anche l'elevato sforzo di sviluppo e i costi associati alla creazione di sistemi didattici intelligenti.

Inoltre, non si sono ancora chiariti gli effetti ATI (interazioni di trattamento dell'abilità) associati agli ITS, che comprendono l'influenza dei requisiti di apprendimento individuali sul successo dell'apprendimento [LEUTNER 92], ad esempio come la risposta a diversi mezzi di apprendimento dipende da caratteristiche degli studenti come l'intelligenza o l'ansia.

Fino ad ora non è stato possibile dimostrare l'utilità del tutorial per l'ITSE o per i sistemi di esperti di uso didattico [ENGLER, FÜHRER et al. 95], a causa della complessità dei sistemi e dei dialoghi a lungo termine.

2.8.3 D3 e TRAINER

D3 [PUPPE, GAPPA et al. 96] e gli ITS-Shell TRAINER [PUPPE, REINHARDT 95] basati su di essa servono come esempio di intelligenti sistemi didattici.

• Diagnostica statistica: utilizzo della frase di Bayes.Le probabilità di diagnosi dei sintomi richieste possono essere determinate da un database di casi.

• Diagnostica basata sul caso: ricerca in database di casi simili e trasmissione della soluzione al proprio caso.

• Diagnosi heuristica: sintomi-diagnosi incatenati, solitamente con fattori di sicurezza.

• set covering-diagnosi: basato sulla copertura o sulle relazioni causali tra diagnosi e sintomi.

• Diagnostica funzionale: diagnosi basata sul modello, che descrive il comportamento dei singoli componenti.

Al momento sono già disponibili alcune basi di conoscenza medica per la D3, tra cui la reumatologia e la neurologia, che sono indispensabili per creare simulazioni di caso con TRAINER.

Il sistema offre due modalità di apprendimento: in uno il sistema presenta in sequenza le indagini suddivise da un esperto in diversi gruppi (anamnesi, esame clinico, laboratorio, ecc.) e lo studente deve formulare una diagnosi di sospetto per ogni gruppo. In un altro modo vengono citati alcuni sintomi e lo studente deve decidere quali ulteriori indagini vuole eseguire. In questo modo il sistema può criticare le decisioni prese dallo studente.

La critica più frequente di D3 riguarda la sua interfaccia di utilizzo, spesso criticata come troppo complicata e poco intuitiva nell'uso.

2.9 Modellazione dei dati semantici

Già nel 1971, l'ANSI (American National Standards Institute) X3 Committee ha istituito un gruppo di lavoro denominato SPARC (Standards Planning and Requirements Committee). L'obiettivo del gruppo di lavoro era quello di stabilire se e dove si possano definire gli standard per i sistemi di banca dati. Dopo un lungo periodo, il gruppo di lavoro ha presentato un rapporto intermedio che descrive un'architettura a tre schemi di un DBMS. La proposta ANSI/X3/SPARC consiste nel schema esterno (visto dei dati da parte dell'utente o del programmatore sui dati), nel schema concettuale (visto aziendale dei dati, descrizione del mondo ricco attraverso entità, relazioni, ecc.) e nel schema interno (visto da un modello fisico su un'organizzazione concreta).

Tipo di oggetti concettuali e relazioni tra oggetti o schema di banca dati

Relazioni logiche, attributi e integrità semanticaDatabank schema

Comando fisico e contenuto dei datiDatabase schema strutture di una banca dati

Figura 7: I tre livelli di modellazione dei dati si basano sul modello relazionale dei dati (cfr. capitolo 2.10.1) e possono essere utilizzati bene come base per la comunicazione, ad esempio, tra esperti di dominio e sviluppatori. Il modello concettuale implementato è spesso definito in letteratura come schema logico [SCHLAGETER, STUCKY 83].

Il modello di dati concettuali è molto adatto allo sviluppo del software orientato agli oggetti. Consente di modellare in modo reale, cioè gli oggetti possono essere rappresentati come li percepiamo nel nostro ambiente. Il modello concettuale può essere rappresentato utilizzando un modello ER (entity-relationship) [CHEN 76] .

Una scheda ER è composta da 5 componenti [RAUH, STICKEL 97 p. 37]:

1 Esatto designamento di schema 2 Almeno una dichiarazione di tipo di oggetto 3 Zero o più dichiarazioni di tipo di relazione 4 Zero o più regole di integrità 5 Zero o più regole di derivazione

Non tutti i componenti possono essere rappresentati con mezzi grafici, quindi l'intero schema viene definito attraverso il testo e illustrato attraverso i diagrammi. La definizione dello schema nella forma avanzata di Backus-Naur (EBNF) [VENTER] è contenuta nella tabella seguente. La definizione presentata in [RAUH, STICKEL 97] è stata ampliata con relazioni di aggregazione.

<schema> ::= schema <schemaname>; <entity set> {; <entity set>}

{;<relationship set>} {;<integrity rule>}. <schemaname> ::= <name> <entity set> ::= entityset <entity set name>

(attributi: <attribute> {, <attribute>}; identificatore: <identifier> {, <identifier>})

<subset declaration> [; attributes: <attribute>{, <attribute>} [; identifier: <identifier>

{, <identifier>}]]) <subset declaration> ::= subsetof <entity set name> ::= <entity set name> ::= <name> <relationship set> ::= relationship <relationship set name>

(participants: <participant>, <participant> {, <participant>} )

<partparticipant> ) <attribute> ::= <attribute name> <domain> [not zero] <identifier> ::= <attribute name> <attribute name> ::= <name> <relationship set name> ::= <name> <wholeparticipant> ::= <participant> ::= <partparticipant> ::= <participant> ::= <entity set name>

... <nonneg_integer> ::= 0 ̊ 1 ̊ ... <name> ::= (<letter> ̊ 2 ̊ ... ̊ 9) <letter> ::= a ̊ b ̊ ... ̊ z ̊ A ̊ B ̊ ... ̊ Z ̊ ̊ ̊ ̊ ̊ 0 ̊ 1 ̊ 2 ̊ ... ̊ 9 Figura 8: sintassi per la dichiarazione schema ER

Poiché una grammatica nell'EBNF non può prevenire tutte le formulazioni errate, occorre aggiungere alcune condizioni aggiuntive [RAUH, STICKEL 97 p. 45]:

1) Tutti i nomi degli oggetti e delle relazioni (<entity set name>,<relationship name>) possono essere utilizzati solo una volta nel schema.

3. Tutti i nomi degli oggetti citati all'interno di una dichiarazione di relazione di partecipante devono essere citati anche come nomi degli oggetti (<entity set name>). 4. I nomi degli oggetti (<role>) non devono essere omessi nella dichiarazione di relazioni ricursive. 5. Se in una dichiarazione di partecipante un tipo di oggetto si verifica più volte, un altro nome deve essere scelto per ogni evento. 6. Per le indicazioni di cardinalità (<inality>) vale la pena che il sublimitatore (<mincard>) sia sempre inferiore o uguale al limite superiore <max>. Se l'Ocard è il sublimitatore, il sublimitatore può assumere qualsiasi numero intero o uguale a zero.

Per l'aggregazione aggiunta, la seguente condizione aggiuntiva è definita: <wholeparticipant> contiene <partparticipant>, ma non viceversa.

Per la formulazione di regole di integrità in un schema ER, si deve utilizzare il Calculus Entity Relationship (ERC) [RAUH, STICKEL 97] che ha come descrizione:

La regola dell'integrità, la lista di quantificazione, la condizione, la condizione, la condizione.

<t3> <quantification list> ::= <quantification list> <quantification> <quantification> ::= (<quantifier> <variable list>) <variable list> ::= <variable list>, <name> <name> <quantifier> ::= <comparison> ::= <value> <op1> <value> <entity variable> <op2> <entity variable> <relationship variable> <op2>

<relationship variable> <value> ::= zero <text constant> <attribute variable>

<value variable> <entity variable> ::= <name> <attribute variable> ::= <construct variable> [ <attribute name> ] <construct variable> ::= <entity variable> <entity variable> ::= <name> <relationship variable>: <entity set name> <relationship variable>: <role> <condition variable> ::= <value variable> ::= <value variable> ::= <value variable> <a1> <a1> <a1> ::= <a1> <a1> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a2> <a> <a2> <a2> <a2> <a <a <a <a <a <a> <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a <a

Per quanto riguarda le regole di integrità, si accetta di non formulare esplicitamente i seguenti requisiti: essi devono essere sempre rispettati.

• I valori degli attributi derivano chiaramente dal valore dell'identificatore.

• Gli identificatori non sono mai indefiniti (zero).

• Le cardinalità delle specie di relazione indicate nella struttura di schema devono essere considerate come regole di integrità che devono essere rispettate.

Come accennato sopra, non esiste uno standard per il modello ER. Il tipo di visualizzazione grafica può quindi essere scelto liberamente. Nel lavoro vengono utilizzati i grafici di classe del Unified Modeling Language [BURKHARDT 97] noti dalla programmazione orientata agli oggetti. Questa visualizzazione grafica è stata scelta per diversi motivi.

Il sistema deve essere realizzato in modo orientato agli oggetti. Un grande vantaggio è quindi che molte costruzioni del modello ER hanno una stretta relazione con le classi necessarie per la realizzazione orientata agli oggetti. Il modello ER progettato può quindi generare in parte automaticamente le classi necessarie. Una differenza essenziale tra la modellazione di relazione entità (ERM) e l'analisi orientata agli oggetti è che gli oggetti ERM possono rappresentare solo aspetti statici come attributi e relazioni, mentre le classi possono anche contenere metodi.

2.10 Banche dati

I dati e le conoscenze presenti in un sistema di insegnamento/apprendimento devono essere conservati in modo permanente.

2.10.1 Modello di dati relativi

Per una descrizione più dettagliata, si fa riferimento alla letteratura disponibile su larga scala [ULLMAN 88; SCHLAGETER, STUCKY 83; GARDARIN, VALDURIEZ 89].

Attributo Una variabile A del tipo Attributo è definita da

In questo caso, DTYP indica un qualsiasi tipo di dati (real, string, ...), il cui intervallo di valori è indicato da WB(DTYP. WB(DTYP) include fondamentalmente anche il valore mancante ω.

La gamma di valori di A è limitata dalla quantità di condizioni di integrità semantica sib0:

WB(A) := {x ∈ WB(DTYP) ∀ sib ∈ sib0: sib(x) = true} con sib0 :

Relation schema Come relation schema viene definita la sommazione di un numero finito di attributi per attribute A: = {A1,A2,...,An}.

U WB(Ai) con a(Ai) ∈ WB(Ai), n ≥ 1 viene ripreso come n-multiplicazione di A

I dupli sono immagini che assegnano a ogni attribute del schema di relazione A un valore attuale =1.

L'intervallo di valori del schema di relazione A è definito da:

Relazione Una variabile R del tipo Relazione è definita come

La gamma di valori di R è limitata dalla quantità di condizioni di integrità semantica sib1 sopra lo schema di relazione A.

WB(R) := {x WB(A) ∀ sib ∈ sib1 : sib(x) = true} {} con sib1 : {sib sib: PM(WB(A)) → {true, false}}

PM(X) è la potenza di una quantità di X.

Schema DB Come schema DB si tratta di riassumere una quantità finita di relazioni a una quantità R:={R1,R2,...,Rm} Ri: 5(/Ai ↓ sibi1) , i = 1, ..., m; m ≥ 1 Database Una variabile DB del tipo di database è definita dal campo dei valori di DB è limitata dalla quantità di condizioni di integrità semantica sib2 sul database schema R WB (DB) := {x WB) R (R) ∀ sib ∈ sib2 : sib (x) = true} con sib2 :

UWB(Ci), con a c c c c c) : = a c), i = 1,...,I

Esso corrisponde a una limitazione della figura a a C. =1

Condizioni di integrità semantica Per semplificare la presentazione di condizioni di integrità semantica di livello 1 (sib1) sono stati fatti alcuni accordi [GERNETH 92]:

Date le variabili di relazione R: 5 (/ A ̊ sib1R) e R: 5 (/ A ̊ ̊ ̊ sib1R) con R, R ∈ R e la variabile database DB: '% ̊ R ̊ sib2)

(1) Le chiavi primarie di R possono essere controllate con la funzione booleana PS(P,x), con P ∈ A, x WB(A):

PS(P, x) : (∀ a,b ∈ x: (a{P} = b{P} ⇒ (a=b)) (∀ a ∈ x: a(P) ≠ ω)).

In condizioni di integrità semantica, la funzione booleana PS(P,x) garantisce l'unicità della chiave primaria (integrità chiave).

(2) La funzione boolean nf(B, x) (nf significa non mancante) assicura che tutti gli attributi di un'attribuzione B abbiano un valore in ogni duplice.

nf(B, x) : ∀ a ∈ x: (∀ B ∈ B: (a(B) ≠ ω)).

(3) La funzione boolean nf1(B, x) assicura che almeno un atributo di un numero di attributi B abbia un valore in ogni duplice.

nf1(B, x) : ∀ a ∈ x: ( B ∈ B: (a(B) ≠ ω)).

Per la semplificazione della specificazione di condizioni di integrità semantica a livello 2 (sib2) viene definita la funzione boolean FS(((R,P),(R,P), v) (FS rappresenta chiavi estranee). In questo caso P ∈ A, P ∈ A e v ∈ WB(R. Le chiavi estranee sono attributi che si trovano nella banca dati come attribute di chiave primaria in una qualsiasi relazione.

FS((R,P), (R,P), v) : ∀ b ∈ v(R), b(P) ≠ ω: ( b∈ v(R): (b(P) = b(P))).

Per garantire l'integrità della banca dati, non devono essere cancellati i dupli riferiti da chiavi esterne.

Discussione del modello di relazione Il modello di relazione [CODD 70] si sposta piuttosto rapidamente ai suoi limiti se si desidera modellare in modo adeguato le cose più complesse (ad esempio i grafici CAD) (cfr. LAUSEN, VOSSEN 96).

Tuttavia, per il modello di relazione esistono una vasta gamma di sistemi di gestione dei database maturati, commercialmente disponibili e ampiamente utilizzati, e esistono standard; l'utilizzo di tale sistema offre quindi il grande vantaggio di poter passare a un prodotto software di un altro produttore in qualsiasi momento senza grandi difficoltà.

2.10.2 Database orientate all'oggetto e relative all'oggetto

I database orientati all'oggetto [HEUER 92] rappresentano una seria alternativa in settori in cui i database relazionali si sono rivelati insufficienti: per esempio, i sistemi multimediali richiedono che oggetti complessi possano essere memorizzati e facilmente accessibili.

Commerzialmente sono disponibili una serie di sistemi di banca dati orientati agli oggetti, come GemStone, ObjectStore, Illustra e O2. GemStone sviluppa Smalltalk in modo da creare un sistema di banca dati. ObjectStore sviluppa C++ in modo simile. Illustra ha le sue radici in Postgres e Ingres ed è quindi l'espansione di uno dei primi sistemi di banca dati relazionali (Ingres) per l'obiettivo. O2 è un sistema di banca dati in senso classico con il proprio DDL (data definition language) e DML (data manipulation language).

Nei nuovi progetti CBTP, in futuro, si ricorreranno sicuramente più a DBMSe relativi agli oggetti quando si intende utilizzare un database. Quando si utilizzano linguaggi di programmazione orientati agli oggetti per realizzarli, l'implementazione di relazioni (complicare) agli oggetti del linguaggio di programmazione si allontana. Una delle ragioni per la diffusione, finora, di sistemi di database orientati agli oggetti è stata ridotta, oltre al fatto che le vecchie risorse di dati devono essere portate prima di essere utilizzate, la mancanza di standard generalmente riconosciuti. Gli sforzi di standardizzazione di SQL3 (Structured Query Language) e ODMG-93 (Object Database Management Group) sono stati effettuati, ma nessuno dei due standard è ancora stato approvato.

3 Progettazione e modellazione

3.1 Requisiti per i sistemi WBT

Le debolezze dei sistemi tradizionali di CBT menzionate nel primo capitolo richiedono la progettazione di nuovi sistemi di insegnamento/apprendimento. I requisiti da soddisfare dal punto di vista dell'autore e dello sviluppatore devono essere descritti di seguito [HAAG, MAYLEIN et al. 98]. Numerosi altri criteri per la qualità delle pubblicazioni elettroniche dal punto di vista del consumatore includono il catalogo di criteri per le pubblicazioni elettroniche in medicina [SCHULZ, AUHUBER et al.]. Tuttavia, il termine pubblicazione elettronica in medicina è generalmente definito come sistema WBT, in modo che non tutti i requisiti definiti possono essere applicati ai sistemi WBT.

3.1.1 Contenuto e didattico

I requisiti contenuti non sono limitati ai sistemi WBT, ma devono essere soddisfatti anche dai sistemi CBT convenzionali e da altri mezzi di insegnamento/apprendimento come i libri:

• Il gruppo di riferimento o i gruppi di riferimento per i quali un sistema è stato sviluppato devono essere chiaramente definiti e informati prima di iniziare l'elaborazione, evitando così l'insoddisfazione degli utenti di un sistema derivante dal fatto che i contenuti di apprendimento forniti non sono adeguati all'attuale livello di conoscenza degli studenti.

• Gli obiettivi di apprendimento che devono essere raggiunti con un sistema WBT devono essere chiaramente definiti e comunicati all'utente, permettendo così all'utente di decidere se, prima di modificare un sistema, si avvicinerà ai propri obiettivi di apprendimento personale.

• La larghezza e la profondità del materiale illustrato devono essere sufficienti per il gruppo di riferimento.

• Le conoscenze presenti nel sistema devono essere tecnicamente accurate e aggiornate, il che è meglio raggiunto attraverso un processo di revisione del sistema finito da parte di esperti di specialità mediche.

• La struttura didattica del sistema dovrebbe essere adeguata al gruppo di riferimento e agli obiettivi di apprendimento.

• Il sistema dovrebbe fornire un feedback adeguato per promuovere il progresso dell'apprendimento.

• Il sistema dovrebbe essere intuitivo, e l'uso di metafore può contribuire a questo.

3.1.2 Architettura

L'architettura di un sistema WBT dovrebbe soddisfare il maggior numero possibile dei seguenti requisiti:

• Alta prestazione: i sistemi WBT devono avere una buona prestazione per essere accettati dagli utenti. La performance dipende sia dalla larghezza di banda disponibile che dall'architettura del sistema.

• Basso carico di rete: un sistema WBT dovrebbe usare le risorse di rete disponibili con la massima delicatezza possibile, generalmente con conseguente miglioramento delle prestazioni dell'insieme del sistema.

• Buona riutilizzabilità: singoli componenti di un sistema WBT devono essere riutilizzabili per altri progetti con il minor sforzo possibile.

• Facilità di espansione: l'architettura del sistema WBT dovrebbe consentire di ampliare le funzionalità del sistema con il minor sforzo possibile senza influire sui contenuti didattici.

L'aggiornamento o il completamento dei contenuti di insegnamento/apprendimento dovrebbe essere semplice.

Idealmente, una componente di autore dovrebbe essere disponibile per consentire agli esperti di settore medico di aggiornare e completare rapidamente, comodamente e senza aiuto esterno.

• Adequata adattabilità e adattabilità: il sistema dovrebbe adattarsi autonomamente alle preferenze e alle esigenze personali dell'utente per promuovere il progresso dell'apprendimento, ma dovrebbe essere adattabile anche dagli utenti stessi.

• Aggiornamento automatico: le modifiche al sistema devono essere automaticamente disponibili agli utenti.

• Bassi requisiti di hardware: l'architettura del sistema dovrebbe essere scelta in modo tale da non richiedere computer di fascia alta sul lato cliente.

• Componenti multimediali: oggi gli studenti di medicina non sono più soddisfatti di sistemi di insegnamento/apprendimento che possedono solo una superficie di testo. L'uso di diversi media (testo, immagine, animazione, suono...) rende i sistemi più attraenti per gli utenti e gli effetti di apprendimento dovrebbero essere rafforzati in media didattica dopo il processo di sommazione se vengono utilizzati più canali per acquisire informazioni [WEIDENMANN 91 S. 13]. L'architettura di un sistema WBT deve supportare l'utilizzo di dati multimediali.

• Interfaccia utente ergonomica: l'interfaccia utente dovrebbe essere orientata a standard GUI comuni [MICROSOFT 95, APPLE 92], essere tenuta il più semplice possibile e consentire un'impiego intuitivo del sistema.

• Facilità di implementazione: l'architettura dovrebbe essere realizzabile con un impegno ragionevole.

• Buona integrabilità: i sistemi WBT devono essere integrabili in sistemi clinici di lavoro con un minimo di impegno.

• Componente integrato di comunicazione: la comunicazione tra gli studenti tra loro e tra gli studenti e gli insegnanti dovrebbe essere possibile direttamente dal sistema, in modo che gli utenti non abbiano bisogno di avviare ulteriori programmi per la comunicazione.

3.1.3 Tecnologie di base

La scelta di strumenti e linguaggi di programmazione appropriati è una condizione importante per la realizzazione di sistemi WBT di alta qualità.La tabella 2 presenta le principali tecniche di base (cfr. capitolo 2.6.2) e le classifica per i tipi di architettura (cfr. capitolo 2.5.1) per la cui realizzazione sono particolarmente adatte.

Java client-based, Remote Data & Knowledge, Distributed Teaching

Tabella 2: Tecnologie di base per la realizzazione di sistemi WBT

Le tecniche di base devono essere applicate:

• Ampia indipendenza da piattaforma: le tecnologie di base utilizzate dovrebbero consentire la creazione di sistemi WBT che funzionino perfettamente su più piattaforme possibili e su più sistemi operativi possibili, mantenendo il numero di potenziali utenti del sistema il più ampio possibile.

• Alta sicurezza: occorre prestare grande attenzione a questo aspetto, poiché molti dei computer utilizzati per l'istruzione medica e la formazione continua si trovano in reti cliniche in cui vengono elaborati dati di pazienti altamente sensibili; quindi occorre escludere che i sistemi WBT malvagi possano spiare i dati o causare danni ai computer che lavorano con sistemi di insegnamento/apprendimento; ciò significa che per gli sviluppatori non è consentito utilizzare tecniche di base che non hanno meccanismi sufficienti di protezione contro gli abusi.

• Alte prestazioni: le tecniche di base utilizzate dovrebbero avere elevate prestazioni.

• Supporto delle funzioni di rete: per realizzare sistemi WBT con architettura di insegnamento distribuito, è importante che le tecniche di base supportino funzioni di rete come Remote Procedure Call e simili.

• supporto multimediale: l'uso dei componenti multimediali deve essere ben sostenuto.

• Libertà di installazione: le tecnologie di base utilizzate dovrebbero consentire la creazione di sistemi WBTS che non richiedono installazione.

• Alta produttività: per limitare i costi di sviluppo, le tecniche di base utilizzate dovrebbero consentire un'elevata produttività.

3.1.4 Decisione architettonica

Il tipo di architettura è stato scelto per l'insegnamento distribuito. Questo tipo di architettura offre vantaggi di prestazione rispetto agli altri tipi di architettura presentati nel capitolo 2.5.1 a bassa banda di rete. L'implementazione più complessa rispetto alle altre architetture viene accettata, in particolare perché il concetto di insegnamento/apprendimento shell presentato nel capitolo 3.3 offre un'eccellente riutilizzabilità.

La tabella 3 valuta un'architettura di insegnamento distribuita in relazione ai requisiti specifici del capitolo 2 (cfr. HAAG, LEVEN 97). Poiché le diverse tecniche di base possono essere utilizzate per l'implementazione, la tabella contiene la valutazione dell'architettura utilizzando le tecniche di base in questione. L'HTML serve sempre come base per l'integrazione delle altre tecniche di base. Le valutazioni si riferiscono anche a implementazioni ideali, cioè la valutazione di sistemi reali può essere utilizzata in circostanze più basse di quelle indicate nella tabella.

Requisiti HTML & Java HTML & Java & HTML & Java &

RMI CORBA Piattaforma all'altezza + + frequenza Sufficiente sicurezza + + + alte prestazioni ++ ++ ++ Basso carico di rete ++ ++ ++ Nessuna installazione ++ ++ ++ Buona riutilizzabilità + + + facile espansione + + ++ Aggiornamento automatico ++ ++ ++ Basso costo / alta pro- - o funzionalità Componenti multimediali + + ergonomico utilizzatore + + area Facilità di implementazione -- o -

Tabella 3: valutazione di un'architettura ideale per l'insegnamento distribuito

Legenda: & e o soddisfacente ++ molto buono - cattivo + buono - molto cattivo

3.2 Modello di fase per lo sviluppo di sistemi WBT

Il modello di fase presentato non definisce metodi di ingegneria del software, ma si può fare riferimento ai metodi diffusi e consolidati in questo settore [BURKHARDT 97; BOOCH 94; RUMBAUGH, BLAHAUGH et al. [JACOBSON, CHELTERSON et al. 92].

I requisiti di "buona riutilizzabilità" e di "semplice espansibilità" di cui al capitolo precedente richiedono una separazione più completa possibile delle conoscenze di insegnamento (tecniche, strategie, ecc.) e dei dati di dominio, o conoscenze di dominio. Da altri modelli di fase per la creazione di software o di sistemi CBT (ad esempio [BODENDORF 90 p. 76]), il modello di fase presentato si differenzia quindi tra l'altro nella stretta separazione e l'esplicita esecuzione delle fasi di modellazione di dominio e di modellazione delle funzioni di insegnamento.

3.2.1 Analisi didattica

L'autore (specialista) deve definire gli obiettivi di insegnamento e di apprendimento, così come i contenuti di insegnamento e di apprendimento da fornire e i target target di cui si rivolge. I contenuti di insegnamento e di apprendimento dovrebbero essere strutturati in modo da essere poi presentati agli utenti del sistema CBT. Per definire gli obiettivi di insegnamento e di apprendimento si dovrebbe utilizzare una taxonomia di apprendimento (es. [BLOOM 72]). Per raggiungere questi obiettivi, i sistemi di CBT presentano cinque forme di interazione diverse con specifici stili e schede medici (capitolo 2.3.1) e, secondo il parere dell'autore, si possono scegliere gli obiettivi e i contenuti disponibili per raggiungere tali obiettivi.

3.2.2 Analisi delle esigenze

Nell'analisi delle richieste, l'autore e lo sviluppatore elaborano insieme un volantino che elenca in modo più dettagliato possibile le richieste relative alla funzionalità del sistema di insegnamento/apprendimento da realizzare, definendo con precisione come il sistema CBTS risponde alle entrate e alle attività degli utenti, specificando se e in che modo il sistema deve adattarsi agli utenti, definendo le funzioni del sistema da rendere disponibili tramite un menu o i pulsanti su pagine di schermo (ad esempio, funzione di assistenza).

Metodo fase risultato persone strumento

Il concetto didattico: (1) Analisi didattica Scopi di insegnamento/apprendimento e autore Analisi del contenuto didattico Editore di testo Forme di interazione

Documentazione: (2) Tecnica. Analisi Autore, sviluppatore RequirementAlt. analisi di testo Editore Requirements

(3) Prototyping sviluppatore, autore, metaprofesore presentazioneUtente Display layouts design GUI-builder

ERM, OOA, OOD, (4) Semant. Modello di rete sviluppatori di dominiModello di dominio

OOA, OOD, Dec.- (5) tabelle di modelli didattici ... sviluppatori di modelli didattici (modello utente) CASE tools

OOD (6) Distribuzione modello sviluppatori Distribuzione progettazione CASE-tools

(7) Programmatori di insegnamento Implementazione /Sistema di apprendimento shell ambiente di sviluppo, DDL

(8) Data e sistema di insegnamento/apprendimento Autore Riassunto di conoscenze DML, strumento di base di dati

Pagina 9 Piano di prova Procedure di prova Sviluppatore, autore, sistema di prova Protocolli di errori Utente Editore di testo

Concetto di valutazione (10) sviluppatore, autore, miglioramento pre-valutazione, editore di testo, elettronica.

Figura 10: Modello di fase per la creazione di sistemi WBT La specificazione è facilitata dal fatto che nel passaggio precedente le forme di interazione sono già state definite. Se il sistema, per esempio, ha la forma di interazione Browsing, l'autore di solito desidera una funzione di ricerca o un indice.

3.2.3 Disegno di presentazione

La prima cosa da fare è decidere se si possano utilizzare e se si dovrebbero utilizzare metafore in questa fase. La presentazione di una sala medico con diversi strumenti di studio, di un muro di libro, ecc. in cui è possibile gestire il programma attraverso la selezione di oggetti con il mouse, è un esempio di metafora. I metafore consentono anche agli utenti non esperti di computer di gestire intuitivamente un sistema CBT. Dovrebbero quindi essere utilizzati quando questo è possibile. Successivamente si può creare un layout dello schermo. Mentre l'autore inserisce le sue previsioni sull'aspetto dell'interfaccia, lo sviluppatore deve prestare un'attenzione diretta alla consistenza e al rispetto delle linee guida dell'interfaccia utente.

3.2.4 Modellazione dei domini

La stretta separazione tra dati di dominio e conoscenze di dominio, da un lato, e conoscenze di insegnamento, dall'altro, richiede la necessità di modellare questi anche strettamente separati tra loro. Si raccomanda di progettare più modelli per ridurre la complessità e rendere il modello di dominio più chiaro e comprensibile nel suo complesso. Gli strumenti che possiedono un modello di visione del controllore (MVC) sono particolarmente adatti a questo scopo. Per modelli che si sovrappongono in parte, le modifiche vengono automaticamente lasciate contemporaneamente in più oggetti davanti agli altri modelli. La conoscenza di dominio può essere rappresentata in reti semantiche.

3.2.5 Modellazione delle funzioni didattiche

La modellazione delle funzioni di insegnamento consiste nel modellare le funzioni di insegnamento elaborate e definite in collaborazione tra autore e sviluppatore nell'analisi delle esigenze. Si deve stabilire come il sistema reagisce alle azioni dell'utente o all'assenza di azioni dell'utente, se svolge un ruolo attivo o passivo nei confronti dell'utente e quando presenta all'utente quali parti dei domini e delle conoscenze contenute nel sistema. Si deve quindi modellare la conoscenza attiva e procedurale. La descrizione può essere fatta, ad esempio, mediante tabelle di decisione, regole o pseudocodi. Se si utilizza un linguaggio di programmazione obiettivo, si deve determinare quali oggetti sono adatti agli altri, quali metodi di programmazione, quali attività competenti e quali modelli di dominio che devono essere utilizzati, e, in particolare, in un sistema di modellazione automatico, che deve contenere le informazioni necessarie per l'utilizzatore, come l'idea di un modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello di modello

3.2.6 Progettazione della distribuzione

I sistemi CBT possono essere divisi in tre strati: livello di presentazione, livello di logica del sistema di insegnamento e livello di dominio dei dati e delle conoscenze [HAAG, MAYLEIN et al. 98]. Nella progettazione della distribuzione occorre decidere su quale computer (cliente o server) siano situati questi strati. Nell'architettura di insegnamento distribuito (cfr. capitolo 2.5.1.3) occorre determinare in aggiunta tutti i progetti di insegnamento (cfr. fase di modellazione delle funzioni di insegnamento) in cui sono situati.

3.2.7 Attuazione

Con l'aiuto dell'ambiente di sviluppo già scelto, viene implementato il sistema di insegnamento (solo l'interfaccia e la logica del sistema di insegnamento, la struttura del livello di dominio dati e conoscenze) e possono essere utilizzati i layout dello schermo già creati e le classi possibilmente generate nelle due fasi precedenti.

3.2.8 Data e raccolta di conoscenze

Una volta completato il shell del sistema di insegnamento/apprendimento, deve essere riempito di contenuti (domain data e conoscenze di dominio). Questo è compito dell'autore. Ora deve portare nel sistema i contenuti di insegnamento/apprendimento definiti nell'analisi didattica. Per facilitare questo compito, l'autore deve essere fornito di uno strumento appropriato. Se si utilizza un DBMS, altrimenti è necessario ricorrere ai comandi del DML (data manipulation language) di un DBMS (INSERT instructions in relational DBMS). Una volta completato l'inserimento, è disponibile un sistema di insegnamento/apprendimento completo che può essere testato.

3.2.9 Test del sistema

Al test del sistema CBT completato dovrebbero partecipare sia gli sviluppatori, sia l'autore, sia i membri del gruppo di destinazione previsto. Prima di iniziare il test, lo sviluppatore deve elaborare un piano di prova per assicurarsi che anche l'intero sistema di insegnamento/apprendimento sia testato e non solo parti di esso. I test eseguiti e gli errori verificati devono essere registrati per iscritto. Il sviluppatore può quindi rivedere il sistema in base ai protocolli di errore. Il test e la correzione degli errori vengono eseguiti fino a quando non vengono trovati più errori. Il sistema può ora essere utilizzato in pratica.

3.2.10 Evaluare

Per determinare se il sistema di insegnamento/apprendimento sviluppato raggiunge gli obiettivi di insegnamento/apprendimento definiti nell'analisi didattica, occorre effettuare una valutazione; prima, tuttavia, si deve elaborare un concetto di valutazione che descriva le domande e specifichi i metodi appropriati per rispondere a esse. L'accettazione dell'utente di un sistema o il grado di soddisfazione dell'utente può essere determinata relativamente facilmente attraverso questioni da compilare dagli utenti.

3.3 Il concetto di sistema di insegnamento/apprendimento

Se si considerano i sistemi di insegnamento e di apprendimento disponibili nel settore medico, in pratica si trovano sempre le forme di interazione o combinazioni di queste descritte in capitolo 2.3.1. Anche se i sistemi CBT con la stessa forma di interazione possono essere molto diversi nell'interfaccia di utilizzo, la funzionalità fornita è generalmente molto simile. Per esempio, nei sistemi di navigazione vi è quasi sempre un directory di contenuti e/o un'indice attraverso il quale gli utenti possono cercare informazioni in modo mirato.

La creazione di una base di conoscenze adatta anche a scopi di formazione non è quindi molto semplice e richiede un grande impegno di tempo. Per ogni area di specializzazione per cui si vuole creare un sistema di insegnamento intelligente, deve esserci una base di conoscenze in cui le conoscenze di dominio di base siano sufficientemente approfondite. Tuttavia, è molto difficile ottenere per la creazione di una base di conoscenze esperti di settori di specializzazione, con conseguente difficoltà nell'implementazione pratica di questo approccio. Il concetto di sistema di insegnamento indipendente e adattivo presentato in questo lavoro è stato quindi concepito in modo consapevole in modo da poter essere sviluppato senza una base di conoscenze sufficientemente ampia.

Per semplificare notevolmente lo sviluppo di sistemi di insegnamento/apprendimento, si propone quindi, in analogia con gli scheletri di sistema di esperto della progettazione e dell'implementazione di un sistema di insegnamento/apprendimento (cfr. capitolo 2.3.2), che consentano agli esperti di autodidazione di realizzare le funzionalità necessarie, almeno in parte, a un livello relativamente elevato di astrazione, ma che presentano anche i loro svantaggi.

In questo caso, le fasi da 3 a 7 sono già state eseguite dagli sviluppatori della Shell. La vasta disponibilità della Shell è possibile grazie alla disponibilità, oltre al sistema di insegnamento/apprendimento da creare, del componente autore indipendente da piattaforma e su Internet. Un altro importante vantaggio di un sistema di insegnamento/apprendimento è che è possibile riutilizzare il contenuto dei sistemi di insegnamento/apprendimento in modo eccezionale.

3.4 Concept CAMPUS

Per attuare le idee, i concetti e i modelli sviluppati nell'ambito di questo lavoro, è stato avviato il progetto CAMPUS (Computer Assisted Education and Training in Medicine through Platform-independent Software).

Il concetto CAMPUS deve soddisfare il maggior numero possibile dei requisiti per i sistemi WBT di cui al capitolo 3.1. Inoltre, occorre tenere conto dell'idea di un sistema di insegnamento/apprendimento (cfr. capitolo 3.3) in quanto ciò comporta alcuni importanti vantaggi, in particolare in termini di riutilizzabilità dei contenuti e di rapido creazione di sistemi di insegnamento/apprendimento.

Poiché la progettazione e l'implementazione di un'ampia shell sarebbero state un passo avanti nell'ambito di questo lavoro, le seguenti spiegazioni si concentrano sulle forme di interazione simulazione (case simulation), browsing (systematic learning) e drill & practice (questions). Tuttavia, il concetto presentato può facilmente essere ampliato per includere le forme di interazione ancora mancanti e le funzionalità aggiuntive. In particolare, si sottolinea che nella progettazione del concetto si è basato sull'idea che il sistema fosse utilizzato nell'ambito di corsi di insegnamento.

3.4.1 CAMPUS sistema di insegnamento/apprendimento

Il sistema di insegnamento/apprendimento CAMPUS è composto da quattro sottosistemi (cfr. Figura 11):

1. sottosistema di autore 2. sottosistema di apprendimento 3. sottosistema di insegnamento 4. sottosistema di amministrazione Autore di registrazione Interfaccia di applicazione Sistema di applicazione Autore di interfaccia di insegnamento Sistemi di simulazione di caso Simulazione Amministrazione di utenti lunghe / -preparazione Lexicone creazione/ Browsing Controllo di accesso -preparazione Presentazione lunghe / -preparazione sottosistema di amministrazione Tutore Dialogo -preparazioneDialogo Tutorial lunghe / -preparazione del protocollo utente Laboratorio -preparazione lunghe Drill & Practice / -preparazione Difficoltà di domande

Adaptazione riassunzione Layout creazione / sistema di adattamento - revisione

Assistenza per la registrazione dell'utente Servizio di gestione del sistema

Ricerca di casoImportazione delle risorse Difficoltà dei casi

Sottosistema di insegnamento/apprendimento Autore Sottosistema di apprendimento Sottosistema di apprendimento

Interfaccia di banca dati Interfaccia di banca della conoscenza Interfaccia di comunicazione Interfaccia di comunicazione

ICD-10 server database utente

Figura 11: CAMPUS sistema di insegnamento/apprendimento

Il sottosistema di autore [SINGER, HAAG et al. 98] permette di utilizzare i sistemi di insegnamento/apprendimento CAMPUS presso il luogo di lavoro di un docente (con diverse forme di interazione). Non richiede alcuna conoscenza informatica. Gli autori possono o dovrebbero concentrarsi completamente sul contenuto tecnico. Il sottosistema di autore è indipendente dalla piattaforma e può essere utilizzato su computer con connessione a Internet. L'utilizzo del sottosistema di autore è quindi più possibile sul posto di lavoro di un docente. Il sottosistema di autore supporta anche l'utilizzo di risorse già esistenti sul Web. È quindi possibile inserire diversi documenti HTML nella banca di conoscenze degli Stati Uniti [PELZER 98].

Il sottosistema di apprendimento consente agli studenti di accedere e lavorare con i sistemi di insegnamento/apprendimento CAMPUS. Supporta tutte e cinque le forme di interazione descritte nel capitolo 2.3.1. L'accesso è necessario per consentire al sistema CAMPUS di determinare, per esempio, quali casi di insegnamento/apprendimento sono già stati elaborati con successo, in quale semestre si trova uno studente, ecc. Il sottosistema di apprendimento presenta i casi di insegnamento/apprendimento, mostra le domande e consente l'accesso comodo alle risorse esterne su Internet e la comunicazione con docenti e colleghi tramite e-mail e IRC (Internet Relay Chat).

Il sottosistema di insegnamento è quindi responsabile dell'adattamento del sistema agli studenti (cfr. capitolo 3.4.3) e della generazione di feedback appropriati sulle azioni degli studenti. Il sottosistema di amministrazione è utilizzato per la gestione degli utenti e il controllo di accesso.

3.4.2 Modello di stratificazione

Le applicazioni client/server in cui viene utilizzato un sistema di gestione del database per la conservazione dei dati sono solitamente basate su un modello a due o tre livelli (modello a due livelli o modello a tre livelli o modello a più livelli) [KLUTE 97]. Nel modello a due livelli il client layer contiene l'intera logica del programma, compresi i driver per accedere al DBMS nel server layer. Si parla in questo contesto di fatt client. Nel modello a tre livelli viene utilizzato un modello a due o tre livelli (comunemente chiamato middleware). Il client layer completa il network layer indipendentemente dal DBMS utilizzato.

Se i dati sono utilizzati ora, essi sono già presenti sul client e non devono essere richiesti prima. Anche la divisione del livello di logica del sistema didattico in due parti (layer 2, layer 5) comporta miglioramenti di prestazione. Una parte è situata sul server, l'altra parte è situata sul client. Ciò consente di minimizzare il numero di operazioni di comunicazione necessarie e la quantità di dati da trasmettere tra i docenti / docenti e i docenti / docenti / docenti / sistema server. Un sistema didattico può essere raggiunto solo nel caso in cui il database di dati sia stato utilizzato in base ai dati utilizzatori.

Il livello di accesso alla banca dati (livello 6) è responsabile dell'accesso trasparente alla banca dati del livello di logica del sistema didattico II (livello 5) che consente di sostituire senza problemi il sistema di gestione della banca dati utilizzato in seguito.

3.4.3 Modello didattico

Il modello didattico descrive il modo in cui il sistema si adatta ai suoi utenti, cercando di promuovere al meglio il progresso dell'apprendimento.

Il sistema prevede le seguenti tipologie di adattamento:

1. Automatica inserimento di testi di aiuto per l'impiego del sistema:

Si no 2. Domande generali relative al trattamento dei casi:

Sì (difficoltà: facile, medio, difficile) No 3.

Sì (difficoltà: leggero, medio, pesante) no 4. Forma di presentazione/interazione

Total Completo Decisione Compatto 5° grado di difficoltà di insegnamento/apprendimento

leggero medio pesante

Quando si apre una finestra, l'utente viene automaticamente visualizzato l'aiuto del sistema se questo è nuovo per lui o se l'ha visto una sola volta. L'aiuto contiene istruzioni sia per l'utilizzo del programma che per l'elaborazione dei casi. Per impostazione predefinita, la pagina di aiuto è visualizzata due volte in ogni finestra. Tuttavia, questo valore può essere modificato dall'autore. Naturalmente, gli utenti possono far visualizzare le pagine di aiuto relative al contesto in qualsiasi momento cliccando sui pulsanti di aiuto.

Il sistema CAMPUS contiene due grandi quantità di domande: una riguarda le domande generali relative al trattamento dei casi, come ad esempio i test di laboratorio o le procedure di indagine tecnica; l'altra riguarda le domande specifiche relative ai casi di insegnamento/apprendimento concreti; queste domande servono, tra l'altro, ad aiutare gli utenti nel trattamento dei casi.

Domande generali Domande su casi concreti Insegnamento/apprendimento

Figura 13: Adaptazione del grado di difficoltà delle domande e dei casi di insegnamento/apprendimento

Tutti i quesiti del sistema sono assegnati a uno dei tre livelli di difficoltà (leggeri, medi, difficili). Nel caso di 1 ≤ x ≤ n e 1 ≤ w ≤ m (in caso di domande di insegnamento o di apprendimento specifico) sono determinati come segue: sulla base del numero di semestri di un nuovo utente, viene stabilito un determinato Stato di partenza x:= (numero di semestre attuale) per le domande generali e w:= (numero di semestri attuali) per le domande su casi di insegnamento o di apprendimento specifico. Nei casi di 1 ≤ x ≤ n e 1 ≤ w ≤ m (in caso di domande su casi di insegnamento o di apprendimento specifico) sono determinati i seguenti livelli:

Se una domanda viene risolta correttamente nel tempo disponibile, l'utente si trova nella condizione più elevata (x : = x + 1 o w: = w + 1). Se la risposta è erronea, viene ridimensionata a z stati (valore predefinito: z = 2) (x: = x - z o w: = w - z).

Per la presentazione di casi di insegnamento/apprendimento, sono previsti quattro diversi modelli di presentazione/interazione. Il modulo di presentazione/interazione Totale mostra un caso di insegnamento/apprendimento in forma tabellare. Oltre a tutti i risultati dell'indagine, sono inclusi tutti i diagnosi di sospetto/apprendimento da scegliere e i principi di terapia applicabili. Il modulo di presentazione/interazione Totale consente agli utenti di costruire i casi di insegnamento/interazione medica in CAMPUS e l'informazione sampolo dell'autore.

Con la presentazione delle ricerche effettuate, oltre ai risultati in formato tabellare, gli studenti imparano quali ricerche devono essere richieste per poter formulare determinati diagnosi. Dopo aver completato con sufficiente successo la presentazione/interazione di sufficienti casi di insegnamento/apprendimento, il sistema CAMPUS passa alla presentazione/interazione di decisione. In questa forma di presentazione/interazione, gli utenti devono decidere, oltre alla scelta di diagnosi di sospetto e di lavoro, quali informazioni hanno bisogno.

Il momento in cui il sistema cambia la forma di presentazione/interazione dipende da diversi fattori. Un numero determinato di casi di insegnamento/apprendimento viene visualizzato nella forma di presentazione/interazione Total (valore predefinito: 2). Il cambio tra le altre forme di presentazione/interazione avviene quando determinati traventi vengono superati sufficientemente spesso (cfr).

Decisione Punto Valore Corretta diagnosi di sospetto / diagnosi di lavoro +1 Mancanza di diagnosi di sospetto / diagnosi di lavoro -1 Completamente erroneo diagnosi di sospetto / diagnosi di lavoro -1 Per diagnosi specifica di sospetto / diagnosi di lavoro -0,25 Per diagnosi generale di sospetto / diagnosi di lavoro -0,25 Decisione di terapia acuta (corretta / errata) +1 / -1 Decisione di assistenza (corretta / errata) +1 / -1 Corrette prove Principio di terapia +1 Mancanza di principio di terapia -1 Falso principio di terapia Principio di terapia controindicato -2 Corretta domanda di contraindicazione +0,25 Corretta analisi clinica -0,25 Corretta analisi clinica +25 Corretta analisi clinica -25 Corretta analisi clinica -1,25 Corretta analisi tecnica - Corretta analisi tecnica - Corretta analisi di laboratorio -10,25 - Corretta analisi di laboratorio -10,1 Corretta analisi tecnica - Corretta analisi di laboratorio -10,25 - Corretta analisi di laboratorio - Corretta analisi tecnica - Corretta analisi di laboratorio -10,25 - Corretta analisi.

Tabella 4: punti di valutazione delle decisioni

Il modulo di presentazione/interazione completato richiede un numero minimo di punti per la somma di tutti i precedenti casi di apprendimento (valore predefinito: a = 5). Successivamente i casi di apprendimento/apprendimento vengono presentati nella decisione di modulo di presentazione/interazione. Il passaggio successivo al modulo di presentazione/interazione è compatto quando un utente ha ottenuto 2a punti. Il livello di difficoltà di casi di apprendimento/apprendimento è determinato in modo corrispondente al livello di difficoltà di questioni (vedi figura sotto 13).

L'assegnazione di singole domande su determinate situazioni nel corso del caso o su determinati nodi e capitoli nel dizionario è effettuata dagli autori. Le assegnazioni sono presentate negli attributi ObjectNr e ObjectName nei tipi NOTE e QUESTION. L'attributo boole inDiscussione del tipo QUESTION indica se la domanda appropriata deve essere visualizzata o meno nella discussione conclusiva del caso alla fine di un'elaborazione del caso.

Entityset NORDING (attributi: NORDINGNr l o n g, objectNr l o n g not zero, objectname char(50) not zero, identifier: NORDINGNr);

Entityset QUESTION (attributi: query assignmentNr l o n g, objectNr l o n g non zero,

nome dell'oggetto char(50) non zero, indiscussione bo o e n non zero, identificatore: domandaNr);

Relation NOTE_NOTE (participants: (NOTE NOTE, (1,1)), (NOTE, (0,n))

Relation QUESTION_QUESTION (participants: (QUESTION, (1,1)), (QUESTION, (0,n))

3.4.4 Modello di percorrenza dei casi

Una volta che un utente si è iscritto al sistema e ha scelto di elaborare un errore di apprendimento/apprendimento, viene presentato un paziente con i suoi dati amministrativi e i suoi antecedenti. Il nome, il sesso, l'età, l'altezza e il peso del paziente vengono indicati, nonché un'immagine che permette all'utente di ottenere una prima impressione ottica del paziente. Il processo successivo dipende dalle categorie di adattamento in cui l'utente è stato inserito dal sistema o si è inserito. In linea di principio, l'utente deve prima di tutto effettuare un'anamnesi approfondita e un'indagine clinica approfondita.

Se non è necessaria una terapia acuta, può decidere immediatamente se è necessaria un'ambulanza, un ambulatorio o un trattamento all'interno dell'istituto di terapia intensiva. Dopo che questa decisione è stata presa, devono essere richiesti specifici controlli tecnici e di laboratorio per confermare o respingere la diagnosi sospetta.

Dopo aver consultato i risultati delle ricerche richieste e dopo aver presentato il percorso clinico attraverso il sistema, è necessario decidere se il caso può essere concluso o meno. Nel primo caso, l'utente deve presentare una previsione e ricevere una breve sintesi del caso di insegnamento/apprendimento; nel caso contrario, può modificare la sua diagnosi di lavoro o il piano di terapia o richiedere nuovi studi tecnici o studi di laboratorio. Il caso di insegnamento/apprendimento viene quindi proseguito (vedi figura 14).

Presentazione del paziente (nome, sesso, età, peso, immagine)

Richieste di studio mirate (investimenti tecnici, laboratori)

Informazioni sui risultati di studi tecnici e di studi di laboratorio

Richiesta di controlli mirata

Informazioni sui risultati degli studi, storia clinica

Informazione della decisione sul sistema Necessità di informazioni Prognosi

Conclusione della decisione degli studenti

3.5 Modellazione concettuale

Nel capitolo 2.9 è stato presentato un modello a tre livelli di modellazione dei dati. Il modello prevede che prima venga progettato un modello concettuale completamente indipendente da aspetti di implementazione. Il modello concettuale del CAMPUSSistema è composto da più sottomodelli presentati nei seguenti sottocapitoli. Nella descrizione verbale dei singoli modelli vengono descritti solo gli attributi che potrebbero non essere intuitivi.

3.5.1 Modello di risultato normale

I risultati normali sono ottimi per la riutilizzazione in altri sistemi di insegnamento/apprendimento. Con la progettazione di un modello di risultati normali (vedi Figura 15) questo aspetto viene preso in considerazione. Il modello consente di riutilizzare i risultati normali senza alcun sforzo aggiuntivo. In questo modo gli autori possono ricorrere ai risultati normali esistenti in qualsiasi momento nella preparazione dei casi di insegnamento/apprendimento, senza doverli ricostruire per ogni sistema di insegnamento/apprendimento. Il sistema di insegnamento, grazie alla disponibilità di esempi normali, ha la possibilità di generare automaticamente risultati non evidenti quando non esiste un risultato per un'indagine richiesta.

Risposte non evidenti (tipo di ANAMNESENORMALWORT) alle domande di anamnesi (tipo di ANAMNESEFRAGIA) dipendono anche dal sesso e dall'aspetto del paziente (tipo di ANAMNESEFRAGIA) ma dipendono anche dalla regione del corpo (tipo di KOERPERREGION) in cui è stata eseguita l'indagine.

Nr -name di etàNr -name di etàNr -name di etàNr -name di etàNr -name di etàNr -name di laboratorioAbbreviamento di laboratorioSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaSpecial areaS

AnamneseNormale risposta_età 1..* 1..* TechnNormale riscontro_età clinicaNormale riscontro laboratorioNormale riscontro clinicoNormale riscontroNr -laboratorioNormale riscontroNr 1..* -scontro_text -minQuestione di anamnese -scontro_immagine_video -max TUntersProcedure_TecnicaNormale riscontro annamneseNr -scontro_text -questione di anamnese

Tipo di campione TecnoNormale ricerca_regione di lavoro_tipo di campioneNr domanda di anteprima_Nome di nomeNormale risposta_nome_stato di prelievo

KlinNormal find_gender 1..* LaboratorioNormal find_gender AnamneseNormal reply -anamneseNormal replyNr -infallibile_resposta

1..* AnamnesiNormale risposta_Sessore TecnoNormale ricerca -tecnoNormale ricercaNr -find_text *1 TecnoNormale ricerca_Sessore -find_image_video -sessoreNr -name -abbreviazione

Figura di associazione 15: Modello di ricerca tecnica normale 1..* Aggregation entityset ANAMNESETYP (attributi: anamnesetypNr l o n g , name char(50) non zero, identifier: anamnesetypNr (2000) non zero; entityset ANAMNESEFRAGE (attributi: anamnesetypNr l o n g , question_text ch n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

Entityset LABORNORMALBEFUND (attributi: laboratorioNormalbefindNr l o n g , befund_text ch ar(2000), min r e al , max r e al , identifier: laboratorioNormalbefindNr);

(∀l)(LABORNORMALBEFUND(l) → (l[min] == null l[max] == null) (l[min] ≤ l[max])) (∀l)(LABORNORMALBEFUND(l) → ¬(l[min] == null l[max] == null l[found_text] == null)) (∀l)

Entityset ALTERSSTUFE (attributi: etàNr l o n g, name char(20) not zero, abbreviamento char(5), di int e ger not zero,

fino a zero, identificatore: etàNr);

Entityset GESCULT (attributi: sessoNr l o n g , name char(10) non zero, abbreviamento char(5) non zero, identificatore: sessoNr);

Entityset PROBENART (attributi: campioneNr l o n g, name char(50) non zero, punto di provenienza char(50) non zero, identificatore: campioneNr);

Entityset COERPERREGION (attributi: coerperregionNr l o n g ,

nome char(50) non zero, immagine ch a r (50) non zero, descrizione ch a r(2000), ispezione bo o l e n n not zero,

l'esistenza di una relazione (participants: (ANAMNESENORMALWORT, relationship) (participants: (ANAMNESENORMALWORT, relationship) (participants: (ANAMNESENORMALWORT, relationship)), (participants: (ANAMNESENORMALWORT, relationship) (participants: (ANAMNESENORMALWORT, relationship) (participants: (ANAMNESENORMALWORT, relationship)), (participants: (participants:), (participants: (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants) (participants: (participants:), (participants:), (participants:), (participants:), (participants:), (participants:), (participants) (partici) (partici) (participants: (partici), (partici) (participants: (partici) (participants: (partici), (partici) (partici), (partici) (partici) (partici) (parti) (parti) (partici) (partici) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti)

(participants: (ANAMNESEFRAGE, (1,n)), (participants: (ANAMNESEFRAGE, (1,n)), (participants: (ANAMNESEFRAGE, (1,n)), (participants: (ANAMNESEFRAGE, (1,n)), (participants: (participants: (ANAMNESEFRAGE, (1,n)), (participants: (participants: (participants:

(participants: (ANAMNESETYP, (1,n)),

wholepartassociation CLININERSEARCHSART_KLINNORMALBEFUND (participants: (CLINERSEARCHSART, (1,n)),

wholepartassociation LABORTEST_LABORNORMALBEFUND (participants: (LABORTEST, (1,n)), (LABORNORMALBEFUND, (1,1)));

wholepartassociation TECHNONORMALBEFUND (participants: (TECHNONORMALBEFUND, (1,n)), (TECHNONORMALBEFUND, (1,1)));

wholepartassociation KOERPERREGION_KOERPERREGION (participants: (KOERPERREGION, UBERORDNETE_KOERPERREGION, (0,n)),

(COERPERREGION, UNTERORDINE_COERPERREGION, (0,1)));

wholepartassociation FACHGEBIET_FACHGEBIET (participants: (FACHGEBIET, UBERORDENTS_FACHGEBIET, (0,n)), (FACHGEBIET, UNTERORDENTS_FACHGEBIET, (0,1)));

3.5.2 Modello di caso

Il modello di caso (vedi Figura 16) descrive la struttura di un errore di insegnamento/apprendimento medico. Innanzitutto, si pensava che non esistesse ancora una soluzione universalmente accettata per un errore di insegnamento/apprendimento medico e che tutti gli approcci già esistenti per i casi di malattia elettronici [VAN BEMMEL, MCCRAY (eds.) 95; SAFRAN, RIND et al. 96] avrebbero consentito di selezionare un caso appropriato per la conservazione di casi di insegnamento/apprendimento. Purtroppo non esiste ancora una soluzione universalmente accettata per i casi di insegnamento/apprendimento medico elettronico e tutti gli approcci finora considerati non erano adatti.

L'anamnesi è composta da almeno una risposta anamnesica (ANAMNESEANTWORT), l'indagine clinica da almeno un risultato di indagine (CUNTERSERGEBNIS). Un'indagine tecnica include esattamente un risultato di indagine (TUNTERSERGEBNIS). Un'indagine di laboratorio include almeno un risultato (LABORTESTERGEBNIS) di un test di laboratorio (LABORTEST).

L'attributo FALL contiene tra l'altro l'attributo di introduzione, la sintesi e la descrizione. L'attributo di introduzione descrive brevemente la situazione iniziale all'inizio della simulazione di caso. L'attributo di sintesi contiene una discussione di caso che viene visualizzata dopo il completamento della simulazione di caso e riassume e spiega tutti gli aspetti essenziali del caso di apprendimento/apprendimento. L'attributo descrive il caso di apprendimento/apprendimento. Gli utenti possono quindi, su richiesta, selezionare i casi di apprendimento/apprendimento di cui sono interessati dalla banca dati del caso. L'attributo di introduzione dell'attributo è indicato dopo la conclusione della simulazione di caso e il risultato dell'indagine clinica (terapia di tipo CUNTERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGERGER

L'attributo di cura indica se il paziente è stato curato in ambulatorio, in camera o in ambulatorio durante un determinato periodo di tempo. L'attributo di terapia acuta indica se la terapia eseguita è una terapia acuta. L'attributo di terapia del tipo oggetto THERAPIE_THERAPIEPRINZIP contiene le informazioni se si tratta di una terapia primaria, supportiva o controindicata.

Entityset FALL (attributi: patientId l o n g, sesso ch a r (9) non zero, nome principale ch(20) non zero, cognome char(30) non zero, età di vita int e ger non zero, peso in t e ger non zero, grandezza i n t e ger non zero, immagine ch a r (50), descrizione ch ar((2000) non zero, introduzione di testo char(2000) non zero, riassunto char(2000) non zero, data di creazione d at e non zero, grado di difficoltà ch ar50) non zero, identificazione: patientId); Entityset ANAMNESE (attributi: anamneseNr l o n g , data d at e non zero, riassunto char2000) non zero, data di identificazione: annum tecnico d d n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

-anamnesi rispostaNr -paziente risposta -sintoma di ingresso -terapia_terapiaprincipio... -terapia -tipo -terapiaprincipioNr -nome -descrizione di clinicaCrossoNr -testione di clinicaCrossoNr -test_prognosticNr -prognostic_text -prognosticResultatoNr -resultato_test_resultato_immagine_video -sintoma di ingresso -diagnosticaNr -data -diagnosticaNr -elenco dei produttoriTitolo -quattroTitolo -icdCrosscode -icdSigncode -descrizione di clinicaCrossoNr -prognostic_text_prognosticNr -prognostic_prognostic_prognosticNr -prognostic_test_test -prognostic_resultatoNr -resultato_resultato_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test_test___test_____test_test____test_________test______

CliniControle_LaboratorioControle_LaboratorioControle tecnicoControle_Controle_Rezultato 1..*Controle_Controle_Rezultato 1..*Controle_NomeControle_Rezultato 1..*Controle_NomeControle_Rezultato 1..*Controle_Rezultato 1..*Controle_NomeControle_Rezultato 1..*Controle_Rezultato 1..*Controle_LaboratorioControle_Rezultato 1..*Controle_Rezultato 1..*Controle_Rezultato 1..*Controle_Controle_Rezultato 1..*Controle_Controle_Rezultato 1..Controle_Controle_Rezultato 1..Controle_Controle_Rezultato_Rezultato 1..Controle_Rezultato_Controle_Rezultato 1..Controle_Rezultato_Controle_Rezultato TTP_Rezultato 1..

Domanda di specializzazione Anamnese Domanda di specializzazione Anamnese Risposta di terapia_Principio di terapiaPrincipio di terapiaCliniCurso di prognosi Tipo di campione KUntersResultato di cliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniCliniClini

Associazione 1..* Figura 16: Caso modello aggregation entityset LABORUNTERSUCHING (attributi: lab testNr l o n g, empfaenerlabor ch ar ar ar50) entityset DIAGNOSELLING (attributi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi, diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi, diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagnosi: diagn

Entityset CLINVERLAUF (attributi: clinVerlaufNr l o n g, clinVerlauf_text char(2000) non zero, identificatore: clinVerlaufNr);

Entityset ANAMNESEANTWORT (attributi: risposta anamneseNr l o n g, risposta paziente ch a r (2000) non zero, sintomo d'ingresso boo l e n n no zero, identificatore: risposta anamneseNr);

Entityset CONTERSERGENCES (attributi: kunderresultatNr l o n g ,

risultato_text ch a r (2000) non zero, risultato_image_video char(50), sintomo di ingresso boo l e a n non zero, identificatore: kUnterresultNr);

Entityset TUNTERSERGEBNIS (attributi: tUnderresultNr l o n g, befund_text ch ar(2000) not zero, befund_bild_video char(50), identifier: tUnderresultNr);

Entityset LABORTESTERGENNIS (attributi: risultati dei test di laboratorioNr l o n g,

Valore d o u b l e, risultato_text ch a r (2000), risultato_immagine char(50), identificatore: risultato del laboratorioNr);

(∀l)(LABORTESTERGEBNIS(l) → ¬(l[resultate_text] == zero l[valore] == zero) ¬((l[resultate_text] == zero) ¬(l[valore] == zero)))

Entityset DIAGNOSE (attributi: diagnoseNr l o n g, tripartitoTitolo ch ar(255) ,

Quattro lettoriTitolo char(255), icdCrosscode char(5) non zero, icdSterncode ch ar(5), diagnoseText char(255) non zero, identificatore: diagnoseNr);

FALL_PROGNOSE (participants: (FALL, (1,1)), wholepartassociation FALL_KLINVERLAUF (participants: (FALL, (1,1)), wholepartassociation FALL_KLINVERLAUF (participants: (FALL, (1,1)), wholepartassociation FALL_KLINVERLAUF (participants: (FALL, (1,1)), wholepartassociation FALL_KLINVERLAUF (participants: (FALL, (1,1)), wholepartassociation FALL_KLINVERLAUF (participants: (FALL, (1,1)), wholepartassociation FALL_KLINVERLAUF (participants: (1,1)), wholepartassociation (1,1)), wholepartassociation (1,), wholepartassociation (1,1) (participants: (1,1)), wholepartassociation (1,), wholepartassociation (1,1) (participants: (1,n), wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas, wholepartas (participants: (1,n), (1,n), wholepartas, wholepartas, wholepartas, wholepartas, (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (n), (n), (n), (n), (n

Relation FALL_FACHGEBIET (participants: (FALL, (1,n)), (FACHGEBIET, (0,n))

(participants: (ANAMNESEFRAGE, (0,n)), (ANAMNESEFRAGE, (1,1)));

Relation CLINICAL TRADUCTIONS_CONTRUTIONS (participants: (CCINICAL TRADUCTIONS, (0,n)), (CCINICAL TRADUCTIONS, (1,1)));

Relation TUNTERSVEREN_TUNTERSERGEN (participants: (TUNTERSVEREN, (0,n)), (TUNTERSERGEN, (1,1)));

relazione LABORTEST_LABORTESTERGENNIS (participants: (LABORTEST, (0,n)),

relazione DIAGNOSE_DIAGNOSE (participants: (DIAGNOSE, (0,n)),

relazione DIAGNOSETTA_TERAPIA (participants: (DIAGNOSETTA, (1,1)),

relazione TTP_THERAPIEPRINCIP (participants: (THERAPIE_THERAPIEPRINCIP, (1,1)),

Relation LABORUNTERSURCH_PROBENART (participants: (LABORUNTERSURCH, (1,1)),

Relation CONTRACTION_COERPERREGION (participants: (CONTRACTION, (1,1)),

relationship TUNTERSERGEBNIS_KOERPERREGION (participants: (TUNTERSERGEBNIS, (1,1)), (KOERPERREGION, (0,n))

3.5.3 Modello di conoscenza del caso

Il modello di conoscenza di caso (vedi Figura 17) descrive la struttura della conoscenza di caso presente nel sistema CAMPUS. Gli autori devono indicare per tutti i risultati dell'indagine se il risultato è inconsapevole, se il risultato dell'indagine è un sintomo guida e se l'indagine corrispondente è stata necessaria (gli attributi di Boolesche sono normali, il sintomo guida e il necessario nei tipi di oggetti AMPORTAMENTE, AMPORTAMENTE, AMPORTAMENTE, AMPORTAMENTE e AMPORTAMENTE).

Un oggetto del tipo DIAGNOSIS (sospetto o diagnosi di lavoro) può essere correlato ai diversi risultati dell'anamnesi (tipo di oggetto ANAMNESEANTWORT), dell'anamnesi clinica (contrast), dell'anamnesi tecnica (contrast), dell'anamnesi tecnica (contrast), dell'anamnesi tecnica (contrast) e dell'anamnesi di laboratorio (contrast) (tra i tipi di oggetto DIAGNOSETWORT, dell'anamnesi diagnostica (contrast), dell'anamnesi diagnostica (contrast), dell'anamnesi diagnostica (contrast), dell'anamnesi clinica (contrast), dell'anamnesi tecnica (contrast), dell'anamnesi tecnica (contrast), dell'anamnesi tecnica (contrast), dell'anamnesi tecnica (contrast).

L'attributo boolesche indica se si tratta di una diagnosi sospetta. L'attributo categoria determina se si tratta di una diagnosi principale, se la diagnosi è correlata alla diagnosi principale o se non esiste o non esiste un collegamento rilevante con la diagnosi principale. L'attributo boolesche indica se si tratta di una diagnosi già presentata in passato (prima dell'inizio della simulazione del caso).

Valutamento del risultato -valutamento del risultato -normale -necessario -sintoma guida -principio della terapia -commento

Laboratorio test risultato del laboratorio_LUEvalutazione del risultato DiagnosiPrincipio della terapia_Principio della terapia

Case_Labortest DiagTherapyprinciple DiagLaborResultate_Labortestresultate -case_LabortestNr -diagTherapyprincipleNr -refusal -type of therapy -courseCase_FL -prognostica -commento DiagLaborResultate -diagLaborResultateNr -evidenza DiagTherapyprinciple_Diagnose -commento Case_DiagnoseCase 1..* DiagLaborResultate_Diagnose

Case_Tunderprocedure -case_TunderprocedureNr DiagTunderresultate_diagnosi - motivo di rifiuto

FTU_Tunderprocedure DiagName risposta_Diagnosi DiagTunderresultato -diagTunderresultatoNr DiagKunderresultato -evidenza -diagKunderresultatoNr commentoTunderprocedure -evidenza -commento

DiagTUnterresultato_TUnterresultato DiagKUnterresultato_KUnterresultato

Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi - Diagnosi

Sottoil risultato_Sottoil risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sotto il risultato_Sopporto_Sopport_Sopport_Sopport_Sopport_Sopport_Sopport_Sopport_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop_Sop

Anamnese risposta_A Risposta valutazione di risultato CUERESULTamento di risultato TUERESULTamento di risultato CUERESULTamento di risultato Nr -RESULTamento di risultato Nr -normale -normale -necessario -necessario AA Risposta valutazione -a Risposta valutazione Nr -sintomato -sintomato -normale -commento -commento -sintomato -necessario -commento

Diagnosi: -diagnosi: -diagnosi: -diagnosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi: -dignosi

L'esercizio di un'attività di diagnosi e di diagnosi di malattie e di diagnosi di malattie (attributi: diagnosi di malattie e di malattie, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia, tipo di malattia).

il commento ch a r (2000), identificatore: principio di diagnosiNr);

(∀dt) ↑ PRINCIPIO DELLA DIAGTERAPIA (dt) → ¬(dt[terapia] == zero dt[correre] == zero dt[prognosi] == zero dt[commento] == zero))

Classificazione dei risultati (attributi: valutazione del risultato, normale non zero, necessaria non zero, sintomo di guida non zero,

Commento ch a r (2000), identificatore: valutazione del risultatoNr;

ATTITUTI: valutazione del risultatoNr l o n g, normale valutazione del risultatoNr, necessaria valutazione del risultatoNr, sintomo principale di valutazione del risultatoNr, commento ch a r (2000), identificatore: valutazione del risultatoNr);

Entityset CORRECTION ALTESTIMENTO (attributi: valutazione dei risultati di corrispondenzaNr l o n g ,

normalità, necessaria, sintomo principale, commento ch a r (2000), identificatore: valutazione dei risultatiNr);

Entityset RISPONDO RISPONDO (attributi: aRISPONDO RISPONDO RISPONDO RISPONDO RISPONDO RISPONDO RISPONDO RISPONDO RISPONDO RISPONDO

normale bo o l e n non zero, necessaria b o l e n non zero, precedente bo o l e n non zero, identificatore: valutazione di diagnosi, osservazione ch a r (2000), identificatore: valutazione di rispostaNr); attributi: valutazione di diagnosiNr o n g, osservazione ch a r (2000), sospetto diagnostico bool e n non null, categoria i n t e r , passato bo o l e n non null, identificatore: valutazione di diagnosiNr); (∀d) identificatore: valutazione di diagnosiNr) identificazione di diagnosiNr > 0 di diagnosiNr di diagnosiNr o n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

relationship DIAGANAMNESEANWORT_ANAMNESEANWORT (participants: (DIAGANAMNESEANWORT, (1,1)), (ANAMNESEANWORT, (0,n));

Relation DIAGTHERAPIEPRINCIP_THERAPIEPRINCIP (participants: (DIAGTHERAPIEPRINCIP, (1,1)), (THERAPIEPRINCIP, (0,n))

Relation DIAGNOSETTA RISPONDAZIONE_DIAGNOSETTA (participants: (DIAGNOSETTA RISPONDAZIONE, (1,1)), (DIAGNOSETTA, (0,n))

Relation FALL_DIAGNOSE (participants: (FALL, (1,n)), (DIAGNOSE, (0,n))

relazione FALL_FTU (participants: (FALL, (0,n)),

relazione FALL_FL (participants: (FALL, (0,n)),

Relation FTU_TUNTERS Conduzioni (participants: (FALL_TUNTERS Conduzioni, (1,1)),

relazione FL_LABORTEST (participants: (FALL_LABORTEST, (1,1)),

wholepartassociation LABORTESTERGEBNIS_LAUERGEBNIS (participants: (LABORTESTERGEBNIS, (1,1)), (LAUERGEBNISTERGEBNIS, (1,1)));

wholepartassociation TUNTERSERGEBNIS_TUERGEBNIS (participants: (TUNTERSERGEBNIS, (1,1)), (TUERGEBNISGEBNIS, (1,1)));

wholepartassociation CONSIDERANZA_CONSIDERANZA (participants: (CONSIDERANZA, (1,1)),

(participants: (ANAMNESEANWORT, (1,1)), (participants: (ANAMNESEANWORT, (1,1)), (participants: (participants: (ANAMNESEANWORT, (1,1)), (participants: (participants:), (participants: (participants: (1,1)), (participants: (1,1)), (participants: (1,1)), (participants: (1,1)), (participants: (1,1)), (participants: (1,1)), (participants: (1,1)), (participants: (1,1)), (participants: (1,1)

3.5.4 Modello di vocabolario

Nel sistema CAMPUS esistono diversi tipi di conoscenze di dominio. Le conoscenze informative contenute nel libro didattico vengono rese accessibili agli utenti sotto forma di un ipertesto [KUHLEN 91]. Il modello di vocabolario (vedi figura 18) descrive la struttura di questo ipertesto. Un generatore [PELZER 98] consente di creare un ipertesto in formato HTML da leggere dal contenuto della banca dati in qualsiasi momento con i browser Web comuni. Con l'aiuto di un parser [PELZER 98] è possibile disaggregare i documenti HTML già esistenti in singoli parti e inserireli nella banca dati del sistema CAMPUS.

Il dizionario generato è uniforme per tutti i sistemi di insegnamento/apprendimento CAMPUS. Tuttavia, nei singoli sistemi ci sono specifici riferimenti a singole pagine o capitoli del dizionario.

Un nodo (Oggetto tipo NOTE) è composto da almeno un elemento informativo (Oggetto tipo INFOELEMENT) e esattamente una barra di navigazione (NAVIGATIONSLEISTE). Un elemento informativo può essere, per esempio, testo, immagini, suoni o video. Ogni nodo è parte di un capitolo (CAPITEL). Ogni nodo è un oggetto specifico del tipo KNOTENTYP. Un nodo contiene un numero qualsiasi di anchi (ANKER) che costituiscono il punto di partenza per i riferimenti (VERWEYPIST) ai nodi HTML. Un riferimento è un tipo specifico di riferimento (VERWEYPIST). Le liste di navigazione sono costituite da almeno un nodo di navigazione (NAVIGATIONS).

Il vantaggio di questa soluzione è che, indipendentemente dall'editore HTML utilizzato e dalla versione HTML utilizzata, è sempre garantito che un documento HTML importato possa essere ripristinato nel suo layout originale [PELZER 98]. L'attributo elementare nel tipo di oggetto ANKER indica se l'ancora è ancorata ad un elemento informativo o ad un elemento di navigazione. Gli attributi di target anchor, rel, rev e title sono attributi opzionali del tag <A> di HTML. L'attributo di orientamento nel tipo di oggetto NAVIGATIONSLEISTE include le informazioni se la barra di navigazione viene decentrata, sinistra o a destra. L'attributo di orientamento esterna decide se la barra di navigazione è decentrata o verticale.

-referenceNr -knotNr -date di creazione -url -anchorNr -date di creazione -element-type -elementNr -anchorposition1 -anchorposition2 -target anchor -rel -rev -title -infoElementNr -date di creazione -name -path -element-type -format -short description -navigationselementNr -description -icon -reference-typeNr -name -description-positionNr -orderpositionNr -capitoloNr -capitoloInfo -name -knotNr -name -datum -direction -knot-type -navigation-listNr -noot-typeNr -knot-typeNr -anchor-typeNr -anchor-typeNr-typeNavigation-typeNavigation-typeNavigation-typeNavigation-pointNavigation-pointNavigation-pointNavigation-pointNavigation-pointNavigation-pointNavigation-point

Noten_Navigationbar Noten_Anker Noten_InfoElement entityset Noten (attributi: knotenNr l o n g, name char(255), date di creazione d at e not null, path char(50) not zero, knotenart char(50) not zero, identifier: knotenNr); (∀k) KNOTEN(k) → k[knart] = RestHTML k[knart] = Sonstiges) toglie Noten HYP (attributi: knotenNr l o ng , name char not zero, description ch50) non zero, identifier: knotenart ch50) non zero, identifier: knotenart d r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r r

Entityset CAPITEL (attributi: capitolo nr l o n g, capitolo voce i n t e r , nome char(80) non zero, identificatore: capitolo nr);

(∀k1, k2)(capitale(k1) capitale(k2) k1 [capitale] = k2 [capitale] → k1 == k2)

Entityset NAVIGATIONSLIST (attributi: barra di navigazioneNr l o n g, orientamento char(1) non zero,

livello di orientamento char(1) non zero, identificatore: barra di navigazioneNr);

(∀n) NAVIGACIONE LISTINA (n) → n[incoraggiamento] = l n[incoraggiamento] = r n[incoraggiamento] = c)

(∀n) LINE DI NAVIGACIONE (n) → n[livello di orientamento]= h n[livello di orientamento]= v)

entityset POSITION (attributi: posizioneNr l o n g ,

posizioni di ordine i n t ege r not zero, identificatore: posizioniNr;

(∀p1, p2)(POSITIONE(p1) POSITIONE(p2) p1 [positione di ordine] = p2 [positione di ordine] → p1 == p2)

Entityset NAVIGATIONSELEMENT (attributi: navigationselementNr l o n g , marcatura char(10), icon char(50), identificatore: navigationselementNr);

(∀n)(NAVIGATIONSELEMENT(n) → ¬(n[descrizione] == zero n[icon] == zero) ¬(¬n[descrizione] == zero) ¬(n[icon] == zero)))

Entityset INFOELEMENT (attributi: infoElementNr l o n g, data di creazione char(10) non zero,

nome char(30), percorso char(50) non zero, elementar ch ar(15) non zero, formato char(15) non zero, abbreviamento ch a r (2000), identificatore: infoElementNr); wholepartassociation KAPITEL_KNOTEN (participants: (KAPITEL, (0,n)), (KNOTEN, (1,1)); wholepartassociation KAPITEL_KAPITEL (participants: (KAPITEL, (0,n)), (KAPITEL, (0,1))); wholepartassociation KNOTEN_ANVERKER (participants: (KAPITEL, (0,n)), (ANKER, (1,1)); wholepartassociation KNOTEN_ANVERKER (participants: (0,n)); wholepartassociation KNOTEN_KNOTEN_NAVIGATIONS (0,n), (0,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n) (n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1,n), (1, (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (n), (1,

-layoutNr -headline -footline -backgroundcolor -technFormulareNr -date di fabbricazione -formulare-head -backgroundcolor -formulare-scherm... -labor formulareNr -date di fabbricazione -formulare-head -backgroundcolor -formulare-scherm... -numero di colonne -formulare-positionNr -colonna-position -sequenza-position -part-formulare-formulare-scrizione 1..* 1..*WBT_System Layout

3.5.5 Modello di layout

Gli autori possono definire i propri layout per i formulari di laboratorio (oggetto tipo LABORFORMULAR) e per i formulari tecnici (oggetto tipo TECHNFORMULAR). I formulari di laboratorio possono essere composti da più sottoformulari (TEILFORMULAR).

Formulario_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo_Posizione del modulo

Gli autori hanno quindi la possibilità di influenzare in misura determinata l'aspetto dei sistemi creati e, soprattutto, di disegnare i moduli di interfaccia in modo da essere utilizzati nel proprio ospedale, consentendo di raggiungere una maggiore vicinanza alla realtà delle simulazioni di caso. Tuttavia, l'aspetto delle finestre del sistema di insegnamento/apprendimento (ad esempio, arrangiamento dei pulsanti, disegno di colore, ripartizione, ecc.) non può essere influenzato. Questo è stato fatto per due motivi:

entityset LABORFORMULAR (attributi: lab formNr l o n g , data di creazione char((2000) not zero, formula head char((50), colore di fondo c h a r (15), formula letteratura char(80) not zero, numero di spaziatura i t e g e r r r n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

relazione TECNOLOGIA_TECNOLOGIA (participants: (TECNOLOGIA, (1,1)), (TECNOLOGIA, (0,n));

Relation WBT_SYSTEM_LAYOUT (participants: (WBT_SYSTEM, (1,1)), (LAYOUT, (0,n))

relazione FORMULARPOSITION_TEILFORMULAR (participants: (FORMULARPOSITION, (1,1)), (TEILFORMULAR, (1,n));

Relation LABORUNTERSURCHING_LABORFORMULAR (participants: (LABORUNTERSURCHING, (1,1)), (LABORUNTERSURCHING, (0,n))

(participants: (LABORFORMULAR, (1,n)),

3.5.6 Modello utilizzatore

Il modello utente (vedi Figura 20) descrive le preferenze degli utenti e il loro utilizzo precedente del sistema CAMPUS.

Un oggetto del tipo UTILIZATORE è costituito da un numero qualsiasi di eventuali elaborazioni di caso (oggetto di tipo HILFETEXT). L'attributo dell'oggetto di tipo HILFETEXT determina l'evento in cui viene visualizzato l'attributo di aiuto (attributo di aiuto), il protocollo di aiuto (attributo di aiuto) e le visite di nodi (NOTE). Ogni oggetto del tipo HILFEPROTOKOLL è assegnato esattamente un oggetto del tipo HILFETEXT. L'attributo dell'oggetto di tipo HILFETEXT determina l'evento in cui viene visualizzato l'attributo di aiuto (attributo di aiuto). Ogni utente possiede un'attributo di identificazione prospettiva (attributo di aiuto) e un'attributo di risposta (attributo di risposta).

L'attributo totaleNurPatho contiene l'informazione su se l'utente riceve l'annuncio solo dei risultati notevoli nel formulario di presentazione/interazione Totale. Il modello utente è un modello di assegnazione semplice [BODENDORF 90 S. 132]. A seconda del numero di insegnamenti/lezioni correttamente elaborati, delle domande correttamente risposte e del numero di semestri attuali, l'utente viene suddiviso in diverse categorie (attributo guida di servizio, formulario di presentazione, domande, punto di registrazione).

Utente -utente -identificazione -password -e-mail -elaborazione del caso Protocollo di aiuto -data di registrazione -data di elaborazione del casoNr -successo -numero di semestre -data di elaborazione -loginDato -talk -ora di utilizzo -forma di presentazione -questioni -quadro di registrazione -ora di adattamentoActivato -prospettiva -carica -totalNurPatho protocollo di aiuto_testo di aiuto

Trattamento di domandeTesto di aiuto - Trattamento di domandeNr -Testo di aiutoNr -Successo -Evento -Tempo di trattamento -Testo di aiuto -Tempo di visita di nodo -Tempo di visita di nodoNr -Tempo di soggiorno

In ogni caso di elaborazione e di elaborazione delle domande viene determinato il successo, la durata dell'elaborazione e il tempo (attributi successo, durata di elaborazione, tempo). Durante la visita al nodo vengono determinati il tempo e la durata del soggiorno (attributi tempo, durata di soggiorno). Quando si inseriscono pagine d'aiuto viene protocollato la data (attribute datum). Sulla base di tutte queste informazioni, il sottosistema di insegnamento può selezionare gli opportuni casi di insegnamento/apprendimento e domande e, se necessario, offrire l'aiuto appropriato.

g, successo reale non zero, durata di elaborazione int e ger non zero, tempo di data non zero, identificatore: caso di elaborazioneNr); entityset QUESTION (attributi: domanda di elaborazioneNr l o n g, successo b o o l e n n n n n n n n n l, durata di elaborazione int e ger non zero, tempo di elaborazione int e ger non zero, identificatore: domanda di elaborazioneNr); disset NOTE USU (attributi: visita di nodoNr l o n g , tempo di data non zero, durata di soggiorno intitys eger non zero, identificatore: visita di nodoNr);

Entityset HILFEPROTOKOLL (attributi: protocollo di aiutoNr l o n g , data d at e not zero, identificatore: protocollo di aiutoNr);

Entityset HILFETEXT (attributi: helfetextNr l o n g, evento char(50) non zero, helfetext char(2000) non zero, identificatore: helfetextNr);

relazione HILFEPROTOKOLL_HILFETEXT (participants: (HILFEPROTOKOLL, (1,1)),

(participants: (User, (0,n)), (FALSE, (1,1)));

wholepartassociation USER_QUESTION (participants: (USER, (0,n)), (QUESTION, (1,1)));

(participants: (User, (0,n)), (Notes, (1,1)));

wholepartassociation NUTZER_HILFEPROTOKOLL (participants: (Utente, (0,n)), (HILFEPROTOKOLL, (1,1)));

3.5.7 Modello di domanda

Il modello di domanda (vedi figura 21) descrive le domande e i relativi tipi di risposta.

Nr -name domanda -dilimitazione -questioneNr -questione testo -data di realizzazione domanda_difficultà -immagine -maxTempo di risposta

Tipo di risposta -tipo di rispostaNr -name domanda_categoria di domanda domanda_risposta

Categoria di domanda Risposta_RispostaTip 1..* -categoria di domandaNr -name Risposta -descrizione -rispostaNr -commento

RispostaImmagine -numero di etichetta RispostaMC -corretto_risposta -risposta -correttezza

RispostaTesto di localizzazione -corre_risposta -numero di localizzazione Risposta Ordinazione -tipo -posizione RispostaSelezione -termine_icona -risposta -correttezza

Risposta di abbinamento Risposta alternativa -concept_a -true_response -concept_b -false_response Un oggetto del tipo QUESTIONE possiede gli attributi data di creazione, testo della domanda, immagine (riferimento ad un'immagine eventualmente associata alla domanda) e maxResposizione (massimo tempo di risposta).

• Introduzione gratuita (RISPONDO GRATUITO)

• Risposte alternative (ANTWORTALTERNATIVE)

• Menù di selezione (RISPONDO)

• Multiple choice (ANTWORTMC)

• Corrispondenza (ANTWORTMATCHING)

• descrizione dell'immagine (RESPONDAZIONE dell'immagine)

• Ordinazione dei termini/iconi (ORDINI ANTRO)

• L'interrogativo (ANTWORTLUECKENTEXT) Ogni domanda è inoltre assegnata con precisione a un livello di difficoltà (SIGURITÀ), con precisione a una categoria di domande (CATEGORIA DELLE QUESTIONI) e con precisione a un tipo di risposta (ANTWORTTYP).

Le otto diverse tipologie di risposte supportate dal sistema consentono agli autori di elaborare domande di controllo delle conoscenze e domande di supporto per il caso specifico.

Entityset QUESTIONE (attributi: domandaNr l o n g,

testo della domanda, 2000) non zero, data di creazione non zero, immagine n° 50), massimo tempo di risposta, identificatore: domanda n° 50);

Entityset ANTWORTTYP (attributi: tipo di rispostaNr l o n g ,

nome char(30) non zero, vantaggi char(2000) non zero, svantaggi char(2000) non zero, identificatore: tipo di rispostaNr);

Entityset SIGURITY STUDY (attributi: difficulty levelNr l o n g, name char(30) non zero,

allineamento char(2000) non zero, identificatore: difficoltàNr); entityset FRAGEKATEGORIE ANTWORTBILDB ANTWORT (attributi: fraggekategorieNr l o ng , name char(30) non zero, descrizione ch ar(2000) non zero, identificatore: fraggekategorieNr); entityset ANTWORT (attributi: antwortNr l o n g , comment ch a r (2000) non zero, identificatore: antwortNr); entityset ANTWORTBILDB ANTWORT (attributi: subset of antwortNr l o ng , name char(30) non zero; entityset boolean ANTWORTSETTE (subset of antwortNr l o n g , comment comment ch a r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r o r

Entityset ANTWORTALTERNATIV (subset of ANTWORT, attributes: right_response ch ar(200) not zero false_response ch ar(200) not zero)

relazione ANTWORT_ANWORTTYP (participants: (ANTWORT, (1,1)), (ANTWORTTYP, (0,n));

(participants: (QuESTO, (1,1)), (CESTO, (0,n));

(participants: (QUESTIONE, (1,1)), (QUESTIONE, (0,n))

(participants: (QuESTO, (1,n)), (RESPONDO, (1,1)));

Solo un tipo di risposte è ammesso per domanda: (∀f,a1,a2) (FRAGUE(f) f[RESPONDO(a1)] f[RESPONDO(a2)) ¬(a1==a2) → ( aat1, at1) ANTWORTTYP(at1) ANTWORTTYP(at1) aat1:RESPONDO==a1 aat1:RESPONDO==a1 aat1:RESPONDO_RESPONDO == at1 TT aat2, at2) (ANTWORT_ANTWORTTYP(aat2) ANTWORTTYP2) 2:RESPONDO==a2 2:RESPONDO==a2 aat2:RESPONDO

3.5.8 Modello di sistema WBT

Il modello del sistema WBT (cfr. figura 22) descrive i componenti di un sistema di insegnamento/apprendimento CAMPUS e i relativi elementi, tenendo conto solo delle forme di interazione: simulazione (case simulation), browsing (systematic textbook knowledge) e drill & practice (questions).

Un sistema WBT (object type WBT_SYSTEM) può contenere un certo numero di insegnamenti/apprendimento (FALL) e domande (FRAGE) e deve essere associato ad un certo numero di nodi (LAYOUT). Un autore può invece creare o modificare un certo numero di sistemi WBT e un layout può essere utilizzato per un certo numero di sistemi WBT. Un sistema WBT può contenere un certo numero di insegnamenti/apprendimento (FALL) e domande (FRAGE) e deve essere associato ad un certo numero di nodi (NOTEN).

WBT_System_Nodes WBT_System_User 1..* WBT_System_Layout

WBT_System_Author 1..* -wBT_SystemNr Autor -name -authornr -date of creation -name -name identification 1..* 1..* -password entityset WBT_SYSTEM (attributi: wBT_SystemNr l o n g, name char(80) not null, date of creation d at e not null, identifier: wBT_SystemNr); entityset AUTOR (attributi: autornr l l o n g, name charnr -date of creation -name -name -identification 1..* 1..* -password entityset WBT_SYSTEMNr l o n g, name charnr) not null, pass h r a r (15) not null, relationship identifier: (0,), relationship (0,), relationship (0,), relationship (0,); WBT_SYSTEMSTEMSTEMSTER (0,), relationship (0,), relationship (0,), relationship (0,), (participants), (1,), (participants), (participants), (participants), (participants), (participants), (participants), (participants), (participants), (participants), (participants), (participants),), (participants), (participants), (participants), (participants),), (participants), (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti), (parti) (parti) (parti) (parti) (parti) (parti) (parti), (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti) (parti

4 Realizzazione

4.1 Strumenti e tecniche di base

Nella progettazione del sistema si è concentrato sull'utilizzo più ampio possibile di standard, con vari vantaggi: ad esempio, le singole componenti del sistema possono essere riutilizzate meglio e un cambio di strumenti e ambienti di programmazione è facilmente possibile se necessario. Come lingua di programmazione viene utilizzato il linguaggio di programmazione oggettivo Java [GOSLING, Ylattin et al. 97a,b]. Come ambiente di sviluppo vengono Symantec Café e Symantec Visual Café [SYMANTEC] e il JDK (Java Development Kit) di Sun. Per l'implementazione del sistema di insegnamento 1.1 e del sottosistema di apprendimento, viene utilizzato un primo livello di linguaggio che è stato completamente inserito nel sistema di programmazione JPLUS 1.1 .

DBMS CAMPUS (es. Oracle RMI Registry insegnamento/apprendimento- 7.3) CAMPUS systemclient ICD-10 server

Figura 23: Integrare i sottosistemi di insegnamento e apprendimento CAMPUS in un ambiente software standard

I dati e le conoscenze sono memorizzati nel relational database management system ORACLE 7.3 [HERRMAN, LENZ et al. 97]. L'ORACLE è stato scelto perché è affidabile e molto potente. Inoltre, ORACLE è disponibile per una vasta gamma di diverse piattaforme hardware. Inoltre, ora ORACLE 8 è disponibile con un successore relazionale agli oggetti. ORACLE 8 offre la possibilità di mettere a punto una visione oggettiva sulle relazioni esistenti. Il DBMS può essere inserito su richieste di oggetti complessi. L'accesso di linguaggi programmatici oggettivi come Java è semplificato.

4.2 Sottosistema autore

Il sottosistema di autore consente agli esperti di competenza di creare sistemi di insegnamento/apprendimento in modo confortevole, senza bisogno di alcuna conoscenza informatica e in grado di concentrarsi pienamente sugli aspetti contenutivi e didattici. L'implementazione è stata avviata in una pratica software del corso di studi di informatica medica e continuata in due lavori di laurea [SINGER 98; PELZER 98] che hanno portato ad un prototipo che, tuttavia, ha ancora bisogno di ulteriore sviluppo. Nella prima fase di sviluppo del sottosistema di autore vengono realizzate quelle parti del sistema che saranno utilizzate per la creazione di simulazioni di casi, per la creazione del lezionario CAMPUS e per la creazione di domande.

Per indicare le conoscenze di diagnosi differenziale, il sottosistema di autore dispone delle categorie di evidenze di cui alla tabella 5. Come accennato in capitolo 3.5.3, indicare le conoscenze di diagnosi differenziale non è un requisito obbligatorio per la funzionalità di un sistema di insegnamento/apprendimento CAMPUS.

p3 = sicuro n3 = chiude da p2 = parla fortemente per n2 = parla fortemente contro p1 = parla fortemente contro n1 = parla contro

Tabella 5: Categorie di prove nel sistema CAMPUS

Il vocabolario CAMPUS ha la seguente (grossa) classificazione (ciascuno con sottotitoli):

• Descrizioni della malattia [KNAUP 94]: definizione, epidemiologia, informazione generale, patogenesi, etiologia, anamnesi, sintomi, diagnostica apparata, laboratorio, risultati istologici, diagnosi differenziali, terapia, percorso, prognosi, profilassi

• terapie (descrizione delle terapie)

• Anamnesi (presentazione di diverse tecniche di anamnesi e domande di anamnesi)

• l'indagine clinica (dichiarazioni sull'indagine clinica)

• controllo tecnico (descrizione delle procedure di controllo tecnico)

• L'analisi in laboratorio ( spiegazioni di diverse prove di laboratorio) Basandosi su questa classificazione, gli autori di specialità possono fornire conoscenze didattiche. Naturalmente, gli autori sono liberi di perfezionare e completare ulteriormente la classificazione proposita sopra. L'acquisizione di pagine HTML già disponibili è possibile [PELZER 98].

Gli autori possono creare confortevolmente domande di controllo delle conoscenze e domande per supportare l'elaborazione di casi di insegnamento/apprendimento, con un totale di otto diversi tipi di risposta, ognuno dei quali ha caratteristiche di punti di forza e di debolezza (vedi tabella 6).

Il tipo di risposta i vantaggi e gli svantaggi L'apprendimento non è problematico per l'analisi delle risposte, in quanto le specifiche delle risposte sono

L'autore deve tenere conto di tutte le possibili risposte.

Alternativa Ottimale tipo di risposta per Solo per un numero molto limitato di domande risponde alle quali sono adatte solo due delle domande. Ci sono solo risposte brevi impossibili.

Selezione di un menù adatto alle domande alle quali le risposte sono

Le risposte in parola facilitano la risposta e possono essere valutate. Solo brevi possibili risposte possono essere indicate.

Le risposte predefinite possono essere utilizzate

Anche i testi più lunghi includono la risposta facilitata.

Matching bene adatta per il contronore adatta per un numero molto limitato di assegnamento laterale di questioni di movimento.

L'immagine può essere scansata dall'autore con l'aiuto di un'autrice di un'immagine (per esempio, un'immagine deve essere scansata con l'aiuto di un'autrice di un'immagine) o di un'immagine (per esempio, un'immagine deve essere scansata con l'aiuto di un'autrice di un'immagine).

Un grafico deve essere dotato di etichette.

Ordinazione da parte di BeFor la consultazione da parte di AbläuNur per un numero molto limitato di interrogazioni/iconi, passi di lavoro, ecc. di domande adatte.

L'interrogazione di commenti è appropriata solo per un numero molto limitato di domande.

Tabella 6: Tipo di domanda/risposta nel sistema CAMPUS

Tutti i quesiti devono essere assegnati dagli autori a uno dei tre livelli di difficoltà. Il livello di difficoltà comprende facilmente le conoscenze di base che ogni studente di medicina dovrebbe essere in grado di rispondere a partire da un semestre determinato e che non prevedono una comprensione più profonda di un campo di specializzazione.

Per quanto riguarda l'attuale stato di sviluppo del sistema CAMPUS, l'autore può assegnare domande a un gran numero di situazioni e oggetti diversi.

4.3 Sottosistema di apprendimento

Il sottosistema di apprendimento fornisce agli studenti l'interfaccia di utilizzo del sistema CAMPUS ed è completamente situato sul computer cliente. Prima di lavorare con CAMPUS, un utente deve accedere al sistema e scegliere uno dei sistemi di insegnamento/apprendimento CAMPUS disponibili.

Figura 24: Adaptazione del sistema CAMPUS

Il dizionario rappresenta un libro didattico strutturato (ipertesto) per gli studenti, utilizzato in genere per poter leggere rapidamente singoli dettagli durante la lavorazione di simulazioni di casi o rispondere alle domande (ad esempio, sulle correlazioni tra sintomi e diagnosi, la frequenza di determinati diagnosi o i vantaggi e svantaggi di determinate procedure di indagine). Gli utenti hanno quindi accesso a conoscenze sistematiche in qualsiasi momento.

Per affrontare il problema dell'ingresso di testo libero di diagnosi, è stato implementato un server ICD-10 in un lavoro di laurea [RIEDEL 98] che consente di inserire diagnosi come testo libero e quindi di scegliere i diagnosi desiderati tra i tre e i quattro campi ICD-10 trovati.

Figura 25: Dialogo sulla chiusura dei diagnosi secondo ICD-10

4.4 Sistema di insegnamento

Il sottosistema di insegnamento genera adeguate risposte alle azioni degli utenti e è responsabile dell'adattamento del sistema CAMPUS ai suoi utenti. Inoltre, garantisce la corretta sequenza di casi sulla base del modello di sequenza di casi presentato nel capitolo 3.4.4. Un esempio della classe LERER è l'oggetto centrale del sottosistema di insegnamento di CAMPUS. Un insegnante (classe LEHRER) è composto da diversi oggetti responsabili di attività specifiche, in parte situati sul server del sistema di insegnamento/apprendimento CAMPUS e in parte sul sistema di insegnamento/apprendimento CAMPUS.

Assessore di aiutoSelector di caso richiestoNome di rispostaSelezione di testo di aiuto +Selezione (long nId) richiestoCliniche ricerche +setTesto di aiuto (string event) +Protocollare (long nId, long patientId, real success, long processing...) richiestoTestiche ricerche +Aiuto (string event) +get DeterminatoFall (long patientId) -Selezione di laboratorio +Selezione di utenti (long nId) richiestoCliniche ricerche +setTesto di aiuto (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocollare (string event) +Protocolleggio) -Protocolleggio -Protocolleggio -Protocolleggio -Protocolleggio -Protocolleggio -Protocolleggio -Protocolleggio -Protocolleggio -prega -prega -Protocollegia -prega -prega -prega -prega -prega -prega -prega -prega -prega -prega -prega -prega -prega -prega -pre -pre -prega -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre -pre

Rueckmelder -cAnamnese Assistente -cAnamneseTypes +helpTests (long nId, string event) -cAnamneseQuestions +helpProtocoling (long nId, string event) -cAnamneseResponses +helpSearch (long nId, string event) -cDiagnostics +helpTextLaden () -cTherapy Principles -cClinicalVerlations -Cognose/Prognose +getFall () +getAnamnese () +helpProtocoling (long nId, string event) +helpProtocoling (long nId, string event) -cAnamneseResponses +helpSearch (long nId, string event) -cAnamneseResponses +helpSearching (long nId, string event) -cDiagnostics +helpTextLaden () -ClinicalVerlations +Therapy Principes -ClinicalVerlations -Protocoling (long nId, string event) +getAnamnese () +helpProtocoling (long nId, event) +helpProtocoling (long nId, event) +help (long nId, event) +help (long nId, event) -Keyespoints) +booling (long nId, event) -Keybooling (long nId, event) -Keyboiling) -Keybooling (Unnamese) -Keybooling (Unnamese) -Keybooling (Unnames) -Keybooling (Unnames) -Keybooling (Unnames) -Keybooling (Unnames) -Keybooling (Unnames) -Keybooling (Unnames) -Keybooling (Unnames) -Keybooling (Unnames) -Keyboing (Unnames) -Nelection) -Nelection (Unnames) -Clection (Unnames) -Clection -Clection -Clection -Clection -Clection -Clection -Clection -Clection -

L'assistente selezionatore seleziona per determinati eventi i testi di aiuto associati e li trasmette al cliente. Inoltre, registra ogni annuncio di un testo di aiuto. I criteri per la selezione dei Selector sono basati sulle caratteristiche contenute in un oggetto di tipo SELECTORSTRATEGIE (cfr. anche il capitolo 3.4.3). Questi provengono da un file parametrabile che viene letto all'avvio del testo del sistema di insegnamento CAMPUS e che può essere modificato dagli autori. Tutti gli altri oggetti del sistema di insegnamento disponibili (cfr. figura 26) sono situati sul client.

Se una domanda necessaria non è ancora stata prospectivamente caricata sul cliente del sistema di insegnamento/apprendimento, il richiedente richiede una domanda appropriata dal selezionatore di domande sul server. Il presentatore (PRAESENTATOR) è responsabile per la presentazione di una domanda/apprendimento in base alla classe di presenze/interazione impostata. Il richiedente (RUECKMELDER) è responsabile di fornire una risposta immediata alle azioni dell'utente, mentre l'attuale espressione prospectiva del richiedente (RUECKMELDER) inizia a registrare l'attività dell'utente (RUECKMELDER) nel caso in cui l'attività dell'utente (RUECKMELDER) inizia a essere effettuata in base al sistema di registrazione (RUECKMELDER) che contiene le caratteristiche dell'obbiettivo (RUECKMELDER) che, in caso di reazionamento, si rivela che l'attività dell'utente (RUECKMELTER) inizia ad essere molto lenta, in caso di abbattersione (RUECKMELTER) e che, in caso di abbatteramento della rete (RUECKMELTER) viene effettuata in base al nome di tutti gli oggetti (RUECKMELTER).

La registrazione di tutte le attività dell'utente viene effettuata da un oggetto del tipo PROTOKOLLIER, che mostra nella sua finestra tutte le azioni eseguite dall'utente, consentendo agli utenti di avere una migliore visione del corso di una simulazione di caso.

4.5 CAMPUS/paediatria e CAMPUS/infezione

Per sperimentare i concetti di questo lavoro, vengono sviluppati sistemi di insegnamento/apprendimento per la pediatria (CAMPUS/Pediatria) e l'infezionologia (CAMPUS/Infezionologia).

Il prototipo del sistema di insegnamento/apprendimento CAMPUS comprende attualmente circa 5000 linee di codice ed è costituito da istanze di 20 diverse classi che possiedono circa 120 metodi.

Il cliente è costituito da istanze di circa 160 classi (di cui circa 70).

Se invece di un'architettura di insegnamento distribuita si basasse su un'architettura di dati e conoscenze remoti nell'implementazione, la portata del cliente aumenta da 14000 a circa 20400 righe di codice, cioè in questo caso si dovrebbe trasmettere circa il 45% di codice in rete, aumentando così il tempo di attesa per il caricamento del sistema di circa il 45%. Questo calcolo presuppone che la portata dei meccanismi di comunicazione implementati tra questi server e questi due architetture non è molto diversa.

CAMPUS/Pediatrica è stato creato in collaborazione con la Heidelberg University Children's Clinic (OA PD Dr. B. Tönshoff) e la Freiburg University Children's Clinic (OA PD Dr. Zimmerhackl). L'obiettivo del progetto è quello di fornire insegnamento/apprendimento pediatrico, domande di apprendimento e conoscenze di testo.

Figura 27: Ricerca di casi di insegnamento/apprendimento in CAMPUS

5 Riassunto e discussione

L'attenzione alla ricerca nel campo della formazione medica basata sul computer si è spostata negli ultimi anni verso sistemi di insegnamento/apprendimento basati sull'internet. Nel corso del lavoro di ricerca sono emerse una serie di applicazioni molto interessanti e innovative (ad esempio [BITTORF, BAUER et al. 97; HAYES, LEHMANN 96; THE WHOLE BRAIN ATLAS]).

L'obiettivo del presente lavoro è stato quello di elaborare un concetto innovativo per la realizzazione dei sistemi di insegnamento/apprendimento utilizzati nella formazione medica e nella formazione continua e la loro prototipazione.

Per quanto riguarda la domanda 1.1: Quali caratteristiche concettuali deve avere un sistema di insegnamento/apprendimento,

per risolvere i problemi descritti nel capitolo 1.2 dei sistemi CBTS convenzionali?

I problemi classici dei sistemi CBT convenzionali (dipendenza da piattaforma, necessità di installazione, complesso aggiornamento) vengono risolti scegliendo un approccio basato su Internet utilizzando standard web e il linguaggio di programmazione Java. Il requisito per l'utente è solo l'accesso a Internet e l'installazione di un browser web con supporto JDK 1.1. Un altro problema di cui si parla nel capitolo 1.2 è che quando gli studenti si studiano da soli con i sistemi CBT convenzionali, se non sono in grado di risolvere le questioni con le conoscenze presenti in un sistema di insegnamento/apprendimento, viene superato da un approccio convenzionale al Web.

La mancanza di adattamento del sistema all'utente in molti sistemi di insegnamento/apprendimento esistenti e l'adattabilità del sistema da parte dell'utente sono state prese in considerazione anche nel concetto. L'adattamento delle forme di presentazione/interazione nelle simulazioni di caso, il livello di difficoltà di domande e casi di insegnamento/apprendimento, il punto di reinserimento delle azioni dell'utente e l'aiuto del sistema sono disponibili automaticamente. I singoli parametri possono essere adattati da parte degli utenti in qualsiasi momento. L'insoddisfazione degli utenti con un modello o un'insufficiente prestazione di adattamento del sistema può essere prevenuta.

L'approccio Shell permette di affrontare anche l'ultimo problema di cui al capitolo 1.2, l'atteggiamento critico di molti docenti nei confronti dei sistemi CBT non sviluppati in collaborazione con loro. I docenti possono creare i propri sistemi che rispondono esattamente alle esigenze personali, ricorrendo ai contenuti già disponibili e alla funzionalità di Shell.

Per la domanda 1.2:Come raggiungere un uso più frequente dei sistemi di insegnamento/apprendimento da parte degli studenti?

Per poter utilizzare i sistemi CBT, gli studenti devono soddisfare due condizioni: devono essere convinti di trarre vantaggio dall'utilizzo di tali sistemi negli esami e devono essere in grado di utilizzare tali sistemi senza grandi difficoltà organizzative. Idealmente, l'utilizzo dei sistemi CBTS dovrebbe essere incorporato nel curriculum e gli studenti dovrebbero essere in grado di utilizzare tali sistemi anche sul proprio computer a casa.

Per la domanda 1.3:Come migliorare l'accettazione dei sistemi didattici?

I sistemi CBT auto-evoluzionati, o sistemi in cui i docenti hanno partecipato attivamente alla creazione, hanno un'accettazione nettamente superiore rispetto ai prodotti commerciali. Purtroppo, lo sviluppo di sistemi di insegnamento/apprendimento completi è molto complesso e costoso. L'approccio shell proposto consente la creazione rapida di sistemi CBT su misura, aumentando così l'accettazione di sistemi di insegnamento/apprendimento tra i docenti di medicina.

Per la domanda 1.4:Cosa fare per stimolare i docenti ad utilizzare maggiormente i sistemi CBT nei loro corsi e raccomandare ai loro studenti di lavorare con i sistemi CBT?

Una modifica dell'attuale regolamento di approvazione potrebbe permettere agli studenti di avere più tempo per studiare da soli, e i docenti potrebbero quindi fornire ai loro studenti raccomandazioni intensificate in materia di studi da soli, anche con sistemi di insegnamento/apprendimento.

In ogni caso, i sistemi di insegnamento/apprendimento devono essere molto più accessibili di quanto non siano stati finora. L'approccio presentato in questo lavoro consente di utilizzare sistemi di insegnamento/apprendimento su molti computer connessi, anche con studenti e docenti in casa.

Per la domanda 1.5:In che misura il concetto può essere mantenuto indipendente?

Il CAMPUSLexikon consente ai singoli docenti di presentare le conoscenze di dominio secondo le loro esigenze e secondo le specifiche esigenze di un campo di specializzazione. Il modello di domande sviluppato consente la creazione di domande per qualsiasi campo di specializzazione. Il modello di domande di base consente di prendere in considerazione le esigenze di diverse aree di specializzazione in modo che le domande di annuncio di ciascun campo di specializzazione possano essere classificate. Se necessario, possono anche essere attribuite singole prove di laboratorio o procedure di indagine tecniche. Il modello di domande di base è quindi largamente indipendente da ciascun campo di specializzazione. Il modello di domande di base (un caso di insegnamento / apprendimento è costituito da annuncio, un caso di indagine clinica, una analisi tecnica tipologica per ciascun campo di specializzazione) è stato descritto in modo che le domande di annuncio di ciascun campo di specializzazione possano essere classificate.

Il sistema CAMPUS è attualmente in fase di prototipo. Una demoversione del sottosistema di insegnamento e apprendimento è disponibile all'indirizzo URL http://www.hyg.uni-heidelberg.de/campus. Grazie a una partecipazione al progetto di ricerca nazionale VIROR, è garantito un ulteriore sviluppo di tre anni e può essere preparata e effettuata una valutazione approfondita. Una valutazione definitiva dei concetti di utilizzo può avvenire solo dopo che il sistema è stato valutato tramite una valutazione sistematica con l'aiuto di utenti e studenti di medicina.

6 Letteratura

AAMC (Association of American Medical Colleges) (1984): Physicians for Twentyfirst Century: The GPEP-Report. Report of the Panel on the General Professional Education of the Physician and College Preperation for Medicin.

21.12.1989 (BGBl I S. 2549).

Aprile 90 ADLER, M.; DIETRICH, J.W.; HOLZER, M.F.; FISCHER, M.R. (Hrsg.) (1998): Formazione informatica in medicina: tecnica - valutazione - attuazione.

ALBANESE, M.A.; MITCHELL, S. (1993): problem-based learning. A Review of Literature on Its Outcomes and Implementation Issues. Academic Medicine 68(1), 52-81. APPLE (1992). Macintosh Human Interface Guidelines. New York: Addison-Wesley. APPLE (1993): HyperCard Reference Manual. Cupertino: Apple.

Il futuro: analisi delle future esigenze del medico; conseguenze per la formazione e modi di riforma.

AUHUBER, T.C. (1998): Sviluppo e valutazione di un sistema di apprendimento basato su computer

MicroPat un atlas interattivo di istopatologia con tutor adattabile. Università europee VII/D/31. Francoforte; Berlino: Lang.

BALZERT, H. (1996): Manuale di tecnologia del software: sviluppo del software. Heidelberg; Berlino; Oxford: Spektrum.

BAUMGARTNER, P.; PAYR, S. (1994): apprendimento con software.

BAUR, M.P.; MICHAELIS, J. (Hrsg.) (1990): computer nella formazione medica.

BERNES-LEE, T.; CAILLEAU, R.; GROFF, J.F.; POLLERMANN, B. (1992): World Wide Web: The Information Universe.

BEUN, R.-J.; BAKER, M.; REINER, M. (eds.) (1995): Dialogue and Instruction.

BIERMAN, D.J.; KAMSTEEG, P.A.; SANDBERG, J.A.C. (1992): Student Models, ScratchPads, and Simulation. In: [COSTA (ed.) 92], 135-145. BITTORF, A.; BAUER, J.; SIMON, M.; DIEPGEN, T.L. (1997): Web-based training modules in dermatology.

BODENDORF F. (1990): Informatica nell'istruzione professionale e universitaria.

BOOCH, G. (1994): analisi e progettazione orientate all'oggetto. Bonn; Paris: Addison-Wesley.

Bonn: TYPOSCRIPT.

Bonn; Paris: Addison-Wesley. CHEIKES, B.A.; RAGNEMALM, E.L. (1995): Simulator-Based Training-Support Tools for Process-Control Operators. In: [BEUN, BAKER, REINER (eds.) 95], 85-101. CHEN, P.P.S. (1976): The Entity-Relationship Model - Towards a Unified View of Data.

ACM Transactions on Database Systems 1(1), 9-36. CHIZZALI-BONFADIN, C.; ADLASSNIG, K.P.; KREIHSL, M.; HATVAN, A.; HORAK, W.

(1997): A WWW-Accessible Knowledge Base for the Interpretation of Hepatitis Serologic Tests. International Journal of Medical Informatics 47(1-2), 57-60. CHODOROW, S. (1996): Educators Must Take the Electronic Revolution Seriously.

CIMINO, J.J.; SOCRATOUS, S.A.; CLAYTON, P.D. (1995): Internet as Clinical Information System: Application Development Using the World Wide Web.

COAD, P.; YOURDON, E. (1991): Analisi orientata agli oggetti.

CODD, E.F. (1970): Un modello relazionale di dati per grandi banche di dati condivisi.

CONKLIN, J. (1987): Hypertext - An Introduction and a Survery.

CONRADI, H.; KREUTZ, R.; SPITZER, K. (Hrsg.) (1997): CBT in medicina - metodi, tecniche, applicazioni -.

COVELL, D.G.; UMAN, G.C.; MANNING, P.R. (1985): Information Needs in Office Practice: Are They Being Met? Annals of Internal Medicine 103(4), 596-599.

DETMER, W.M.; SHORTLIFE, E.H. (1997): Using the Internet to Improve Knowledge Diffusion in Medicine. Communications of the ACM 8, 101-108. EFFELSBERG, W. (1995): Il progetto di teleteaching delle università di Heidelberg e Mannheim.

EITEL, F. (1993b): La mancanza di formazione. In: SCHWEIBERERER, L.; IZBICKI, J.R.: Chirurgia accademica: formazione, proseguimento e formazione; analisi e prospettive. Berlino; Heidelberg: Springer, 123-132.

ENGLER, C.; FÜHRER, A.; HEMPEL, P.; BUSCHER, H.-P. (1995): HEPA-CADS: sviluppo di un sistema di esperti tutoriali per la diagnosi delle malattie del fegato.

FISCHER, M.; GRÄSEL, C.; SCHERBAUM, W.; GÄRTNER, R.; MANDL, H.; SCRIBA, P. (1995): apprendimento problematico in medicina con il sistema di autore assistito da computer "CASUS".

FLANAGAN, D. (1998): Java in a nutshell. Bonn: O'Reilly, internat.Thomson-Verl.

FONTAINE, D.; LE BEUX, P.; RIOU, C.; JACQUELINET, C. (1994),

Assisted Instruction System for Clinical Case Teaching.

FRASSON, C.; GAUTHIER G. (eds.) (1990): Intelligent Tutoring Systems: At the Crossroad

Norwood, NJ: Ablex. FRIEDMAN, R.B. (1996): Top Ten Reasons the World Wide Web May Fail to Change Me

Dical Education. Academic Medicine 71(9), 979-981. GARDARIN, G.; VALDURIEZ, P. (1989): Relational Databases and Knowledge Bases.

GERNETH, F. (1992): concezione e realizzazione di un sistema immunologico dedicato

Sistema di conservazione e valutazione dei dati per l'integrazione di dati clinici e immunologici utilizzando un modello di dati semantici.

Dentistry: con un overview dei progetti di riforma degli studi e delle proposte di riforma degli studi. Frankfurt am Main: Mabuse. GOSLING, J.; YELLIN, F. ; JAVA TEAM (1997a): JavaTM API. Volume 1: I pacchetti di base.

GOSLING, J.; YELLIN, F.; JAVA TEAM (1997b): JavaTM API. Volume 2: Il window toolkit

Bonn; Parigi: Addison-Wesley. HAAG, M. (1995): concetto complessivo per lo sviluppo e l'impiego di

I corsi di formazione medica a Heidelberg, Heidelberg, Heilbronn: laurea nel corso di laurea in medicina.

HAAG, M.; LEVEN, F.J. (1997): sistemi di insegnamento/apprendimento basati sul web per la formazione medica: stato e futuri sviluppi. In: [CONRADI, KREUTZ, SPITZER (Hrsg.) 97], 105-116.

HAAG, M.; MAYLEIN, L.; LEVEN, F.J.; TÖNSHOFF, B.; HAUX, R. (1998): Web-Based Training: A New Paradigm in Computer-Assisted Instruction in Medicine. International Journal of Medical Informatics.

Hypermedia Systems. Communications of the ACM 31, 836-52. HALLER, R.; BURGER, W.; SCHEFFNER D. (1995): Curriculum di riforma della medicina presso la clinica Rudolf Virchow della Freie Universität Berlin.

HASMAN, A. (1989): The Role of Medical Informatics in a problem-oriented educational environment. In: [SALAMON, PROTTI et al. (eds.) 89], 97-102. HAYES, K.A.; LEHMANN, C.U. (1996): The Interactive Patient: A Multimedia Interactive

Educational Tool on the World Wide Web. M.D. Computing 13(4), 330-334. HERRMANN, U.; LENZ, D.; UNBESCHEID, G. (1997): Oracle 7.3: gestire, ottimizzare, connettere. Bonn; Paris: Addison-Wesley. HERSH, W.R.; BROWN, K.E.; DONOHOE, L.C.; CAMPELL, E.M.; HORACEK, A.E. (1996): CliniWeb: Managing Clinical Information on the World Wide Web.

HEUER, A. (1992): Database orientate all'oggetto: concetti, modelli, sistemi.

HIRSCH, M. C.; BRAUN, H.; HUBER M.; RIEDER, R.; VOIGT, K.H.; FISCHER, M.R. (1993): SimNerv - Un laboratorio di fisiologia virtuale per la somma dei potenziali di azione sul nervo sciatico della rana.

IBRAHIM, B.; FRANKLIN, S.D. (1995): Advanced Educational Uses of the World Wide Web. Computer Networks and ISDN Systems 27(6), 871-879. JACOBSON, I.; CHRISTERSON, M.; JONSSON, P.; ÖVERGAARD, G. (1992): Object-oriented software engineering - A use case driven approach. Wokingham: AddisonWesley.

KALKBRENNER, G. (1996): apprendimento assistito da computer e servizi telematici.

KALLINOWSKI, F.; MEHRABI, A.; GLÜCKSTEIN, CH.; BENNER, A.; LINDINGER, M.; HASHEMI, B.; LEVEN, F.J.; HERFARTH, CH. (1997): Formazione basata sul computer - Un nuovo percorso di formazione e formazione chirurgica. Chirurg 68(4), 433-438. KAPPE, F.; MAURER H. (1993): Hyper-G: Un grande sistema ipermedia universale e alcuni spin-offs. In: informatica e informatica tecnica(352), 39-47.

KLUTE, R. (1997): Database. Interazione: ODBC, JDBC e driver software. iX 6/97, 126-132.

KNAUP, P. (1994): elaborazione a computer di libri di testo medici utilizzando conoscenze formalmente rappresentate. Università di Heidelberg, Dipartimento di Informatica Medica: Dissertamento.

COEBKE, J.; NEUGEBAUER, E.; LEFERING, R. (Hrsg.) (1996): La qualità dell'insegnamento in medicina.

KUHLEN, R. (1991): Hypertext: un mezzo non lineare tra libro e Wissensbank.

LARKIN, J.H.; CHABAY, R.W. (eds.) (1992): Introduzione assistita al computer e sistemi di tutoraggio intelligenti: obiettivi condivisi e approcci complementari.

LAUSEN, G.; VOSSEN, G. (1996): Database orientate all'oggetto: modelli e lingue.

LEUTNER, D (1992): sistemi di insegnamento adattivo; basi psicologiche di istruzione e analisi sperimentali. Weinheim: psicologia-Verl.-Union. LEVEN, F.J., SCHULZ, S., ALLE, W., KLAR, R. (1995). sistemi di insegnamento e apprendimento informatici in clinica: stato e futuri sviluppi. In: BUCHHOLZ, W.; HAUX, R. (Hrsg.) (1995): elaborazione delle informazioni presso la clinica universitaria di Baden-Württemberg. Heidelberg. 187-193.

LEVEN, F.J.; ALLE, W.; HAAG, M.; VIELHAUER, A. (1996): Laboratorio "Computer assisted training in medicine" presso la clinica dell'Università di Heidelberg. In: [KOEBKE, NEUGEBUER, LEFERING (Hrsg.) 96], 251-257. LINDBERG, D.A.; HUMPHREYS, B.L.; MCCRAY, A.T. (1993): The Unified Medical Lan

LLAURADO, J.G. (1997): Commentary. International Journal of Medical Informatics 46, 1-5.

LOWE, H.J.; LOMAX, E.C.; POLONKEY, S.E. (1996): The World Wide Web: A Review of an Emerging Internet-based Technology for the Distribution of Biomedical Infor-

LUSTI, M. (1992): Sistemi didattici intelligenti. Monaco; Vienna: Oldenbourg. MACROMEDIA (1994): Manuale utente direttore. San Francisco: Macromedia. MAIER, G.; WILDERGER, A. (1995): In 8 secondi intorno al mondo: comunicazione via Internet. Bonn; Parigi: Addison-Wesley.

MANN, G. (1993): Integrazione di sistemi basati sulla conoscenza nella medicina, ad esempio di un sistema di dati e di banche di conoscenza in neurologia.

MAYLEIN, L.; HAAG, M. (1998): integrazione delle risorse esistenti nei sistemi WBT.

MCCALLA, G.I. (1992): The Central Importance of Student Modelling to Intelligent Tuto-

MFT-PRESIDENTE COMMISSIONE (1996): raccomandazioni per la riforma del regolamento di approvazione dei medici.

MICROSOFT (1995): The Windows Interface Guidelines for Software Design.

MIDDENDORF, S.; SINGER, R.; STROBEL, S. (1996): Java: manuale di programmazione e riferimento.

MINSKY, M. (1975): A Framework for Representing Knowledge. In: WINSTON, P. (ed.): The Psychology of Computer Vision. McGraw-Hill, 211-277.

NIELSEN, J. (1995): Multimedia & Hypertext: The Internet and Beyond.

NIEMANN, K.D. (1996): architettura client/server. Braunschweig; Wiesbaden: Vieweg. OLIVER, R.E.; WINGERT, K.; REID, J.C.; LOCATIS, C. (1996): The Virtual Health Care

Team: an Example of Distributed Virtual Education.

OPPERMAN, R.; SIMM, H. (1994): Adaptabilità: Individualizzazione iniziata dall'utente. In: [OPPERMANN (ed.) 94], 14-66.

OPPERMANN, R. (ed.) (1994): Adaptive User Support: Ergonomic Design of Manually and Automatically Adaptable Software. Hillsdale: Lawrence Erlbaum. OWEN, S.G.; HALL, R.; ANDERSON, J.; SMART, G.A. (1965): Programmed Learning in Medical Education.

diography to Final Year Medical Students. Postgraduate. Med. J. 41(474), 201-205. PAETAU, M. (1990): Comunicazione uomo-macchina: software, potenziale progettuale, compatibilità sociale. Frankfurt; New York: campus.

PASTERKAMP, H. (1991): Computer assisted learning of chest auscultation: The Respiration Acoustics Laboratory Environment. In: VAN BEMMEL; ZVÁRONOVÁ (eds): Knowledge, Information and Medical Education. North Holland: Elsevier, 244-251.

PELZER, G. (1998): Concezione e implementazione di un sistema per la generazione a computer di unità di informazione hypermedia basate su HTML da un database relazionale.

PUPPE, F. (1993): Systematic Introduction to Expert Systems. Berlin; Heidelberg: Springer. PUPPE, F; REINHARDT, B (1995): Generating Case-Oriented Training From Diagnostic Expert Systems. Machine-Mediated Learning 3&4, 199-219.

QUADE, G.; PUSCHEL, N.; FAR, F. (1996): CancerNet Redistribution via WWW. ProcAMIA-Annu-Fall-Symp, 403-407.

RAGGETT, D. (1997): HTML 3.2: nuove possibilità per la pubblicazione web.

RAMM, F. (1996): ricerca e pubblicazione sul World Wide Web.

RAO, R.; PEDERSEN, J.O.; HEARST, M.A.; MACKINLAY, J.D.; CARD, S.K.; MASINTER, L.; HALVORSEN, P.K.; ROBERTSON, G.G. (1995): Rich Interaction in the Digital Library. Communications of the ACM 38(4), 29-39.

REDLICH, J.-P. (1996): Corba 2.0: Introduzione pratica a C++ e Java. Bonn; Reading; Mass. [e.a.]: Addison-Wesley.

REINHARDT, B.; SCHEWE, S. (1995): A Shell for Intelligent Tutoring Systems. Proc. Conference on Artificial Intelligence in Education (AIED 95), 83-90. REINHARDT, B.; PUPPE, F. (1997): Aspetti didattici nei sistemi di formazione intelligenti orientati a errori. In: [CONRADI, KREUTZ et al. (Hrsg.) 97], 157-168. RICH, E. (1989): Stereotipi e modellazione degli utenti. In: [KOBSA, WAHLSTER (eds.) 89], 35-51.

RIEDEL, J. (1998): progettazione e realizzazione di un sistema di formazione basato sul web per i casi di infezione.

RIEDEL, J.; HAAG, M.; LEVEN, F.J. (1998): WBT-infect: un sistema di formazione e informazione basato sul web per i casi infettiologici.

RODGERS, R.P.C. (1996): Java and Its Future in Biomedical Computing.

RUMBAUGH, J.; BLAHA, M.; PREMERLANI, W.; EDDY, F.; LORENSON, W. (1991): Object Oriented Modeling and Design. Englewood Cliffs: Prentice Hall. SAFRAN, C.; RIND, D.M.; SANDS, D.Z.; DAVIS, R.B.; WALD, J.; SLACK, W.V. (1996): Development of a Knowledge-Based Electronic Patient Record.

SALAMON, R.; PROTTI, D.; MOEHR, J. (eds.) (1989): Proceedings of the 1989 International Symposium of Medical Informatics and Education. School of Health Information Science, University of Victoria, British Columbia, Canada. SAYEGH, M. (1997): CORBA: Standard, specificazioni, sviluppo.

SCHMITT, H.-J. (1996): obiettivi mobili. ActiveX: risposta di Microsoft a Java. ct 12/96, 258-264.

SCHNEIDER-HUFSCHMIDT, M.; KÖHME, T.; MALINOWSKI, U. (eds.) (1993): Interfacce utente adattive: Principles and Practice. North Holland: Elsevier. SCHULMEISTER, R. (1996): Fondamenti dei sistemi di apprendimento ipermedia: teoria - didattica - design. Bonn; Paris: Addison-Wesley.

SCHULZ, S.; SCHRADER, U.; KLAR, R. (1997): Computer Based Training and Electronic Publishing in the Health Sector: Tools and Trends.

SCRIBA, P.C.; MANDL, H., SCHERBAUM, W. (Hrsg.) (1997): Manuale degli autori CASUS.

SELF, J. A. (1990): Bypassing the Intractable Problem of Student Modeling. In: [FRASSON, GAUTHIER (eds.) 90], 107-123.

SILBERG, W.M.; LUNDBERG, G.D.; MUSACCHIO, R.A. (1997): Assessing, Controlling and Assuring the Quality of Medical Information on the Internet (editoriale).

SINGER, R. (1998): progettazione e realizzazione di un componente di autore per sistemi di formazione basati sul web nell'ambito del progetto CAMPUS.

In: [ADLER, DIETRICH et al. (Hrsg.) 98], 141-150. SPENSLEY, F.; ELSOM-COOK, M.; BYERLEY, P.; BROOKS, P.; FEDERICI, M.; SCARONI, C.

(1990): Using Multiple Teaching Strategies in an ITS. In: [FRASSON, GAUTHIER (eds.) 90], 188-205.

SPITZER, K.; BÜRSNER, S. (1994): sistemi basati sulla conoscenza nella medicina. In: informatica e informatica tecnica 36(6), 53-59. STOLL, C. (1996): Il deserto di Internet.

STONEBRAKER, M.; MOORE, D. (1998): database relativi agli oggetti.

STRASSER, A. (1992): Generazione di sistemi di rappresentanza delle conoscenze specifici di dominio

e la trasformazione delle basi di conoscenza con un'applicazione in informatica giuridica.

ULLMAN, J.D. (1988): Principles of Database and Knowledge-Base Systems. Volume I: Classical Database Systems. Rockville: Computer Science Press. VAN BEMMEL, J.H.; MCCRAY A.T. (eds.) (1995): Yearbook of Medical Informatics 1995: The Computer-based Patient Record. Stuttgart: Schattauer. WEED L.L. (1989): New Premises and New Tools for Medical Care and Medical Education. In: [SALAMON et al. 89], 23-30.

WEICHELT, U.; SCHMIDT, H.; ADLER, M.; BAEHRING, T.; FISCHER, M.R. (1998): Formazione medica e addestramento sul web orientata al caso: complesse possibilità di interazione attraverso una soluzione client-server basata su Java. In: [ADLER, DIETRICH et al. (Hrsg.) 98], 159-164.

WEIDENMANN, B. (1991): apprendimento con i mezzi d'immagine. basi psicologiche e didattiche. Weinheim; Basilea: Beltz.

WENGER, E. (1987): Artificial Intelligence and Tutoring Systems.

WINKELS, R.; BREUKER, J. (1992): What's in an ITS? A Functional Decomposition. In: [COSTA (ed.) 92], 57-68.

Consiglio scientifico (1992): linee guida per la riforma dell'istruzione medica.

Consiglio scientifico (1998): raccomandazioni sullo sviluppo dell'istruzione superiore attraverso il multimediale negli studi e nell'insegnamento.

YETIM, F. (1994): spiegazioni nel contesto dell'interazione uomo-computer: un concetto per l'integrazione dei metodi di ipertesto e intelligenza artificiale.

Pubblicazioni elettroniche Quando si fa riferimento a pubblicazioni elettroniche, l'indicazione di una "data di pubblicazione" è stata omessa, in quanto spesso non è accertata e si deve sempre aspettarsi di apportare modifiche alle pubblicazioni.

CBT server: CBT server medicina dell'Università di Heidelberg. http://www.hyg.uni-

DAETWYLER, CH.: The Interactive Exploration of the Fundus Diabeticus.

http://www.aum.iawf.unibe.ch/vlz/bwl/eye_www.htm. HON (Health On the Net) Code Principles. http://www.hon.ch/Conduct.html. HSTAT (NLM). http://text.nlm.nih.gov. LINKS CHECKERS. http://WWW.stars.com/Authoring/HTML/Validation/Links.html. MACROMEDIA AUTHORWARE. http://www.macromedia.com/software/authorware/. PITTSBURGH CASE INDEX. http://www.upmc.80/cases/. PUBMED-FREE MEDLINE: http://www.nlm.nih.gov.org/data/profil.html; http://www.nih.gov.org/profil.html; WEB http://www.macromedia.com/software/authorware/.

SUN: Remote Method Invocation Specification. http://www.javasoft.com/products/jdk/ 1.1/docs/guide/rmi/spec/rmiTOC.doc.html. SYMANTEC Visual Cafe for Java 2.5 - Database Development Edition.

http://www.symantec.com/vcafedde/vcafedde25.html. THE WHOLE BRAIN ATLAS. http://www.med.harvard.edu/AANLIB/cases/java/case.html. UC BERKELEY DIGITAL LIBRARY PROJECT. http://elib.cs.berkeley.edu/. UNIVERSTITY OF IOWA FAMILY PRACTICE HANDBOOK.

http://vh.radiology.uiowa.edu/Providers/ClinRef/FPHandbook/FPContents.html. UPMC (University of Pittsburgh School of Medicine) Health System 98.

http://www.upmc.edu/ccehs/default.htm. VENTER, H.: EBNF. http://www.cs.upe.ac.za/slim/ebnf.html. VIROR.

http://ad.informatik.uni-freiburg.de/viror. WEBDOCTOR MDFORUM. http://www.gretmar.com/webdoctor/MDForum.html.

Appendice

I Simbolo e notazione

Nel lavoro vengono utilizzati i seguenti tipi di carattere (a volte in combinazione):

Immagini grasse f(x) Tipi di dati s p e r r r r t t e quantità sottolineati M tipi di oggetti GROSSOS LIBRARI DOMANDA tipi .21785 $77 Variabili in corsivo Data di creazione

I seguenti operatori sono utilizzati:

logico E logico O NON logico ⇒Implicazione equivalenza quantico di esistenza ∀Tutto quantico ∈... è elemento di ... quantico di parti quantico di unione A → B

II Modello logico

Il modello a 3 livelli di modellazione dei dati presentato nel capitolo 2.9 prevede la realizzazione del modello logico dopo la realizzazione del modello concettuale (cfr. capitolo 3.5) che tiene conto dell'utilizzo di un DBMS relazionale e riunisce i modelli concettuali in un unico modello logico per motivi di accesso più rapido ed efficiente e di più facilità di implementazione e manutenzione.

Naturalmente, anche nel modello logico devono essere soddisfatte le indicazioni di cardinalità definite nella modellazione concettuale, poiché il rispetto di queste condizioni di integrità (livello 2) è monitorato dal sottosistema dell'autore e non è specificato nel DBMS, la specificazione delle cardinalità nel modello logico viene rinviata.

In seguito viene presentato il modello logico. Per una comprensione più semplice, sono indicati commenti su tutti gli attributi. La descrizione formale viene fatta con il formalismo presentato nel capitolo 2.10.1.

CLAVE PRIMARIA CLAVE CLAVE CLAVE CLAVE PRIMARIA CLAVE CLAVE CLAVE PRIMARIA CLAVE CLAVE PRIMARIA CLAVE CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLAVE PRIMARIA CLA

(b1fg,1(x) = truth : PS(Facoltà#, x), sib1fg,2(x) = truth : nf({Facoltà_Name}, x), sib2fg,1(v) = truth : FS(((FAColtà#), (FAColtàGEBIET,

AUTHOR: 5(/(({autore#, autore_name, identificazione, password} Kga ({sib1aut,1, sib1aut,2}), con autore#: $77(l o ng Kga () chiave primaria Autore_name: $77(char(50) Kga () Nome completo dell'autore Identificazione: $77(char(15) Kga () ID utente Password dell'autore: $77(ch ar(15) Kga () Password dell'autore

sib1aut,1(x) = truth : PS(autore#, x), sib1aut,2(x) = truth : nf({autore_name, identificazione, password}, x).

LAYOUT: 5(/(({Layout#, intestazione, calligrafia, colore di fondo} ▷ {sib1lay,1, sib1lay,2}), con layout#: $77(l o ng ) chiave principale intestazione: $77(char(50) ▷ ) calligrafia per le pagine HTML: $77(char50) ▷ ) calligrafia per le pagine HTML colore di fondo: $77(char15) ▷ ) calligrafia per le pagine HTML:

Pagine sib1lay,1(x) = truth : PS(Layout#, x), sib1lay,2(x) = truth : nf1({headline, footline, background color}, x).

WBT_SYSTEM: 5(/(({WBT_System#, layout#, author#, WBT_System_Name, date di creazione} ➡️ {sib1ws,1, sib1ws,2, sib2ws,1, sib2ws,2}), con WBT_System#: $77(lo n g ) Layout di chiave primaria#: $77(l o ng )

sib1ws,1(x) = truth : PS(WBT_System#, x), sib1ws,2(x) = truth : nf({Layout#, autor#, WBT_System_Name, date di creazione}, x), sib2ws,1(v) = truth : FS(((WBT_SYSTEM, Layout#), (LAYOUT, Layout#) , v), sib2ws,2(v) = truth : FS(((WBT_SYSTEM, autor#), (AUTOR, autor#), v).

WBT_SYSTEM_FACHGEBIET: 5(/({WBT_System_Specialist#, WBT_System#, specialist#} {sib1wsfg,1, sib1wsfg,2, sib2wsfg,1, sib2wsfg,2}), con WBT_System_Specialist#: $77(l o n g )

sib1wsfg,1(x) = wahr : PS(WBT_System_Special area#, x), sib1wsfg,2(x) = wahr : nf({WBT_System#, special area#}, x), sib2wsfg,1(v) = wahr : FS(((WBT_SYSTEM_FACHGEBIET, WBT_System#),

(WBT_SYSTEM, WBT_System#), x), sib2wsfg,2(v) = truth: FS: FS: WBT_SYSTEM_FACHGEBIET, area di specializzazione#), (FACHGE- 5(/{Patiente#, sesso, nome, cognome, età, peso, altezza, immagine, descrizione, grado di difficoltà, testo di introduzione, sintesi, data di inizio}:

FALL_FACTIVITÀ: 5 (/) {FALL_FACTIVITÀ: $77) {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FACTIVITÀ: $77} {FAL_FAL_FACTIVITÀ: $77} {FAL_FAL_FACTIVITÀ: $77}

sib1fafa,1(x) = wahr : PS(Anamnese#, x), sib1fafa,2(x) = wahr : nf:{Patient#, area di specializzazione#, x), sib2fafa,1(v) = wahr:

ANNAME: 5\/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

sib1a,1(x) = truth : PS(Anamnese#, x), sib1a,2(x) = truth :nf({Patient#, date}, x), sib2a,1(v) = truth : FS(((ANAMNESE, Patient#), (FALL, Patient#), v).

CLINICAL QUESTIONE: 5*/*{Clinical Investigation#, Patient#, Date, Summary}\\\ (sib1ku, 1, sib1ku, 2, sib2ku, 1}), con Clinical Investigation#: $77\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n

Riassunto: $77 200 Riassunto dell'intero storico

L'esame clinico, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente, il paziente.

RICORDO TECHNOLOGICO: 5(/({RICORDO TECHNOLOGICO, paziente, modulo tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico, formulario tecnico

Tecnolo­gico­investiga­zione, regione di lavoro,

fund_text, find_picture_video, richiesta_data, find_date, normale, necessario, commento, sintomo principale}

Con la ricerca tecnica#: $77(lo n g ) Chiave primaria Paziente#: $77(l o ng ) Chiave frontaleTechnFormulare#: $77(l o n g ) Chiave frontale $77(lo n g ) Chiave frontaleTechn

Date: $77 date ) Date in cui il risultato è stato ottenuto

Normal: $77.00 Risultato normale? Necessario: $77.00 Risultato necessario?

Commento: $77.000 Commento sull'esame

I risultati dell'indagine sono i primi sintomi?

(b1tu,1(x) = truth: PS(TechnoInvestigazione#, x), sib1tu,2(x) = truth: nf({Patient#, TechnFormular#, TechnInvestigazione#,

Requirement_Date, Requirement_Date, Requirement_Date, Requirement_Date, Normal, Necessary, LeadSymptom}, x), sib1tu,3(x) = truth ∀ a ∈ x: a

FORMULAR,Formulare tecnico#), v), sib2tu,3(v) = verità: FS

#), (TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICI, TECHNOLOGICAL SERVICAL SERVICI, TECHNOLOGICAL SERVICAL SERVICI, TECHNOLOGICAL SERVICAL SERVICAL SERVIC, TECHNAL SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC SERVIC

$77 (l o ng ) Risultato del laboratorio: $77 (l o g ) Risultato del laboratorio: $77 (l o g ) Risultato del laboratorio: $77 (l o g) Risultato del laboratorio: $77 (l o g) Risultato del laboratorio: $77 (l o g) Risultato del testo: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: $77 (l o g) Risultato del test: Risultato del laboratorio: Risultato del test: Risultato del test: Risultato del laboratorio: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risultato del test: Risult

Si tratta di un sistema di controllo che consente di controllare l'esistenza di un sistema di controllo.

I risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica, i risultati della ricerca clinica e i risultati della ricerca clinica.

Tipo di ricerca, regione di lavoro, testo del risultato,

Risultato_Immagine_Video, Normale, sintomo di ingresso, necessario, commento, sintomo di ingresso } ▷ {sib1kue,1, sib1kue,2, sib2kue,1, sib2kue,2, sib2kue,3}), con $77(lo n g ) Risultato clinico di chiave primaria Resultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico clinico di ingresso Risultato clinico di ingresso Risultato clinico clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico di ingresso Risultato clinico normale Risultato clinico di ingresso Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato normale Risultato: risultato di ingresso

Necessario: $77 (B o l e an ) È stato necessario un'indagine? Commento: $77 (Char) 2000 (Char) ) Commento sul risultato dell'indagine Sintoma: $77 (B o l e n ) È un'indagine sintoma?

1 (x) = verità: PSCliniche indagini Risultato#, x), sib1kue,2 (x) = verità: nf({Cliniche indagini#, Cliniche indagini#, Corpo di lavoro

on#, risultato_Testo, normale, sintomo di ingresso, necessario, sintomo di conduzione}, x), sib2kue,1(v) = verità :FS(((Clinica, clinica#),

(Clinical research, clinical research#), v), sib2kue,2(v) = truth: FS

(art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#, (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#), (art#) (art#) (art.

Risposta di nome, Anamnese, domanda di anamnese,

Risposta al paziente, normale, sintomo d'ingresso, necessario, commento, sintomo chiave.  {sib1aa,1, sib1aa,2, sib2aa,1, sib2aa,2}), con risposta antecedente#: $77(l o n g ) Chiave primaria Anamnesi#: $77(lo n g ) Risposta antecedente #: $77(lon g ) Risposta antecedente: $77(char20 0 0 ) Risposta del paziente: $77(bo o l e n n ) Risposta del paziente inconsapevole?

Sintoma d'ingresso: 77 dollari.

Necessario: $77(b o l e an ) Domanda di nome necessaria? Commento: $77(char(2000) ) Commento sulla risposta al paziente Principale sintomo: $77(bool e a n ) Risposta al paziente Principale sintomo?

sib1aa,1(x) = verità : PS(risposta di nome#, x), sib1aa,2(x) = verità : nf({annumese#, domanda di anamnesi#, risposta del paziente, normale,

Sintoma di entrata, necessaria, sintoma di conduzione}, x), sib2aa,1(v) = verità: FS(((ANAMNESEANTWORT, Anamnese#), (ANAMNESE, Anam-

Nese#), v), sib2aa,2(v) = verità : FS((ANAMNESEWORD, domanda di nome#), (ANAMNESE-

QUESTIONE DI NOMENO: 5(/({Questione di NOMENO: $77(lon g ) Con domanda di NOMENO: $77(lon g ) Testa di domanda di chiave esterna: $77(ch a r (2,0 00) ) Testo della domanda

sib1af,1(x) = verità: PS(questione di nome#, x), sib1af,2(x) = verità: nf({namnesetyp#, testo della domanda}, x), sib2af,1(v) = verità: FS((ANAMNESETYPE#), (ANAMNESETYPE#), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE), (ANAMNESETYPE)

La domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome, la domanda di nome

$77 (lo n g ) chiave primaria Domanda di annuncio_Professionalità#: Domanda di annuncio#: $77 (lo n g ) chiave esterna Domanda di annuncio#: $77 (lo n g ) chiave esterna

sib1aff,1(x) = truth : PS(laboratorio di ricerca#, x), sib1aff,2(x) = truth : nf({questione di nome#, area di specializzazione#, x), sib2aff,1(v) = truth : FS((ANAMNESEFRAGE_FACHGEBIET, domanda di anamnese#),

(ANAMNESEFRAGE, ANAMNESETYPE_NAME#), v), sib2aff,2(v) = truth: FS(((ANAMNESEFRAGE_FACHGEBIET, area di specializzazione#), ANAMNESETYPE: 5(/({namnesetyp#, anamnesetyp_Name} ↓ {sib1at,1, sib1at,2}), con anamnesetyp#: $77(lon g ) Primary key Anamnesetyp_Name: $77((char30) ↓ ) Name of the anamnesetyp1at,1(x) = truth PS Laboratorio di ricerca#, x), sib1at,2:x) = wahr nf(((((((a_typeName, x)

CLINICAL SQUADER: 5(/({Clinical test type, Clinical test type_Name} ▷ {sib1kua,1, sib1kua,2}), con Clinical test type#: $77(lo n g ) Primary key $77(char30) ▷ ) Name of the clinical test Type_Name: chungs type: sib1kua,,1x) = truth PS(Clinical test type#, x), nf1kua,,2x) = truth :{Clinical test type_Name}, x).

I procedimenti di ricerca tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico-tecnico

$77 (lo n g ) chiave primaria TecnologiaProcedimenti di ricerca#: $77 (char) 30) ) Nome della tecnicaProcedimenti di ricerca_Nome: forza del processo: $77 (ch a r) ) Forze di una tecnicaProcedimenti di ricerca Svantaggi: $77 (char) 20 (char) ) Debolezza di una tecnicaProcedimenti di ricerca

(b1tuv,1(x) = truth: PS(TechnInvestigazioni#, x), sib1tuv,2(x) = truth: nf({Tinvestigazioni_Name}, x).

LABORTEST: 5(/({LABORTEST#, labortest_Name, labortest_shortcut, unit} ) con labortest#: $77(lo n g ) chiave primaria Labortest_Name: $77(char(50)) ) Nome del laboratorio test Labortest_shortcut: $77(char20) ) Abbreviamento per labortest unit: $77(char10) ) Unità del risultato del test

sib1lt,1(x) = truth : PS(Labor test#, x), sib1lt,2(x) = truth : nf({Labor test_name, unit}, x).

LABORATORIALE: 5 (/) {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORIALE: 5} {LABORATORI: 5} {LABORATORI: 5} {LABORATORI: 5} {LABORATORI: 5} {LABORATORI: 5} {LABORATORI: 5} {LABORATORI} {LABORATORI: 7} {LABORATORI: 7} {LABORATORI: $7} {LABORATORI: $7} } } } {LABORATORI: $ORATORI: 7} {LABORATORI: $ORATORI: $0} } } } {L} {L} {L} {L} {L} {L} {L} {L} {L} {L} {L}} {L} {L}} {L} {} {}} {} {}} {} {} {} {} {} {} {}} {} {} {} {} {} {} {} {}} {} {} {} {} {} {} {} {} {} {}} {} {} {} {} {} {} {} {} {} {} {} {}} {} {} {} {} {} {}} {

sib1lf,1(x) = truth : PS(Formulario di laboratorio#, x), sib1lf,2(x) = truth : nf({data di creazione, tipografia del modulo, numero di colonne}, x).

FONTO TECHNOLOGICO: 5\/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

con TechnForm#: $77(l o n g ) Chiave primaria Data di creazione: $77(dat e ) Data di creazione della tecnica. Capo di formulario: $77(char(50) ) Capo di formulario Colore di fondo: $77(char15) ) Colore di fondo del formulario Scrittura del formulario: $77(char80) ) Titolo del formulario

sib1tf,1(x) = truth : PS(TechnFormular#, x), sib1tf,2(x) = truth : nf({date di realizzazione, scritta del modulo}, x).

LABORF_TEILFORM: 5 (/) {labor_partform#, lab_form#, lab_form#, subform#, colonna_position, sequenza_position} ∙ {sib1lftf,1, sib1lftf,2, sib2lftf,1, sib2lftf,2,} , con lab_partform#: $77(l o g )

sib1lftf,1(x) = wahr : PS(Labor_partform#, x), sib1lftf,2(x) = wahr : nf({laborform#, subform#, colonna posizione, sequenzafol-

(Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio) (Lavoratorio)

LAR, formulario di laboratorio#), v), sib2lftf,2(v) = verità: FS(((LABORF_TEILFORM, sottoformulario#), (TEILFORMULAR, TEILFORMULAR: 5(/({TEILFORM#, sottoscritto} {sib1tef, sib1tef,2}), con sottoformulario#: $77l o gâr ) Prima chiave sottoscritto: $77(((ch ar50) ) Titolo del sottoformulario sib1tef,1x) = verità: PS<<<<<<<<<<<<<<<<<<<<<<<<<<<<, x), sib1tef,2x) = verità

TEILFORMULAR_LABORTEST: 5\/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Il testo di cui all'articolo 2 del regolamento (CE) n. 1408/71 è stato modificato in modo da consentire l'elaborazione di un programma di ricerca e di una revisione del programma di ricerca.

FORMULAR, sotto forma#), v), sib2tflt,2(v) = truth: FS(((((TEILFORMULAR_LABORTEST, labortest#), (LABOR-

PROBENART: 5(/({sampolo tipo, nome del campione, luogo di ritiro} ➡️ {sib1pa,1, sib1pa,2}), con campione tipo #: $77(l o n g ➡️) chiave primaria campione tipo_Nome: $77(ch ar(50) ➡️ ) Nome del campione tipo di luogo di ritiro: $77(ch a r (ch a r (5 0) ➡️ ) luogo di ritiro del campione

Si tratta di un'operazione che si svolge nel corso di una serie di anni.

COERPERREGIONE: 5(/({COERPERREGIONE#, COERPERREGIONE_Nome, descrizione,

Immagine, ispezione, palpazione, esplorazione, percussione, analisi del suono. ), con rilievo corporeo#: $77(l o n g ) chiave principale rilievo corporeo_Nome: $77(ch a r (5 0) ) Nome del campione Descrizione: $77(ch a r (5 0) ) Descrizione Immagine: $77(char50) ) Riferimento a immagine del corpo re-

Ispezione: 77 dollari. Riesci a controllare le aree corporee?

Palpazione: $77 b o l e an ) Può essere palpita la regione del corpo

Percussione: 77 dollari. Potete percutire le regioni corporee?

Testione: 77 dollari. È possibile eseguire un'esame tecnico sulla regione del corpo?

(b1kr,1(x) = vaer: PS(Coerperregion#, x), sib1kr,2(x) = vaer: nf({Coerperregion_Name, ispezione, palpazione, esplorazione,

ALTERSSTUFE: 5 (/((({età#, età#, età#Nome, età#abbreviazione} ) {sib1as,1, sib1as,2, sib1as,3}), con età#: $77(l o ng ) chiave primaria età_Nome: $77(char 20) ) Nome dell'età Abbreviazione: $77ch ar(5) ) Abbreviazione Da: $77 (indicare in giorni) Fino a: $77lo n g ) Fino a (indicare in giorni)

sib1as,1(x) = true PS(età#, x), sib1as,2(x) = true : nf({età_Nome, Da, Fino}, x), sib1as,3(x) = true : ∀ a ∈ x: a {Fino} < a {Fino }.

LABORNORMALBEFUND: 5 (/) {LABORNORMALBEFUND: 5 (/) {LABORNORMALBEFUND: $77 (lo n g ) {LABORNORMALBEFUND: $77 (lo n g ) {LABORNORMALBEFUND: $77 (lo n g ) {LABORNORMALBEFUND: $77 (lo n g ) }{LABORNORMALBEFUND: $77 (lo n g ) {LABORNORMALBEFUND: $77 (lo n g ) }{LABORNORMALBEFUND: $77 (lo n g ) }{LABORNORMALBEFUND: $77 (lo n g ) }{LABORNORMALBEFUND: $77 (lo n g ) }{LABORNORNORMALBEFUND: $77 (lo n) }{LABORNORNORMALBEFUND: $77 (lo n) }{LABORNORNORNORNORMALBEFUND: $77 (lo n) }{LABORNORNORNORNORNORMALBEFUND: $77 (lo n) }{LABORNORNORNORNORNORMALBEFUND: $77 (lo n) }{LABORNORNORNORNORNORNORMALBEFUND: $77 (lo n) }{LABORNORNORNORNORNORNORMALBEFUND: $77 (lo n) {LABORNORNORNORNORNORMALBEFUND: $77 (lo n) {LABORN: $77 (lo n) }{LABORNORN: $77 (lo n) }{LABORN: $77 (lo n} {LABORN: $77 (lo n} (lo n} (lo n} (lo n

Rich's Max: $77

sib1lnb,1(x) = truth pssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss

FS(((TECHNORMALBEFUND, age level#), (ALTERSSTUFE, sib2knbart, sib2knbart,3}, (ALTERSSTUFE, CLINNORMALBEFUND: 5(/({KlinNormalbefund#, ClinicalBefund#, Koerperregion#, age level#, gender, result_Text, result_Bild_Video} , (ALTERSSTUFE, sib1knb, sib1knb, sib2knb, sib2knb, sib2knbart, sib2knbart,3}), con ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#Fund#, ClinicalBefund#, ClinicalBefund#Fund#, ClinicalBefund#, ClinicalBefund#, ClinicalBefund#Fund#, ClinicalBefund#Fund#Fund#, ClinicalBefund#, ClinicalBefund#Fund#, ClinicalBefund#, ClinicalBefund#Fund#

sib2knb,2(v) = truth : FS(((KLINNORMALBEFUND, corporea regione#)

"Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione del lavoro", "Regione dell'alteramento",

Risposta ordinaria, domanda ordinaria, corrispondenza

perregione#, età#, sesso, insoddisfacente_risposta}

$77(lo n g ) chiave primaria Anamnesi Risposta normale#: domanda di anamnesi#: $77(lon g ) chiave di credito#: $77(lo n g ) chiave di credito#: $77(l o n g ) chiave di credito

sib1anno,1(x) = verità: PS(nomeNormale risposta#, x), sib1anno,2(x) = verità: nf({questione del nome#, regione di lavoro#, età#, sesso,

Infantile_resposta}, x), sib2anno,1(v) = verità : FS

(QUESTIONE ANAMENTE, QUESTIONE ANAMENTE#), v), sib2anno,2(v) = verità : FS(((ANAMENTE NORMALE

ERPERREGION, COUERREGION#), v), sib2anno,3(v) = truth : FS(((NORMALWORD, age level#), (ALTERS-

CLINICAL CONCLUSIONE: 5*/*{Clinical course#, Patient#, order position, Clinical course_Text }\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Si tratta di una serie di casi in cui l'individuo ha avuto un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica che non è stata sufficientemente soddisfatta da un'esperienza fisica o fisica.

PROGNOSSO: 5(/({Prognostic#, Patient#, Prognostic_Text }♪ {sib1p,1, sib1p,2, sib2p,1}), con Prognostic#: $77(l o n g ) Primary Key Patient#: $77(l o ng ) Frontiere Key Prognostic_Text: $77(ch ar(2000) ) Prognostic del paziente

sib1p,1(x) = truth : PS(Prognostic#, x), sib1p,2(x) = truth :nf({Patient#, Prognostic_Text}, x), sib2p,1(v) = truth : FS(PROGNOSE, Patient#), (FALL, Patient#), v).

CETTE DI TERAPIA: 5(/({CETTE DI TERAPIA#, paziente#, da, fino, ordine posizionamento

on, therapy_text, new_diagnose, new_therapy, new_care, acute_therapy, comment } {sib0tk,1, sib1tk,1, sib1tk,2, sib2tk,1}), con catena di terapia#: $77(lo n g ) chiave primaria Paziente#: $77(l o ng ) chiave remota Da: $77(date ) Inizio della terapia: $77

Nuova terapia: $77(boolean ) È necessaria una nuova terapia a causa dei risultati dell'indagine o del corso della clinica? $77(char(40) ) ambulatorio, ambulatorio o terapia intensiva: sib0tk,3(w) = truesivstation w ∈ {ambulant, stati-

La terapia acuta: $77 boolean ) L'elemento con ordine di posizione 1: è la terapia acuta

Commento: $77.000 Commento dell'insegnante sulla terapia eseguita

sib1tk,1(x) = truth : PS(therapy chain#, x), sib1tk,2(x) = truth : nf({patient#, Von, Bis, sequenza, testo della terapia,

Nuova diagnosi, nuova terapia, tipo di assistenza, terapia acuta},

X), sib2tk,1(v) = verità : FS((TERAPIETTA, paziente#), (FALL, paziente#), v).

Terapette_diagnosi: 5\/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

L'aspetto di cui si tratta è il seguente: l'aspetto di cui si tratta è: l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta l'aspetto di cui si tratta; l'aspetto di cui si tratta è l'aspetto di cui si tratta; l'aspetto di cui si tratta l'aspetto di cui si tratta; l'aspetto di cui si tratta l'aspetto di cui si tratta; l'aspetto di cui si tratta di cui si tratta l'aspetto di cui si tratta;

CETTE, terapia#), v), sib2tkd,2(v) = verità

Terapeutica, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo, controllo.

$77 (lo n g ) chiave primaria TherapChain_training#: catena di terapia#: $77 (lo n g ) chiave accessoria Laboratorio#: $77 (lo n g ) chiave accessoria Controllo: $77 (b o l e an ) Si tratta di un controllo?

Si tratta di una serie di ricerche che hanno dimostrato che l'efficacia di un sistema terapeutico può essere determinata da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico o da un sistema terapeutico.

L'aspetto di cui si tratta è quello di:

(TERAPIETTA, catena di terapie#), v), sib2tlu,2(v) = verità

L'esame di cui trattasi è stato effettuato nel corso di un'inchiesta di laboratorio.

Terapeutica, Tecnologia, Controllo.

$77 (lo n g ) chiave primaria TerapeuticaCatena di ricerca#: catena di ricerca#: $77 (lo n g ) chiave anteriore TecnologiaCatena di ricerca#: $77 (lo n g ) chiave anteriore Controllo di ricerca: $77 (b o l e an ) Si tratta di un controllo di ricerca?

Si tratta di un sistema operativo che consente di controllare e controllare i risultati di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica o di un'indagine clinica.

THERAPKETTE_THERAPP PRINCIPE: 5(/(({therapkette_therapprinciple#, therapeutic chain#, therapeutic chain#, therapeutic chain#, therapeutic principle#, therapeutic type of therapy } {sib0tktp,1, sib1tktp,1, sib1tktp,2, sib2tktp,1, sib2tktp,1, sib2tktp,2}), con $77(lo n g ) Primary key Therapkette_therapprinciple#: $77lo n g ) Primary key Therapeutic chain#: $77lo n g ) Primary key Therapeutic chain#: $77lo n g ) Primary key Therapeutic key: $77lo n g ) Primary key: $7750 )

1 (x) = verità: PS(Therapkette_TherapPrinzip#, x), sib1tktp,2(x) = verità: nf({therapykette#, therapeutic principle#, therapeutic type}, x), sib2tktp,1(v) = verità: FS(((THERAPKETTE_THERAPPRINCIP, therapeutic chain#),

(TERAPIETTA, catena di terapie#), v), sib2tktp,2(v) = verità : FS((TERAPIETTA_PRINCIPIO, principio di terapia#),

(TERAPIEPRINCIP, principio di terapia#), v),

PRINCIPIO DELLA TERAPIA: 5(/({principio del trattamento, principio del trattamento_Nome }♪ {sib1tp,1, sib1tp,2}), con principio del trattamento#: $77(lo n g ) chiave primaria del trattamento_Nome: $77(char(150) ) Nome del principio del trattamento

(x) = verità: PS(principio di terapia#, x), sib1tp,2(x) = verità: nf({principio di terapia_Name}, x).

Diagnosi, titolo triplate, titolo triplate, codice incrociato, codice stellare, testo di diagnosi.

con diagnosi#: $77(l o n g ) chiave primaria tripliceTitolo: $77(char(255) ) ICD-10 QuartipliceTitolo: $77(char(255) ) ICD-10Cross code: $77(char5) ) ICD-10Cross code: $77(char5) ) ICD-10Cross code: $77(char5) ) ICD-10Titolo di diagnosi: $77ch ar(255) )

sib1d,1(x) = verità : PS(diagnosi#, x), sib1d,2(x) = verità:nf({cdcrosscode, DiagnoseText}, x).

FALL_DIAGNOSSO: 5(/({FAL_DIAGNOSSO#, paziente#, diagnosi#, data, diagnosi di sospetto, commento, categoria, passato} ➡️ {sib0fd,1, sib1fd,1, sib1fd,2, sib2fd,1, sib2fd,2}), con caso_DIAGNOSSO#: $77(l o g ) chiave primaria

Commento: $77.000 Commento

$77(in t e ger ) 1=diagnosi principale, 2=per la categoria: sib0fd,1(w) = vero: dato il diagnosi principale , 3=nessun w ∈ {1, 2, 3} Zshg. Per il diagnosi principale o non importante?

Passato: $77$ di diagnosi passate

(prima del caso)? sib1fd,1(x) = verità : PS(diagnosi#, x), sib1fd,2(x) = verità : nf({paziente#, diagnosi#, data, diagnosi sospetta, categoria,

Passato}, x), sib2fd,1(v) = true : FS(((FALL_DIAGNOSE, paziente#), (FALL, paziente#), v), sib2fd,2(v) = true : FS(((FALL_DIAGNOSE, diagnosi#), (DIAGNOSE, diagnosi#),

PRINCIPIO DI TERAPIA: 5(/({diagnostic_therapy principle#, diagnosi#, principio di terapia#, tipo di terapia, percorso, prognosi, commento}

$77(lo n g ) chiave primaria Diagnosi_terapia Principio#: Diagnosi#: $77(lo n g ) chiave anteriore Principio di terapia#: $77(lo n g ) chiave anteriore Tipo di terapia: $77(char30) )

Si tratta di un metodo che consente ai pazienti di sviluppare un'attività fisica o fisica che non sia necessaria e che non sia necessaria per i loro pazienti.

DIGNOSE_ANAMNESESWORT: 5(/({diagnosi_risposta anonima#, diagnosi#, risposta anonima#, evidenza, commento}

$77(lo n g ) chiave primaria Diagnosi_risposta anonima#: Diagnosi#: $77(l o n g ) chiave esterna Risposta anonima#: $77(l o n g ) chiave esterna Evidenza: $77(ch a r (1 0) ) Evidenza per la diagnosi di risposta anonima Commento: $77(char(2000) Commento alla collaborazione

sib1daa,1(x) = truth : PS(diagnosis_name answer#, x), sib1daa,2(x) = truth : nf({diagnosis#, antecedents#, evidence}, x), sib2daa,1(v) = truth: FS((DIAgnosis_name word, diagnosis#), (DIA-

GNOSE, diagnosi#), v), sib2daa,2(v) = vero : FS((DIAGNOSE_ANAMNESESWORT, risposta anamnesi#),

(ANAMNESESEANTWORD, risposta all'annuncio#), v).

DIGNOSE_CLINUNTERSO: 5*/*DIGNOSE_CLINUNTERSO: DIGNOSE_CLINUNTERSO: DIGNOSE_CLINUNTERSO: DIGNOSE_CLINUNTERSO: DIGNOSE_CLINUNTERSO: DIGNOSE_CLINUNTERSO: DIGNOSE_CLINUNTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE_CLINTERSO: DIGNOSE

I risultati di un'indagine clinica hanno dato commenti: $77.000 Commenti sulla connessione tra diagnosi e risultati clinici

I risultati della ricerca sono stati ottenuti in base alle ricerche effettuate nel corso dell'anno e sono stati rilevati in base alle ricerche effettuate nel corso dell'anno.

GNOSE, diagnosi#), v), sib2dkue,2(v) = verità

(Cliniche ricerche, cliniche ricerche), v).

DIGNOSE_TECHNOLOGIA: 5*/*DIGNOSE_TECHNOLOGIA: 5*/*DIGNOSE_TECHNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA: DIGNOLOGIA

Il risultato di un'indagine tecnica commento: $77.000 Commento sulla connessione diagnosi - risultato tecnico.

L'investigazione sib1dtu,1(x) = verità: PS(diagnosi_tecnicoInvestigazione#, x), sib1dtu,2(x) = verità: nf({diagnosi#, ricerca tecnica#, prove}, x), sib2dtu,1(v) = verità: FS(((DIAGNOSE_tecnicoinvestigazione, diagnosi#),

(DIAGNOSE, diagnosi#), v), sib2dtu,2(v) = verità: FS(((DIAGNOSE_TECHNOLOGY, TECHNOLOGY

(TECHNOLOGY, TECHNOLOGY*), v).

DIAGNOSI_LABORTESTRUTI: 5(/({Diagnosi_LABORTESTRUTI#, Diagnosi#, LABORTESTRUTI#, Evidenza, commento}\\\\{sib1dlte,1, sib1dlte,2, sib2dlte,1, sib2dlte,2}), con $77 ((lo g\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Test di laboratorio sib1dlte,1(x) = vero : PS(Diagnosi_LaborResultat#, x), sib1dlte,2(x) = vero : nf({diagnosi#, risultati di test di laboratorio#, prove}, x), sib2dlte,1(v) = vero: FS(((DIAGNOSE_LABORTESTERGEBENNIS, Diagnosi#), (DIA-

GNOSE, diagnosi#), v), sib2dlte,2(v) = vero

(RESULTATO DEL LABORTO, risultato del test di laboratorio), v).

ERROR: 5(/({error#, germer_name, germer_genus, genus_root} ∙ {sib1err,1, sib1err,2}), con germer#: $77(l o n g ) chiave primaria germer_name: $77(ch a r (2 0 0 0)) ) nome del germer germer_genus: $77(ch ar(200)) ) genus che il germer

Racconto di genere: $77 ((char(5) ) Racconto di generi patogeni

sib1err,1(x) = truth: PS(errog#, x), sib1err,2(x) = truth:nf({errog_name}, x),

FALL_ERREGER: 5(/({FALL_ERREGER#, Patient#, pathogen#} 🔴 {sib1fe,1, sib1fe,2, sib2fe,1, sib2fe,2,}), con FALL_ERREGER#: $77(l o n g ) chiave primaria Patient#: $77(l o ng ) chiave frontale pathogen#: $77(l o n g ) chiave frontale

(FALL, Patient#), v), sib2fe,2(v) = (FALL_ERREGER, ERREGER#) (FALL, ERREGER#) (FALL, ERREGER, ERREGER#) (FALL, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER, ERREGER)

FALL_LABORTEST: 5(/({FALL_LABORTEST#, Patient#, Labortest#, Reason for Rejection} (sib1fla,1, sib1fla,2, sib2fla,1, sib2fla,2}), con Case_LABORTEST#: $77(l o n g ) chiave primaria Patient#: $77(l o ng ) chiave esterna Labortest#: $77lo n g )

• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •

Difficoltà: 5 (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà) (difficultà)

sib1sst,1(x) = true : PS(difficultà#, x), sib1sst,2(x) = true : nf({difficultà_nome, delimitazione}, x).

QUESTIONE: 5*/*{Questione#, Categoria_Nome, Descrizione} (sib1fk,1, sib1fk,2}), con Categoria#: $77(lon g ) Chiave primaria Categoria_Nome#: $77(c h a r (50) ) Nome della Categoria Descrizione: $77(ch a r (2 0 0 0) ) Descrizione della Fekatego

Rie sib1fk,1(x) = truth : PS(Questione #, x), sib1fk,2(x) = truth : nf({Questione_Name}, x).

QUESTIONE: 5(/({questione, autore, tipo di risposta, livello di difficoltà,

Categoria di domanda#, data di creazione, testo di domanda, immagine, tempo di risposta max. {sib1fra, 1, sib1fra, 2, sib2fra, 1, sib2fra, 2, sib2fra, 3, sib2fra, 4}), con domanda#: $77(l o n g ) Chiave primaria Autore: $77(l o n g ) Chiave chiave chiave Risposta tipo: $77(lo n g ) Chiave chiave chiave Difficoltà di livello#: $77l o n g ) Chiave chiave chiave chiave Categoria di domanda #: $77lon g ) Chiave chiave di creazione: $77 Data di creazione: $77 e e ) Risposta alla domanda Resto: $77 (txt: $77a)

Sb1fra,1(x) = verità: PS Questione#, x), sib1fra,2(x) = verità: nf({autore#, tipo di risposta#, grado di difficoltà#, categoria di domanda#,

Data di creazione, testo della domanda, x), sib2fra,1(v) = verità: FS(((QUIESTA, autore#), (AUTORE, autore#), v), sib2fra,2(v) = verità: FS((QUIESTA, risposta tipo#), (ANTWORTTYP, risposta tipo#), v), sib2fra,3(v) = verità: FS((QUIESTA, grado di difficoltà#),

Difficilezza#), v), sib2fra,4(v) = verità: FS(((QUIESTA, Categoria di domanda#), (QUIESTA, QUESTIONE RISPONDITA: 5(/{RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA: RISPONDITA RISPONDITA RISPONDITA

RISPONDO DELLA RISPONDAZIONE: 5*/*{rispostaSelezioneMC#, domanda#, tipo, risposta, correttezza, commento}

con rispostaSelezioneMC#: $77(l o n g ) Domanda chiave primaria#: $77(l o n g ) Tipo chiave esterna: $77(char(1) ) Domanda MC selezionata? sib0aam,1(w) = verità w ∈ {a, m}, risposta: $77(ch ar(2 0 0 0)) ) Testo della risposta corretta: $77(bool e a n ) Risposta corretta? Commento: $77(2000) )

sib1aam,1(x) = truth : PS(RispostaSelezioneMC#, x), sib1aam,2(x) = truth : nf({Questione#, tipo, risposta, correttezza}, x), sib2aam,1(v) = truth FS((RISPONDO:

RISPONDO ALTERNATIVO: 5 (/) {RESPONDO ALTERNATIVO, domanda #, corretta_risposta, sbagliata_risposta, commento} ∙ {sib , sib , sib }), con rispostaAlternativa#: $77(lo n g ) Domanda chiave primaria#: $77(l o n g ) chiave esterna corretta_RESPONDO: $77(char20 0) ) Testo di una risposta corretta_RESPONDO: $77(char200) Risposta ) Testo di un commento errato: $77(char2000 )

sib1aal,1(x) = truth: PS(respostaAlternativa, x), sib1aal,2(x) = truth: nf({question#, right_response, wrong_response}, x), sib2aal,1(v) = truth FS(((RESPONDO:

RISPONDO: 5(/({risposta libera#, domanda#, corretta_risposta, commento} ➡️ {sib1aaf1, sib1aaf2, sib2aaf1}), con risposta libera#: $77(lo n g ) Domanda chiave primaria#: $77(l o n g ) chiave esterna corretta_risposta: $77(char(20 0) ) Testo di una risposta corretta Commento: $77(char(2000) ) Commento

sib1aaf,1(x) = verità : PS(respostaFrei#, x), sib1aaf,2(x) = verità : nf({question#, correct_response}, x), sib2aaf,1(v) = verità : FS((ANTWORTFREI, question#), (QUESTIONE, question#), v).

RISPONDAZIONE: 5 (/) {rispostaMatching#, domanda#, concetto_A, concetto_B, commento} ♬ {sib1am,1, sib1am,2, sib2am,1}), con rispostaMatching#: $77(lon g ♬)

sib1am,1(x) = truth : PS(respostaMatching#, x), sib1am,2(x) = truth : nf({question#, nozione_A, nozione_B}, x), sib2am,1(v) = truth : FS((ANTWORTMATCHING, question#), (question#, question#), v).

Risposte: 5 (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte) (Risposte)

con rispostaArchivio#: $77(l ong ) Domanda di chiave primaria#: $77(l o n g ) Tipo chiave frontale: $77(char 1) ) Commenti = b, o icone = i sib0anan,1(w) = verità w ∈ {b, i} Conto_icona: $77(ar50) ) Conto o percorso su posizione di icona: $77(i n t ege r ) Pozizione nell'ordine di ordine Commento: $77(char2000 ) Commento sib1,1x) : ananan n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n n

WBT_SYSTEM_QUESTIONE: 5(/({WBT_System_Question#, WBT_System#, QUESTIONE#} 🔴 {sib1wsf,1, sib1wsf,2, sib2wsf,1, sib2wsf,2,}), con WBT_System_User#: $77(l o g ) chiave principale WBT_System#: $77(lo n g ) chiave frontale QUESTIONE: $77l o n g ) chiave frontale

sib1wsf,1(x) = truth : PS(WBT_System_nodes#, x), sib1wsf,2(x) = truth : nf({WBT_System#, domanda#}, x), sib2wsf,1(v) = truth : FS(((WBT_SYSTEM_FRAGE, WBT_SYSTEM#), (WBT_SYSTEM,

WBT_SYSTEM#), v), sib2wsf,2(v) = vero : FS((WBT_SYSTEM_FRAGE, domanda#), (FRAGE, domanda#), v).

Utilizzatore: 5(/({User#, ID, password, e-mail, talk, loginDa-

In questo caso, la Commissione ha deciso di adottare le misure necessarie per risolvere le questioni di cui trattasi.

Data di registrazione, numero di semestre, AdaptationActivated, ProspectiveLoad, TotalNurPatho} ▷ {sib1nu,1, sib1nu,2}), con utente#: $77(l ong ) Identificazione di chiave primaria: $77char20) ) Identificazione di password di login utente: $77ch ar2 0) ) Password di login utente Email: $77char: $50 ) Indirizzo e-mail utente Talk: $77(bool e l a n n n ) Deve essere inserito un utente?

(Risate) Come si presenta un caso all'utente?

Pregiudizi: 77 dollari. Quali sono le categorie di domande?

L'ora di registrazione: $77 quando si effettuano le risposte del sistema?

Data di iscrizione: $77.00 ) Quando l'utente ha ottenuto il numero del semestre: $77.00 ) In che semestre si è iscritto l'utente al momento della prima iscrizione?

Adaptazione attivata: $77 (Boo l'a n) è l'automazione del sistema.

Prospettibile caricamento: $77

TotalNurPatho: $77 b o l ean ) Il modulo di presentazione / interazione Total dovrebbe mostrare solo risultati patologici?

sib1nu,1(x) = truth : PS(User#, x), sib1nu,2(x) = truth : nf({identificazione, password, e-mail, talk, manuale di gestione,

Modulo di presentazione, domande, data di presentazione, data di presentazione

Numero di semestre, Adaptazione attivata, carica delle prospettive, totaleNurPatho}, x).

WBT_SYSTEM_User: 5(/({WBT_System_User#, WBT_System#, user#} 🔴 {sib1wsn,1, sib1wsn,2, sib2wsn,1, sib2wsn,2}), con WBT_System_User#: $77(l o g )

sib1wsn,1(x) = truth : PS(WBT_System_User#, x), sib1wsn,2(x) = truth : nf({WBT_System#, user#, x), sib2wsn,1(v) = truth : FS(((WBT_SYSTEM_NUTZER, WBT_System#), (WBT_SYSTEM,

WBT_SYSTEM#), v), sib2wsn,2(v) = truth : FS((WBT_SYSTEM_User, user#), (User, user#), v).

CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE CALCOLAZIONE

con casse#: $77(l o n g ) chiave primaria Utente#: $77(l ong ) chiave frontale paziente#: $77(l o ng ) chiave frontale successo: $77(real ) successo di casse Durata di elaborazione: $77(longo ) Durata di elaborazione in secondi

sib1fab,1(x) = truth : PS(Caso di elaborazione#, x), sib1fab,2(x) = truth : nf({User#, Patient#, Successo, Durata di elaborazione, Tempo}, x), sib2fab,1(v) = truth : FS((REDICIONE, Utente#), (Utente, Utente#), v), sib2fab,2(v) = truth FS:TRUTTO, Patient#), (FALL, Patient#), v).

QUESTIONE: 5\/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

sib1frb,1(x) = truth : PS (User, user#), sib1frb,2(x) = truth : nf({User#, question#, Successo, durata di elaborazione, data}, x), sib2frb,1(v) = truth :

USUALIZZA DEL NOTTO: 5 (/) {node visitation#, user#, node#, length of stay, time} {sib1knb,1, sib1knb,2, sib2knb,1, sib2knb,2,}), con note visitation#: $77(l o n g ) User key primary#: $77 ((l ong ) Node key key key #: $77 ((l o ng ) Node key length of stay: $77 (((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((((

sib1knb,1(x) = truth : PS(visita ai nodi#, x), sib1knb,2(x) = truth : nf({utente#, nodi#, durata di soggiorno, tempo}, x), sib2knb,1(v) = truth : FS((NOTEUZIO, Utenti#), (Utenti, utenti#), v), sib2knb(,2v) = truth : FS((NOTEUZIO, nodi#), (NOTEUZIO, nodi#), v).

HELPTEXT: 5(/({HELPTEXT#, evento, testo di aiuto} ➡️ {sib1hit,1, sib1hit,2}), con testo di aiuto#: $77(l o n g ➡️) Primario chiave evento: $77(char(50) ➡️) Evento in cui viene inserito il testo di aiuto

Il testo di aiuto: $77

sib1hit,1(x) = truth : PS(Testo di aiuto#, x), sib1hit,2(x) = truth : nf({successo, testo di aiuto}, x).

HELP PROTOCOLO: 5\/\\HELP PROTOCOLO#, utente#, testo di aiuto#, data} \\\{sib1hp,1, sib1hip,2, sib2hip,1, sib2hip,2}), con protocollo di aiuto#: $77\long ) chiave primaria Utente#: $77\long ) chiave esterna testo di aiuto#: $77\l o n g ) chiave esterna Data: $77\Date di aiuto

sib1hip,1(x) = truth : PS(protokolo di aiuto#, x), sib1hip,2(x) = truth : nf({utente#, testo di aiuto#, data}, x), sib2hip,1(v) = truth : FS((HILFEPROTOKOLL, utente#), (UZER, utente#), v), sib2hip,2v) = truth : FS((HILFEPROTOKOLL, testo di aiuto#), (HILFETEXT, testo di aiuto#),

QUESTIONE: 5 (/) QUESTIONE #, QUESTIONE #, Oggetto #, Nome dell'Oggetto (Oggetto: $1, sib1fzu, 2, sib2fzu, 1, sib2fzu, 2, 1 sib2fzu, 2}), con QUESTIONE #: $77 ((l o n g ) QUESTIONE PRIMIARIA QUESTIONE #: $77 ((l o n g ) Oggetto: $77 ((l o n g g ) Oggetto: $77 ((l o n g g ) Oggetto: $77 ((l o n g g ) Oggetto: $77 ((l o n g ) Oggetto: $77 ((l o n g )) Oggetto: $77 ((l o n g )) Oggetto: $77 ((l o n g )) Oggetto: $77 ((l o g )) Oggetto: $77 ((l o g )) Oggetto: $77 ((l o g )) Oggetto: $77 ((l o g ) Oggetto: $77 (l) Oggetto:

sib1fzu,1(x) = truth : PS(questione di domanda#, x), sib1fzu,2(x) = truth : nf({questione#, oggetto#, nome dell'oggetto}, x), sib2fzu,1(v) = truth FS((QUESTIONE, QUESTIONE#), (QUESTIONE, QUESTIONE#), v), sib2fzu,2(v) = truth

NOTE: 5(/({node#, capitolo#, tipo di nodo#, scheda di navigazione#, data di creazione, nodo_Name, percorso, scheda di navigazione} {sib0kn,1, sib1kn,1, sib1kn,2, sib2kn,1, sib2kn,2, sib2kn,3}), con nodi: $77 (l o ng ) Prima chiave capitolo#: $77 (lo n g g g g g g g g g g g g g ) Nota di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave di chiave

NOTE CONTROLATO: 5 (/) {node assignation#, object#, node#, node#, object name} {sib1kzu,1, sib1kzu,2, sib2kzu,1, sib2kzu,2,}), con node assignment#: $77(l ong ) Node principale: $77 ((l o ng ) Node utente: $77 ((l o n g ) Node utente: $77 ((l o n g ) Nome utente: $77 (((char5 0)) ) Nome dell'oggetto riferito

tipnamens sib1kzu,1(x) = true : PS(ordinanza dei nodi#, x), sib1kzu,2(x) = true : nf({node#, oggetto#, nome dell'oggetto}, x), sib2kzu,1(v) = true : FS((NOTE, nodi#), (NOTE, nodi#),

(v), sib2kzu,2(v) = true : FS(((Notazione, oggetto#), (OBJECTNAME, O-

ANCER: 5 (/) {anchor#, node#, element#, date di realizzazione, element type, anchor position1, anchor position2, target anchor, REL, REV, TITLE} {sib0ank,1, sib1ank,1, sib1ank,2, sib2ank,1, sib2ank,2}), con anchor#: $77 (lo n g ) Primary key node#: $77 (lo n g g ) Element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element element

Attributo opzionale del tag <A> REL: $77(char(50) ) Attributo opzionale del tag <A> REV: $77(char(50) ) Attributo opzionale del tag <A> TITLE: $77(ch a r (50) ) Attributo opzionale del tag <A>

sib1ank,1(x) = verità : PS(ancorno#, x), sib1ank,2(x) = verità : nf({nodo#, elemento#, data di creazione, tipo di elemento, posizione di ancoraggio

on1, posizione di ancoraggio2}, x), sib2ank,1(v) = vero: FS((ANCER, nodo#), (NOTTI, nodo#), v), sib2ank,2(v) = vero: FS((ANCER, elemento#), (ELEMENT, elemento#), v).

REFERENZA: 5*/*{referenza, tipo di riferimento, ancoraggio, nodo, data di creazione, URL} {sib1ver, 1, sib1ver, 2, sib2ver, 1, sib2ver, 2, sib2ver, 3}), con riferimento#: $77(l o n g ) chiave primaria REFERENZA: $77(l o n g ) chiave anteriore Ancoraggio#: $77lo(n g ) chiave anteriore Nodo#: $77l o n n g ) chiave anteriore (obiettivo del connesso)

ses) Data di realizzazione: $77\dat e ) Data di realizzazione URL: $77\char\80) ) Uniform Resource Locator

sib1ver,1(x) = truth PS: Referenza, x), sib1ver,2(x) = truth : nf({Reference type#, anchor#, knot#, date of creation, URL }, x), sib2ver,1(v) = truth: FS: (Reference type#), (VERWEISTYP, reference type#), v), sib2ver,2(v) = truth: FR: FR: FR: FR: ANKER, ANKER, V), v), sib2ver,3v) = truth FS: TRUTT, knot#), (NOTES, NOTES, V)

REFERENTE: 5(/({reference_type#, reference_type_name, description} ➡️ {sib1vert,1, sib1vert,2}), con riferimento #: $77(l o n g ➡️) chiave primaria Reference_type: $77(ch a r (50) ➡️ ) Nome del tipo di riferimento Descrizione: $77(ch a r (2 0 0 0) ➡️ Descrizione / delimitazione

sib1vert,1(x) = truth : PS(Reference type#, x), sib1vert,2(x) = truth : nf({Reference type_name, description}, x).

CAPITOLO: 5 (/) {capitolo#, sottoscrittoCapitolo#, posizione del capitolo, capitolo_Name} ∙ {sib1kap,1, sib1kap,2, sib2kap,1}), con capitolo#: $77(lo n g )

Capitolo capitolo_Nome: $77

(capitolo, capitolo#), (capitolo, capitolo#), (v)

LISTO DI NAVIGACIONE: 5(/({barella di navigazione#, direzione, livello di direzione} ▷ { sib0nale,1, sib0nale,2, sib1nale,1, sib1nale,2, sib1nale,2}), con barella di navigazione#: $77(lo n g ) Direzione chiave primaria: $77(char1) ) Sinistra (l), destra (r) o centrata: sib0nale,1w) = v (c) w ∈ {l, r, c} Direzione di direzione: l) ▷ ) Horizontale (h) o verticale (v) v w) =

SIB1nale,1(x) = verità: PS(Lista di navigazione#, x), sib1nale,2(x) = verità: nf({orientamento, livello di orientamento}, x).

NAVILEISTE_NAVIELEMENT: 5(/({NaviLeiste_NaviElement#, navigationbar#, navigationselement#, sequenza posizione}

$77(lo n g ) chiave primaria NaviLeiste_NaviElement#: barella di navigazione#: $77(lo n g ) chiave frontaleElement di navigazione#: $77(l o n g ) chiave frontale

sib1nana,1(x) = truth: PS(NaviLeiste_NaviElement#, x), sib1nana,2(x) = truth: nf({navigationbar#, navigationselement#, sequenza

In questo caso, non si può fare a meno di una volta che il sistema di navigazione non è in grado di raggiungere il livello di velocità.

VIGATIONSLIST, navigation bar#), v), sib2nana,2(v) = truth : FS(((NAVILEISTE_NAVIELEMENT, navigation element#), NA-

VIGATIONSELEMENT, elemento di navigazione#), v).

SELEMENTE di NAVIGACIONE: 5(/({Elemento di NAVIGACIONE#, scrittura, icona} ▷ {sib1nael,1, sib1nael,2}), con elemento di NAVIGACIONE#: $77(l o n g ) Scrittura chiave primaria: $77(char(10) ▷ ) Scrittura dell'icona: $77(ch a r (5 0) ▷ ) Via all'icona

sib1nael,1(x) = truth : PS(Navigation element#, x), sib1nael,2(x) = truth : nf1({descrizione, icona}, x).

InfoElement#, data di creazione, InfoElement_Name, percorso, tipo di elemento, formato, breve descrizione.

con InfoElement#: $77(lo n g ) chiave primaria Data di creazione: $77(dat e ) Data di registrazione in DB InfoElement_Name: $77(ch ar(30) ) E.t.l. Nome dell'elemento Via: $77(char50) ) Via di accesso all'elemento InfoElement Element: $77(ch ar(15) ) testo, immagine, video, suono... formato: $77(char15) ) Storage Format abbreviato: $77(((2000) Descrizione testuale dell'elemento

sib1inel,1(x) = true : PS(InfoElement#, x), sib1inel,2(x) = true : nf({date di creazione, percorso, tipo di elemento, formato}, x).

NOTE_INFOEEMENT: 5 (/) {node_InfoElement#, node#, infoElement#} {sib1knee,1, sib1knee,2, sib2knee,1, sib2knee,2}), con nodo_InfoElement#: $77(l o n g )

sib1knie,1(x) = truth : PS(Noti_InfoElement#, x), sib1knie,2(x) = truth : nf({noti#, InfoElement#}, x), sib2knie,1(v) = truth FS(((Noti_INFOEEMENT, nodi#), (Noti, nodi-

ten#), v), sib2knie,2(v) = ver : FS((KNOTEN_INFOELEMENT, InfoElement#), (INFOELEWBT_SYSTEM_NOTEN: 5(/({WBT_SYSTEM_NOTEN#, WBT_SYSTEM#, NOTEN#} {sib1wsk,1, sib1wsk,2, sib2wsk,1, sib2wsk,2}), con WBT_System_User#: $77l o n g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g g

III elenco abbreviato

Application UMO Ordine di approvazione per medici ANSI American National Standards Institute ATI Aptitude-Treatment Interactions Language DML Manipulation Language DOMINIE Data Domain Independent Instructional Environment CAMPUS Computer Supported Exercise and Continuing Education in Medicine by Platform Independent Software CASE Computer-Aided Software Engineering CBT Computer-Based Training CGI Common Gateway Interface COM Component Object Model CORBA Common Object Request Broker Architecture DBMS Database Management System DDL Data Definition Language DML Manipulation Language DOMINIE Data Domain Independent Instructional Environment EBNF Computer Supported Exercise and Continuing Education in Medicine by Platform Independent Software CASE Computer-Aided Software Engineering CBT Computer-Based Training CGI Common Gateway Interface COM Component Object Model CORBA Common Object Request Broker Architecture DBMS Database Management System DDL Data Definition Language DML Manipulation Language DOMINIE Data Domain Independent Instructional Environment EBNF Computer Supported Exercise and Continuing Education in Medicine by Platform Independent Software CASE Computer-Aided Software Engineering UMM Computer-Based Training ERM Entity-Relationship Modeling ERC Entity Entity Entity-Relationship Calculus al.

IV elenco delle immagini

Figura 1: Distribuzione degli studi presso la riforma di Berlino Figura 10: Strutture di interazione e di architettura Figura 5: Strutture di interazione e di architettura Figura 2: Strutture di programmazione SCHEMATISCA Figura 3: Strutture di programmazione SCHEMATISCA Figura 23: LERNIFILL 15 Figura 4: Architettura Figura: Strutture WBT Sistemi 21 Figura 5: Strutture di interazione e di architettura Figura 25: Strutture di interazione Figura 6: Strutture di interazione (COMMESSIONE OBJECTIVE RECOMMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOMESSIONE RECOSSIONE RECOMES RECOMESSIONE RECOMES ROMES RECOMES ROMES RECOMES ROMES ROMES ROMES RECOMES ROMES ROMES ROMES ROMES ROMES ROMES ROMES R

V elenco di tabelle

TABELLA 1: Classificazione delle misure di adattamento TABELLA 34 TABELLA 2: Tecnologie di base per la sostituzione dei sistemi WBT TABELLA 55 TABELLA 3: Classificazione di un'ideale architettura di insegnamento distribuita TABELLA 57 TABELLA 4: Punti di valutazione per le esigenze 71 TABELLA 5: Categorie di prove nel sistema del campus TABELLA 6: 113 punti/risposte nel sistema del campus 114

Indice VI

ActiveX 32 D3 42 Adattabilità 33 Database livello 19 Funzionalità 35 Database e conoscenze 62 User Interface 36 Database 50 Adattazione 34 Database 48 Rate di adattamento 34 oggettivo 52 Adaptazione 35 oggettivo 52 Adaptività 33; 36 Data Modellazione Vedere Analisi di esigenze semantica 58 Data Modellazione Gruppo di lavoro Formazione medica 8 Schema DB 49 Architettura Tipi WBT Sistemi diagnostici ATI Effetti 42 set covering"- 42 Attributi 48 Casi 42 Formazione funzionale 42 Berlino-basica 10 Heuristica 42 Progetto BMG 9 Studi medici 42 Docentici 8 Studi didattici 58 Scrittori riformati e CBT 11 Assessori 40 Autori di ricerca 11 Discriminazione 40 Discriminazione 40 Discriminazione 40 Discriminazione 40 Discriminazione 40 Discriminazione 14 Discriminazione 40 Discriminazione 14 Discriminazione 40 Discriminazione 40 Discriminazione 14 Discriminazione 40 Discriminazione 40 Discriminazione 40 Discriminazione 40 Discriminazione 40 Discriminazioni

Backtrack 19 Backus-Naur-Form Introduzione 1 ampliato 44 Entity-Relationship Calcolo 46 Tecnologia di base 7 Schema di Entity-Relationship 44 Tecnologie di base 31; 55 Evaluation 62 Definizioni del termine 7 Corso di studio sulla riforma di Berlino Vedere: formazione Bookmarks 19 Browsing Vedere Forma di interazione

Casemodello 81 Casemodello 88 fisheye view 20 CAMPUS 64 Fragemodello 105 CAMPUS/Infectiology 119 Domanda 5 CAMPUS/Pediatria 119 Frames 38 CASUS 15 Stranger Key 51 CBT 7 Forme di Interazione 11 CBT System 7 Sviluppo 14 Problema di granularità 28 convenzionali 7 Guided Tours 19 CGI 32 Client/Server Comunicazione 25 Architettura basata su client 22 Cognitive Apprenticeship 39 History lists 19 Cognitive Overhead 20 HTML 31 Computer-based Training 7; 11 HTTP 17 Constraints 38 Hyperface 18 Cookies 17 Hypertext 18 CORBA 26 Nights 19 Object Request Broker 26 Overview Diagrammi 20 Implementazione 62 Integrazione 27; 29 Moduli Intelligenti Sviluppo 36 37 Moduli Sviluppo Indipendente 31 Moduli Sviluppo 39 Moduli Sviluppo 39 Moduli di comunicazione 31 Moduli di comunicazione 31 Moduli di comunicazione 31 Moduli di comunicazione 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli interfaccia 31 Moduli interfaccia 31 Moduli interfaccia 31 Moduli interfaccia 31 Moduli interfaccia 31 Moduli di interfaccia 31 Moduli interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli di interfaccia 31 Moduli interfaccia 31 Moduli interfa

Modellazione concettuale 75 Modello di dati relativi 48 Relazioni schema 49 Remote Data & Knowledge Architettura 22 Remote Procedure Call 25 Concetti di rappresentazione 28 Language Mapping 27 Resource 28 Layout Modello 99 Qualità delle risorse 29 Sistema di insegnamento/apprendimentoCliente 7 RMI 25 Sistema di insegnamento/apprendimentoFunzionalità 7 Sistema di insegnamento/apprendimentoServidore 7 Sistema di insegnamento/apprendimentoShell 7; 64 Sistema di insegnamento/apprendimentoShell Concept 63 Modellazione delle funzioni di insegnamento 61 Strati Modello 67 Modello di insegnamento 68 Sistema di insegnamento Modello 67 Modello di insegnamento Modello 68 Modello di insegnamento Modello di insegnamento Modello di insegnamento Modello di insegnamento 99 Condizioni di insegnamento semantico 50 Sistemi di insegnamento 115 Sistemi di insegnamento 37 Modello di insegnamento/apprendimento Modello di insegnamento 94 Architettura 24 Modello di insegnamento/apprendimentoSistema di insegnamento/apprendimento 64 Modello di insegnamento/apprendimento Modello di insegnamento 63 Modello di insegnamento Modello di insegnamento Modello 61 Modello di insegnamento Modello 67 Modello di insegnamento 68 Modello di insegnamento Modello 67 Modello di insegnamento 68 Modello di insegnamento Modello di insegnamento 11 Sistemi di insegnamento 11 Sistemi di insegnamento 11 Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento 50 Sistemi di insegnamento 11 Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento 37 Sistemi di insegnamento 37 Sistemi di insegnamento 37 Sistemi di insegnamento 37 Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento 37 Lezioni Sistemi di insegnamento Sistemi di insegnamento 37 Lezioni Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento Sistemi di insegnamento Sistemi 94 Sistemi di insegnamento

Modulo di insegnamento Vedere Tutoriali intelligenti WBT Sistema Modello 109 Sistemi basati sul web Formazione 7 Consiglio scientifico 2 WWW 16 Dynamics 29 Disponibilità 61 Debolezza 17 Forze 17 Risorse WWW 27

WBT 7 WBT sistema 7 WBT sistemi 20 Obiettivo 5 Requisiti 53 Modello a due strati 67 Architettura 20

Curriculum vitae

Nome Martin Ernst Haag Strasse Finkenweg 25 Abitazione 69214 Eppelheim Nascita 04.12.1969 Luogo di nascita 74585 Rosso al lago - Brettheim cittadinanza tedesca Stato familiare religione libera evangelica

Scuola elementare 1976-1980 Scuola elementare Brettheim Gymnasium 1980-1989 Gymnasium Gerabronn Data di laurea 10 maggio 1989 Tipo di laurea Generale maturità universitaria

Studi e studi Informatica medica presso l'Università di Heideldauer Berg / Università di specializzazione di Heilbronn dal WS 1990/91 - SS 1995 Diplomasso (diploma - 28 giugno 1995 Informatica medica)

Assistenza scientifica da novembre 1993 a giugno 1995 in laboratorio formazione assistita al computer in medicina dell'Università di Heidelberg

- Grazie. - Grazie.

A questo punto ringrazio tutte le persone che hanno contribuito a completare con successo il mio dottorato di ricerca.

Prof. Dr. R. Haux, ringrazio molto di aver assunto la cura di questo dottorato di ricerca.

I dirigenti del laboratorio di formazione medica assistita dal computer, Prof. Dr. h.c. H.G. Sunday e Prof. F.J. Leven, mi ringraziano per avermi permesso di utilizzare l'intera infrastruttura del laboratorio.

I signori Dipl.-Inform. Med. G. Pelzer, Dipl.-Inform. Med. J. Riedel e Dipl.-Inform.

Ringrazio i signori PD Dr. B. Tönshoff e AiP T. Ullinski della clinica per bambini dell'università, nonché il Prof. Dr. H.-K. Geiss e l'AiP signora E. Müller dell'Istituto di igiene per il loro supporto tecnico e per la fornitura di corsi di insegnamento.

I signori Dipl.-Inform. Med. B. Chevreux e Dipl.-Inform. Med. T. Pfisterer si sono mostrati gentili a leggere il presente lavoro di correzione.

Signor Dipl.-Inform. Med. W. Ringrazio tutti per i anni di buona collaborazione nel creare e gestire il laboratorio di formazione medica assistita dal computer.

Ringrazio tutti i miei amici, conoscenti e genitori per il loro supporto mentale negli ultimi tre anni.