Interaktives Notfalltraining in der Zahnmedizin: Entwicklung einer Virtual Patient Player-Simulationssoftware

mibe000192 10.3205/mibe000192 urn:nbn:de:0183-mibe0001920 Originalarbeit Interaktives Notfalltraining in der Zahnmedizin: Entwicklung einer Virtual Patient Player-Simulationssoftware Interactive emergency training in dentistry: Development of a virtual patient player simulation software Geneit Geneit Martin M Dr.

Praxis für Zahnmedizin und Oralchirurgie Dr. med. dent. Martin Geneit, Ludwigsweg 6, 49152 Bad Essen, DeutschlandPraxis für Zahnmedizin und Oralchirurgie Dr. med. dent. Martin Geneit, Bad Essen, Deutschland

geneit@t-online.de author German Medical Science GMS Publishing House

Düsseldorf

610 emergency dentistry MedBiquitous virtual patients simulation Notfall Zahnmedizin MedBiquitous virtuelle Patienten Simulation 20181113 germ This is an Open Access article distributed under the terms of the Creative Commons Attribution 4.0 License. Dieser Artikel ist ein Open-Access-Artikel und steht unter den Lizenzbedingungen der Creative Commons Attribution 4.0 License (Namensnennung). 1860-9171 14 3 GMS Medizinische Informatik, Biometrie und Epidemiologie GMS Med Inform Biom Epidemiol MEDIZIN.BILDUNG.DIGITAL 14 Virtuelle Patienten sind in der medizinischen Ausbildung seit langem etabliert. Mit ihrer Hilfe können Lernende ohne Risiko für einen Patienten ihre therapeutischen und diagnostischen Fähigkeiten unter möglichst realitätsnahen Bedingungen ausbauen. Während Modell- oder Puppensimulationen in der Zahnmedizin zum Training manueller Fähigkeiten einen Standard darstellen, werden computerbasierte, interaktive Simulationen virtueller Patientenfälle für dieses Fachgebiet selten beschrieben. Einige dieser Systeme sind für einen begrenzten Einsatzzweck konzipiert und lassen eine flexible und wiederverwendbare Gestaltung virtueller Patienten nicht oder nur eingeschränkt zu. Lösungsansätze hierzu zeigt der MedBiquitous-Standard. Dieser hat sich im medizinischen Bereich als Grundlage virtueller Patientensimulationen bewährt. Er bietet eine erweiterbare Struktur für die Daten virtueller Patienten und beschreibt grundlegende Algorithmen einer dazugehörigen Simulationssoftware. In der vorliegenden Arbeit wird auf Grundlage des MedB</PlainText></TextGroup>iquitous-Modells eine Virtual Patient Player-Simulationssoftware für ein interaktives Notfalltraining in der Zahnmedizin entwickelt. Ein erster virtueller Beispielpatient wurde erstellt. Der MedEmergency-Player ermöglicht im Unterschied zu vorhandenen Systemen eine aktionsb<TextGroup><PlainText>et</PlainText></TextGroup>onte Simulation ohne „starr“ vorgegebene Behandlungspfade. Der Benutzer erfährt und untersucht die Reaktionen unmittelbar wie bei einem realen Patienten.</Pgraph></Abstract> <Abstract language="en" linked="yes"><Pgraph>Virtual patients have long been established as part of medical training. With their help, students can develop their therapeutic and diagnostic skills under conditions that are as realistic as possible, without any risk for a patient. While model or dummy simulations represent a standard in dentistry for the training of manual skills, computer-based, interactive simulations of virtual patient cases in this field are rarely described. Some of these systems have been designed for a limited purpose and do not permit a flexible and reusable design of virtual patients, or only permit it with restrictions. The MedBiquitous standard offers solutions for this purpose. This has proven itself in the medical field as a basis for virtual patient simulations. It offers an expandable structure for the data of virtual patients and describes fundamental algorithms of associated simulation software. In this paper, virtual patient player simulation software for interactive emergency training in dentistry is developed on the basis of the MedBiquitous model. As an example, a first virtual patient was created. MedEmergency Player enables action-focussed simulation without rigidly predefined linear or branched treatment pathways, unlike existing systems and the previous use of the MedBiquitous standard. The user directly experiences and examines the reactions as with a real patient</Pgraph></Abstract> <TextBlock linked="yes" name="Einleitung"> <MainHeadline>Einleitung</MainHeadline><Pgraph>Bei Notfallsituationen während der zahnärztlichen Behandlung muss das Behandlungsteam angemessen und koordiniert reagieren. Die hierfür nötige notfallmedizinische Ausbildung erwirbt der Zahnarzt während des Studiums und in vertieft sie in Weiterbildungen. Für ein ausführliches, regelmäßiges Üben fehlt allerdings oft ein der Sache angemessenes Zeitkontingent.</Pgraph><Pgraph>Durch regelmäßiges Anwenden prägen sich Lerninhalte des zahnärztlichen Alltags ein. Dies ist bei Notfallsituation nicht möglich. Es sind selten eintretende, plötzliches Ereignisse mit hohem Risiko. Sie können nicht durch einen realen Patientenfall trainiert werden.</Pgraph><Pgraph>Das fachliche Können muss daher auf andere Weise aufrechterhalten werden. Wichtig ist hierbei das rasche Reagieren im „theoretischen“ Bereich, aber auch das regelmäßige Üben der praktischen Handgriffe. </Pgraph><Pgraph>Zu diesem Zweck werden seit Langem virtuelle Patienten im Sinne von nicht computerbasierten naturgetreuen Puppensimulationen <TextLink reference="1"></TextLink> verwendet, z.B. bei der Herz-Lungen-Wiederbelebung. Eine andere Form virtueller Patienten könnte als „interaktive, realitätsnahe, computerbasierte Simulation“ <TextLink reference="2"></TextLink> die Notfallausbildung unterstützen.</Pgraph><Pgraph>In der Zahnmedizin sind solche computergestützten interaktiven Patientenszenarios grundsätzlich bekannt. Das ODSDM/DDx&Tx-System wurde bereits in den achtziger Jahren des 20. Jahrhunderts über einen langen Zeitraum in der studentischen Ausbildung verwendet <TextLink reference="3"></TextLink>. Simuliert wurden hier zunächst Patientenfälle aus dem Bereich der oralen Pathologie, später auch Szenarien aus dem gesamten zahnmedizinischen Fachgebiet <TextLink reference="4"></TextLink>.</Pgraph><Pgraph>Trotz dieser frühen Beschreibung wurden in den folgenden Jahrzehnten in der Zahnmedizin nur wenige computergestützte virtuelle Patienten in der Literatur erwähnt <TextLink reference="3"></TextLink>, <TextLink reference="4"></TextLink>, <TextLink reference="5"></TextLink>, <TextLink reference="6"></TextLink>, <TextLink reference="7"></TextLink>, <TextLink reference="8"></TextLink>, <TextLink reference="9"></TextLink>, <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>, <TextLink reference="12"></TextLink>, <TextLink reference="13"></TextLink>, <TextLink reference="14"></TextLink>. Im Bereich des Notfalltrainings ist nach Literaturrecherche und dem Kenntnisstand des Autors bisher keine Software bekannt.</Pgraph><Pgraph>Mögliche Ursachen für die geringe Verbreitung sind u.a. hoher Aufwand und Kosten bei der Entwicklung und Anpassung der virtuellen Patienten und die fehlende Wiederverwendbarkeit bzw. Austauschmöglichkeit der Inhalte <TextLink reference="15"></TextLink>.</Pgraph><Pgraph>Einen solchen wichtigen systemübergreifenden Austausch virtueller Patienten ermöglicht der Standard nach ANSI/MedBiquitous. Er beschreibt eine gemeinsame XML-b<TextGroup><PlainText>as</PlainText></TextGroup>ierte Struktur für Inhalt und Verhalten der virtuellen Patienten. Dadurch kann eine der Spezifikation entsprechende Virtual Patient Player-Software diese virtuellen Patienten darstellen. Zudem können Inhalte leichter angepasst und erweitert werden <TextLink reference="16"></TextLink>.</Pgraph><Pgraph>Der MedBiquitous-Standard wurde bisher hauptsächlich für Virtual Patient Systeme mit dem Schwerpunkt auf textbasierter Entscheidungsfindung eingesetzt. Der Handlungsablauf der Simulationen ist zumeist verzweigt oder linear vorgegeben. Seltener wird auch eine sogenannte problemlösungsorientierte/globale Struktur implementiert, bei der z.B. Anamnese- und Befundungsoptionen ohne vorgegebene Reihenfolge frei ausgewählt werden können <TextLink reference="17"></TextLink>.</Pgraph><Pgraph>Die Auswahl der Handlungsoptionen erfolgt in jedem Fall durch die aktive Navigation des Benutzers, z.B. per Mausklick. Dieser Ablauf könnte durch mehrere gleichzeitig frei wählbare Handlungsoptionen mit direkter Reaktion des virtuellen Patienten erweitert werden, so dass eine eher „aktionsbetonte“ Software resultiert.</Pgraph><Pgraph>Dieser Artikel beschreibt die Verwendung und Adaption des MedBiquitous-Standards für die unmittelbare Beeinflussung der Parameter eines virtuellen Patienten. Mit der angepassten Struktur wird eine Virtual Patient Player-Software für das interaktive Notfalltraining in der Zahnmedizin entwickelt. Die Software erlaubt auch den Einsatz linearer oder verzweigter Pfadstrukturen. </Pgraph><Pgraph>Leichter weiterverwenden und anpassen lässt sich ein solches System nicht nur durch den Einsatz des Me<TextGroup><PlainText>dBiquit</PlainText></TextGroup>ous-Standards, sondern auch durch eine plattformunabhängige browserbasierte Frontend-Komponente und die Trennung von Programmlogik, Daten und Benutzeroberfläche.</Pgraph><Pgraph>In die grafische Benutzeroberfläche lassen sich optional multimediale Inhalte einbinden, um die Immersion des Benutzers in das Simulationsgeschehen zu fördern. Zur Demonstration wird ein Prototyp (einfacher Patientenfall) zur simulierten Behandlung eines bei der zahnmedizinischen Behandlung auftretenden Notfalls erstellt.</Pgraph></TextBlock> <TextBlock linked="yes" name="Material und Methoden"> <MainHeadline>Material und Methoden</MainHeadline><Pgraph>Die Software wurde mit den in den folgenden Abschnitten angegebenen Hilfsmitteln ohne externe Dienstleister eigenständig durch den Autor entwickelt.</Pgraph><SubHeadline>XML-Daten des virtuellen Patienten</SubHeadline><Pgraph>Die XML-Daten der virtuellen Patienten des <TextGroup><PlainText>MedEmergenc</PlainText></TextGroup>y-Players werden auf einem Server vorgehalten und sind nicht allzu umfangreich. Daher spielen Performance-Unterschiede verschiedener Datenbankm<TextGroup><PlainText>an</PlainText></TextGroup>agementsysteme (DBMS) eine untergeordnete Rolle. Somit kann statt eines nativen XML-DBMS ein XML-e<TextGroup><PlainText>na</PlainText></TextGroup>bled DBMS (Microsoft SQL Server/Visual Studio) eingesetzt werden. Dies ist in Hinblick auf Datenintegrität, Abfragen, nebenläufigen Transaktionen, Standardisierung und Administration vorteilhaft.<TextLink reference="18"></TextLink>.</Pgraph><Pgraph>Die abschnittsweise Weitervermittlung der vom Server aufbereiteten XML-Daten an das Flex-Frontend erfolgt über dynamische Webseiten des zum SQL-Server „passenden“ Mediators ASP.NET in Verbindung mit MS Visual Basic.</Pgraph><SubHeadline>MedEmergency-Player-Frontend</SubHeadline><Pgraph>Das Frontend des MedEmergency-Players soll ein im Vergleich zu herkömmlichen Webanwendungen ein verbessertes Nutzererlebnis ähnlich einer dynamischen Desktopanwendung bieten. Dem Benutzer stehen umfangreiche Darstellungs- und Interaktionsmöglichkeiten wie Animationen, Video, komplexe Kontrollelemente zur Verfügung. Ein kleinerer Teil der Anwendungslogik wird in das Frontend ausgelagert, so dass nicht zu umfangreiche Inhalte vom Server geladen werden müssen. Damit sind einige charakteristische Merkmale einer sogenannten „Rich Internet Application“ (RIA) erfüllt, wobei dieser Begriff weder standardisiert noch exakt definiert ist <TextLink reference="19"></TextLink>.</Pgraph><Pgraph>Zur Entwicklung des RIA-Frontends wurde das Adobe/Ap<TextGroup><PlainText>ac</PlainText></TextGroup>he Flex Framework mit der IDE Adobe Flash Builder ausgewählt. Dieser bietet bei eingeschränkten Ressourcen im Vergleich zu den Möglichkeiten von HTML/Jav<TextGroup><PlainText>aS</PlainText></TextGroup>cript eine „Komplettlösung“ <TextLink reference="20"></TextLink> zur Erstellung eines datenzentrierten und umfangreicheren Frontends. </Pgraph><Pgraph>Das Flex SDK der Flash-Plattform beinhaltet eine große Anzahl anpassbarer UI Komponenten. Dadurch wird der Programmieraufwand für die Benutzeroberfläche des MedEmergency-Players deutlich verringert. Die Design View des Flash Builders hilft durch ihre visuelle Darstellung bei der Gestaltung und Adaption der Benutzeroberfläche. Design und Layout der Benutzeroberfläche können „pixelgenau“ ohne Berücksichtigung verschiedener Browser<TextGroup><PlainText>(-versionen)</PlainText></TextGroup> erstellt werden. Das Testen der Software erfordert dadurch weniger Aufwand im Vergleich zu HTML/JavaScript.</Pgraph><Pgraph>Erstellte Anwendungen können mit dem Adobe Flash-Player in Browsern und mit der plattformübergreifenden Laufzeitumgebung Adobe AIR nach Installation browserunabhängig auch ohne Internetverbindung auf lokalen Desktop- und mobilen Rechnern ausgeführt werden <TextLink reference="20"></TextLink>. Der MedEmergency-Player kann somit je nach Einsatzzweck webbasiert gleichzeitig vielen Nutzern zur Verfügung stehen oder auch komplett als lokales System auf einzelnen Rechnern installiert werden. </Pgraph><Pgraph>ActionScript als Programmiersprache der Flash-Umgebung bietet u.a. klassenbasierte Objektorientierung und XML als nativen Datentyp für die Verarbeitung der Inhalte des MedBiquitous-Modells. Für die Sprachausgabe des virtuellen Patienten wird ein Text-to-Speech-System genutzt (Voice RSS: <Hyperlink href="http://www.voicerss.org/">http://www.voicerss.org/</Hyperlink>).</Pgraph><SubHeadline>PureMVC-Framework</SubHeadline><Pgraph>Das Frontend des MedEmergency-Players soll möglichst einfach an unterschiedliche Fachgebiete und Lernkonzepte angepasst werden können. Daten, Benutzerschnittstelle und Programmlogik werden daher möglichst unabhängig voneinander gehalten. So kann z.B. die Benutzeroberfläche an ein anderes Fachgebiet ohne aufwändige Anpassungen der anderen Programmteile adaptiert werden. </Pgraph><Pgraph>Für diese Anforderungen lässt sich das PureMVC-Framework als Mikroarchitektur einsetzen, da es auf dem MVC-Entwurfsmuster basiert. Änderungen der Software und des komplexen MedBiquitous-Modells werden durch die Aufteilung in <Mark1>M</Mark1>odel (Daten), <Mark1>V</Mark1>iew (Benutzerschnittstelle) und <Mark1>C</Mark1>ontroller (Programmlogik) vereinfacht. PureMVC ist für umfangreichere Anwendungen geeignet, die wie die MedEmergency Frontend-Komponente auf ActionScript basieren. Die Kommunikation zwischen den Hauptakteuren läuft nach festgelegten Regeln ab, hierbei werden u.a. Notifications als ein von den Flash Event-Klassen unabhängiges ergänzendes Beobachter-Benachrichtigungsmodell (Observer Pattern) verwendet <TextLink reference="21"></TextLink>. </Pgraph><Pgraph>Der Entwurf innerhalb des PureMVC-Frameworks erfolgt nach der von Hall vorgeschlagenen Vorgehensweise <TextLink reference="21"></TextLink>:</Pgraph><Pgraph>Zunächst werden Value Objects mit den Entitäten des XML-Modells und View Components für das GUI entworfen und getestet. Diese Bestandteile des Models sind unabhängig vom Rest des Systems und dienen als Gerüst für den restlichen Aufbau der Applikation. </Pgraph><Pgraph>Anschließend werden die Proxies für den Zugriff auf die Value Objects definiert, dann die Mediators für die „Vermittlung“ zwischen View Components und dem restlichen System. Die Implementierung der Commands zur Steuerung der Programmlogik erfolgt als letzter Schritt.</Pgraph><SubHeadline>MedBiquitous-Standard</SubHeadline><Pgraph>Die Grundlage für das Datenmodell des MedEmergency-Players ist der Standard nach MedBiquitous, der neben den Datenstrukturen <TextLink reference="22"></TextLink> auch Vorgaben für eine korre<TextGroup><PlainText>sp</PlainText></TextGroup>ondierende Virtual Patient Player-Software beschreibt <TextLink reference="23"></TextLink>. Das MedBiquitous-Modell besteht im Wesentlichen aus vier Hauptbestandteilen <TextLink reference="22"></TextLink>: ActivityModel, Dat<TextGroup><PlainText>aA</PlainText></TextGroup>vailabilityModel, VirtualPatientData und Manifest. Diese werden als getrennte XML-Dokumente codiert. Virtual Patient Data (VPD) beinhaltet ähnlich einer elektronischen Krankenakte die patientenbezogenen Daten des virtuellen Patienten wie z.B. Medikation, Therapiemaßnahmen etc. Media Resources (MR) verweisen auf multimediale Inhalte, während das Data Availability Model (DAM) seinerseits auf VPD- und MR-Elemente verweist und Inhalte für das Activity Model (AM) in einzelnen Knoten (DAM-Nodes) bündelt. Das AM stellt u.a. Handlungsoptionen für den Benutzer mittels einer Knotenstruktur zur Verfügung. Die Knoten (Activity Nodes) sind miteinander verlinkt und enthalten Verweise auf DAM-Nodes. DAM-Nodes, VPD- und MR-Elemente können durch verzweigte Verbindungen (XPath-Verweise) mehrfach benutzt werden, so dass die systembedingte Redundanz der XML-Daten reduziert wird.</Pgraph><Pgraph>Der Algorithmus eines Virtual Patient Player nach Me<TextGroup><PlainText>dBi</PlainText></TextGroup>quitous-Spezifikation besteht aus festgelegten Einzelschritten <TextLink reference="23"></TextLink>. Für den „Spielcharakter“ der Simulation sind hierbei u.a. die Strukturen Counter, CounterRules und CounterActionRules von Bedeutung. </Pgraph><Pgraph>Ein Counter repräsentiert einen einzelnen numerischen Wert, der sich abhängig von der Aktion des Benutzers verändern kann. So können beispielsweise Werte für die „Vital-/Simulationsparameter“ des Patienten (Blutdruck, Puls, „Gesundheit“ o.ä.) hinterlegt werden.</Pgraph><Pgraph>In einem Bereich des Activity Models werden die grundlegenden Eigenschaften der Counter festgelegt (ID, Bezeichnung, initialer Wert, Suffix/Präfix) und die Regeln für die vom Counter abhängigen Reaktionen des Programms definiert (CounterRules).</Pgraph><Pgraph>Die einem Counter zugeordneten CounterRules können eine oder mehrere Regeln (Rule) enthalten. In einer Rule ist relationaler Operator („Relation“) und ein Zahlenwert („Value“) codiert. Ist der aus diesen Elementen und dem aktuellen Wert des Counters zusammengesetzte Ausdruck wahr, wird der im Element „RuleRedirect“ als Pfad hinterlegte ActivityNode angesteuert. Im MedBiquitous-Modell werden die Regeln ausschließlich bei einem Wechsel des ActivityNode überprüft.</Pgraph><Pgraph>Im MedBiquitous-Modell wird der Wert eines Counters bei Ansteuerung eines bestimmten Activity-Nodes verändert. Dies wird durch das Element „CounterActionRule“ des einzelnen ActivityNode definiert. Der CounterOperator bestimmt dabei die Art der Wertänderung (z.B. Addition), der CounterRuleValue enthält einen Operanden bzw. einen zuzuweisenden Wert. Im CounterPath befindet sich ein Verweis im XPath-Format auf den zu ändernden Counter.</Pgraph><Pgraph>Die „Weiterschaltung“ zu einem neuen ActivityNode erfolgt nach MedBiquitous-Standard erst durch dezidiertes Anklicken eines Navigationselements bzw. nach Überprüfung entsprechender Bedingungen vor Eintritt in einen Activity Node.</Pgraph></TextBlock> <TextBlock linked="yes" name="Ergebnisse"> <MainHeadline>Ergebnisse</MainHeadline><Pgraph>Mit dem MedEmergency-Player lassen sich Aspekte der Notfallbehandlung eines Patienten während einer zahnmedizinischen Behandlung simulieren. Hierzu kann der Benutzer die Anamnese, Diagnose und Therapie durchführen, der virtuelle Patient gibt daraufhin entsprechende Rückmeldungen in textlicher oder audiovisueller Form. </Pgraph><Pgraph>Die Architektur des MedEmergency-Player-Systems wird zusammenfassend anhand eines Verteilungsdiagramms in Abbildung 1 <ImgLink imgNo="1" imgType="figure"/> dargestellt.</Pgraph><SubHeadline>XML-Daten des virtuellen Patienten</SubHeadline><Pgraph>Die XML-Daten eines virtuellen Patienten werden gemäß dem Verteilungsdiagramm in Abbildung 1 <ImgLink imgNo="1" imgType="figure"/> in Tabellenform in einem XML-enabled DBMS gespeichert. Aus den einzelnen getrennten Bestandteilen der Datenstruktur werden relevante Abschnitte zunächst durch den SQL Server über Stored Procedures extrahiert, teilweise aufbereitet und neu zusammengestellt. Somit können für die Weiterverarbeitung „fertig vorbereitete“ XML-Inhalte bereitgestellt werden. </Pgraph><Pgraph>Die vom Server bereitgestellten XML-Daten werden <TextGroup><PlainText>anschließend</PlainText></TextGroup> an die Frontend-Komponente mittels <TextGroup><PlainText>HTTPService</PlainText></TextGroup> weitervermittelt. Das Ergebnisformat e4x ermöglicht hierbei eine direkte Weiterverarbeitung durch Actio<TextGroup><PlainText>nS</PlainText></TextGroup>cript-Methoden. Auf die zur Laufzeit unveränderlichen XML-Inhalte wird mit dem REST-Architekturstil zugegriffen.</Pgraph><Pgraph>Die im Web-Browser mit Hilfe des Flash Player-Plugins betriebene Frontend-Komponente verarbeitet die erhaltenen Daten durch Algorithmen der (angepassten) Me<TextGroup><PlainText>dB</PlainText></TextGroup>iquitous Player-Spezifikation. Die Interaktion mit dem virtuellen Patienten erfolgt über eine grafische Benutzeroberfläche mit integrierter Sprachausgabe.</Pgraph><SubHeadline>MedEmergency-Player-Frontend</SubHeadline><Pgraph>Bei der Gestaltung der Benutzerschnittstelle wurde ein möglichst übersichtlicher Aufbau ohne Überfrachtung mit zu vielen Programmsymbolen gewählt. Somit ist auch <TextGroup><PlainText>ein E</PlainText></TextGroup>insatz auf mobilen Geräte (Smartphone, Tablet) einfach möglich. Die Flex-Standardkomponenten (Buttons, TextAreas etc.) wurden in Ihrer Gestaltung modifiziert (abgerundete Kanten, Buttons mit semitransparenten Icons etc.). Der Bildschirmaufbau wurde in drei Bereiche aufgeteilt. Abbildung 2 <ImgLink imgNo="2" imgType="figure"/> zeigt dies anhand eines implementierten Beispielpatienten:</Pgraph><Pgraph><UnorderedList><ListItem level="1">ein Feld für Multimediakomponenten (Grafiken, Animationen etc.) u.a. für die Möglichkeit bildhafter Darstellung der Behandlungssituation,</ListItem><ListItem level="1">ein Textfeld für die Ausgabe von Patientenreaktionen, Befunden, Bewertungen und sonstigen Programmmeldungen, </ListItem><ListItem level="1">die Menüleiste mit Icons für Medikation, Interviewfragen, nicht-medikamentöse Therapie (z.B. Beatmung), Labor- und physikalischen Untersuchungen (z.B. Blutzucker-/Blutdruckmessung).</ListItem></UnorderedList></Pgraph><Pgraph>Ein Untermenü mit Handlungsoptionen erscheint als (Advanced)DataGrid durch Anklicken der Buttons. Bei Auswahl von Interviewfragen erfolgt eine Ausgabe im Textfeld und zusätzlich eine Sprachausgabe der Antwort des Patienten. Die Menüpunkte werden in der XML-Struktur des virtuellen Patienten festgelegt und lassen sich somit flexibel an die Aufgabenstellung anpassen (XML-Elemente des Bereichs VirtualPatientData des Modells, z.B. InterviewItem, Medication, DiagnosticTest etc.).</Pgraph><SubHeadline>PureMVC-Framework</SubHeadline><Pgraph>Das Frontend verwendet das PureMVC-Framework <TextLink reference="21"></TextLink> und ist entsprechend dem Meta-Entwurfsmuster MVC in drei Pakete „model“, „view“ und „controller“ unterteilt:</Pgraph><Pgraph>Das Paket „model“ enthält Proxy-Klassen für die Bereitstellung und Speicherung von (XML)-Daten des virtuellen Patienten (z.B. ActivityNodes, Links, Counter etc.). Für die temporäre Datenspeicherung werden „value object"-Klassen benutzt.</Pgraph><Pgraph>Das Paket „view“ definiert die grafische Benutzeroberfläche des MedEmergency-Players durch die Klassen der View Components. Den View Components sind Mediator-Klassen zugeordnet. Eine View Component kann über eine Event-Klasse Nachrichten an eine ihr zugehörige Instanz einer Mediator-Klasse senden. Das Mediator-Objekt verbindet wiederum die zugeordnete View Component durch bidirektionalen Datenaustausch mit dem Rest der Applikation.</Pgraph><Pgraph>Im Paket „controller“ befinden sich Command-Klassen zur Steuerung der Programmlogik und zur Initialisierung des PureMVC-Frameworks. Command-Klassen können Zugang zu den Klassen der Pakete „view“ und „model“ haben.</Pgraph><SubHeadline>MedBiquitous-Standard</SubHeadline><Pgraph>Der handlungsorientierte MedEmergency-Player ermöglicht eine optionale direkte Weiterschaltung nach einer oder mehreren vorher festgelegten Benutzerinteraktionen mit dem VPD-Bereich des Modells (z.B. Medikamenteng<TextGroup><PlainText>ab</PlainText></TextGroup>e) zum nächsten ActivityNode. </Pgraph><Pgraph>Parameter des virtuellen Patienten (z.B. der Blutdruck) können ohne zwingende Rückmeldung verändert werden. So würde z.B. der Blutdruck durch ein Medikament noch nicht ausreichend gesenkt; erst durch eine weitere Dosis wird ein Wert der Counter-Variablen erreicht, der zu einem anderen ActivityNode mit entsprechender Rückmeldung führt.</Pgraph><Pgraph>Daher werden Counter nicht nur bei der Behandlung <TextGroup><PlainText>von A</PlainText></TextGroup>ctivityNodes anhand von CounterRules geprüft und durch CounterActionRules verändert, sondern auch bei einer Interaktion des Benutzers mit VPD-Elementen. Die Syntax der im Bereich der VPD-Elemente ergänzten <TextGroup><PlainText>CounterActionRules</PlainText></TextGroup> ist analog zu den ActivityNode-A<TextGroup><PlainText>bs</PlainText></TextGroup>chnitten aufgebaut (s. Abbildung 3 <ImgLink imgNo="3" imgType="figure"/>).</Pgraph></TextBlock> <TextBlock linked="yes" name="Diskussion"> <MainHeadline>Diskussion</MainHeadline><Pgraph>Im Bereich des zahnmedizinischen Notfalltrainings ist der unterstützende Einsatz virtueller Patienten als computergestütztes interaktives Patientenszenario naheliegend: Studenten und Zahnärzte könnten mit ihrer Hilfe gefahrlos Diagnose- und Therapieaspekte ohne Angst vor Fehlern erlernen, da reale Notfallpatienten zu Übungszwecken nicht verfügbar sind. Im Bereich der Notfalltherapie ist nach Literaturrecherche und dem Kenntnisstand des Autors jedoch bislang kein derartiges System bekannt.</Pgraph><Pgraph>Der in dieser Arbeit vorgestellte MedEmergency-Player simuliert mit Hilfe eines solchen virtuellen Patienten Aspekte der Notfallbehandlung während einer zahnmedizinischen Therapie. Hierbei kann der Benutzer mit Hilfe der Software notwendige schnelle Entscheidungen als Ergänzung zu praktischen Übungen trainieren. Die Programmfunktionen bei Diagnose und Therapie eines solchen simulierten Behandlungszwischenfalls verdeutlicht ein für das System beispielhaft erstellter Notfallpatient. </Pgraph><Pgraph>Virtuelle Patienten als computergestützte interaktive Patientenszenarios werden in der Zahnmedizin selten beschrieben <TextLink reference="3"></TextLink>, <TextLink reference="4"></TextLink>, <TextLink reference="5"></TextLink>, <TextLink reference="6"></TextLink>, <TextLink reference="7"></TextLink>, <TextLink reference="8"></TextLink>, <TextLink reference="9"></TextLink>, <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>, <TextLink reference="12"></TextLink>, <TextLink reference="13"></TextLink>, <TextLink reference="14"></TextLink>. Bei der Entwicklung des MedEmergency-Players sollten daher in der Literatur beobachtete „Stolpersteine“ realisierter Simulationen möglichst vermieden werden, die den Einsatz virtueller Patienten behindern: Virtuelle Patienten zu erstellen ist aufwändig und zeitintensiv, vorhandene Ressourcen müssen effektiv eingesetzt werden. Ein Standard wie der nach ANSI/ Me<TextGroup><PlainText>dBiq</PlainText></TextGroup>uitous kann diese Aufgabe erleichtern: Durch vorgegebene Datenstrukturen und Algorithmen eines Virtual Patient Player lassen sich virtuelle Patienten einfacher erstellen, anpassen und wiederverwenden <TextLink reference="15"></TextLink>.</Pgraph><Pgraph>Nach Literaturrecherche und Kenntnisstand des Autors wird lediglich für das Web-SP System die Implementierung des MedBiquitous-Standards beschrieben <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>. Auch für das MedEmergency-Simulationssystem konnte das MedBiquitous-Modell mit einigen Erweiterungen eingesetzt werden. Der Handlungsablauf kann hierbei wie bei anderen Systemen verzweigt und linear vorge<TextGroup><PlainText>ge</PlainText></TextGroup>ben sein. Auch problemlösungsorientierte/globale Strukturen mit flexibler Auswahl von Anamnese- und Diagnoseschritten wie beim Web-SP System sind möglich. Zusätzlich kann der Benutzer jederzeit flexibel Therapieoptionen auswählen und die Auswirkungen auf die <TextGroup><PlainText>„(Vital-)P</PlainText></TextGroup>arameter“ des virtuellen Patienten direkt erfahren und beobachten. Dies wurde durch eine Adaption des Me<TextGroup><PlainText>dBiq</PlainText></TextGroup>uitous-Standards erreicht, indem die zur Programmsteuerung erforderlichen Counter auch bei Interaktion des Benutzers mit Befund- und Therapieoptionen (VPD-Elementen) des virtuellen Patienten anhand zugehöriger Regeln geprüft werden. Die bisher übliche „Weiterschaltung“ zu einem neuen Handlungsknoten (ActivityNode) durch das Anklicken eines Navigationsel<TextGroup><PlainText>em</PlainText></TextGroup>ents wird umgangen. Die Simulation entspricht so eher einer realen Behandlungssituation als ein festgelegter Ablauf mit sequentiellen Handlungsoptionen.</Pgraph><Pgraph>Bei einem ressourcenschonenden System sollten sich virtuelle Patienten ohne spezielle Fachkenntnisse und möglichst auch für unterschiedliche Fachgebiete unkompliziert erstellen lassen. Vorhandene Systeme zeigen hierbei unterschiedliche Ausprägungen der Anpassbarkeit: von einer für eine Anwendung speziell erstellten Webseite <TextLink reference="8"></TextLink> über Systeme für ein einzelnes Fachgebiet mit anpassbaren Inhalten <TextLink reference="9"></TextLink> bis hin zu flexiblen Systemen mit flexiblen Inhalten und unterschiedlichen Fachgebieten <TextLink reference="4"></TextLink>, <TextLink reference="6"></TextLink>, <TextLink reference="7"></TextLink>, <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>, <TextLink reference="12"></TextLink>. </Pgraph><Pgraph>Die Anpassungsmöglichkeiten werden z.T. nicht genauer beschrieben, in einigen Fällen finden sich weitergehende Erläuterungen. Das ältere CASE-System verwendet vorgegebene Schablonen (Macromedia Authorware), die ohne Fachkenntnisse ausgefüllt werden können <TextLink reference="6"></TextLink>. Die Flexibilität ist hier eingeschränkt, da der Benutzer die Schablonen nicht verändern kann. Ein hohes Maß an Flexibilität bietet die Autorenkomponente des Web-SP Systems. Der Benutzer kann Vorlagen virtueller Patienten mit hinterlegten medizinischen Inhalten benutzen oder existierende Fälle anpassen <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>. Für das MedEmergency-System existiert zurzeit nur eine Player-Komponente, so dass die Inhalte mit einem XML-Editor entsprechend dem MedBiquitous-Standard eingegeben werden müssen. Die XML-Struktur ermöglicht hierbei frei anpassbare Inhalte auch für unterschiedliche Fachgebiete.</Pgraph><Pgraph>Idealerweise sollte sich auch die Software und insbesondere die Benutzeroberfläche leicht anpassen lassen. Dies kann z.B. bei der Verwendung in einem anderen Fachgebiet erforderlich werden. Je spezialisierter ein System ist und umso mehr Inhalte und Programmstruktur verbunden sind, umso aufwändiger ist eine Veränderung. So müsste z.B. eine speziell für einen virtuellen Patienten erstellten Webseite <TextLink reference="8"></TextLink> komplett umgeändert bzw. neu erstellt werden.</Pgraph><Pgraph>Das für den MedEmergency-Player eingesetzte PureMVC-Framework ermöglicht hingegen eine strikte Trennung von Datenmodell, Benutzeroberfläche und Programmlogik des Frontends. Die mit Flash Builder erstellte Benutzeroberfläche kann unabhängig vom Rest der Applikation mit geringem Aufwand geändert werden. Die Menüinhalte sind in der XML-Struktur hinterlegt und somit flexibel, so dass ein Einsatz in unterschiedlichen Fachbereichen ohne Änderung der Software erleichtert wird. Auch Variablen, Zähler und Verhalten werden so codiert, dass das Frontend unabhängig vom konkreten virtuellen Patienten ist. Das Frontend erhält die virtuellen Patientendaten unabhängig durch Proxies und separate Delegates vom Server. Dadurch werden Änderungen der Serverarchitektur erleichtert.</Pgraph><Pgraph>Für den verbreiteten Einsatz virtueller Patienten sollte sich die Player-Software benutzerseitig unkompliziert und ohne besondere Hardwareanforderungen einsetzen lassen. Hierbei ist nur das älteste System ODSDM/DDx&Tx nicht plattformunabhängig und muss als komplexes System installiert werden, zumal es zusätzliche Komponenten wie einen Videodisk-Player zur Darstellung der virtuellen Patienten verwendet <TextLink reference="3"></TextLink>, <TextLink reference="4"></TextLink>, <TextLink reference="5"></TextLink>. Der Einsatz für den Benutzer ist somit erschwert. Ältere Systeme auf Basis von Macromedia Authorware werden auf einer CD-ROM als ausführbare Dateien zur Verfügung gestellt <TextLink reference="6"></TextLink>, <TextLink reference="9"></TextLink>, wären aber prinzipiell auf Windows- und Mac OS-Systemen ausführbar. Die übrigen Systeme sind bereits webbasiert <TextLink reference="7"></TextLink>, <TextLink reference="8"></TextLink>, <TextLink reference="10"></TextLink>, <TextLink reference="11"></TextLink>, <TextLink reference="12"></TextLink>, <TextLink reference="13"></TextLink>, <TextLink reference="14"></TextLink>, so dass sie sich für den Benutzer unkompliziert im Webbrowser darstellen lassen. Die Flex-Frontend-Komponente des MedEmergency-Players erlaubt ebenfalls eine plattformunabhängige Darstellung ohne Installationsaufwand im Browser des Anwendercomputers. Durch die abschnittsweise Weitervermittlung bereits vom Server aufbereiteter XML-Daten sind die benutzerseitigen Hardwareanforderungen hierbei gering: Das Frontend muss nicht die gesamten Dateien im Speicher vorhalten und verarbeiten.</Pgraph><Pgraph>Zusammenfassend ließ sich mit dem MedEmergency-Player eine anpassbare und plattformunabhängige Software zur Simulation virtueller Patienten für das zahnmedizinische Notfalltraining konzipieren. Hierbei konnte der MedBiquitous-Standard verwendet und adaptiert werden. Zur Steigerung der Realitätsnähe kann der Benutzer im Unterschied zu vorhandenen Systemen die „(Vital-)Parameter“ der virtuellen Patienten direkt beeinflussen und erfahren.</Pgraph></TextBlock> <TextBlock linked="yes" name="Ausblick"> <MainHeadline>Ausblick</MainHeadline><Pgraph>Der MedEmergency-Player kann auch in anderen (medizinischen) Fachbereichen eingesetzt werden, da (multimediale) Inhalte und Verhalten des virtuellen Patienten in einer XML-Struktur kodiert werden. Auch die Menüi<TextGroup><PlainText>nh</PlainText></TextGroup>alte sind dadurch flexibel, wobei die Gliederung in Anamnese, Diagnose und Therapie im Frontend festgelegt ist. Diese ist allerdings bei jeder (zahn-)medizinischen Behandlung relevant. Eine Änderung wird durch das MVC-Entwurfsmuster und die Möglichkeiten von Flash Builder zum vereinfachten Redesign des GUI erleichtert.</Pgraph><Pgraph>Auch innerhalb des Fachgebietes Zahnmedizin sind weitere Einsatzbereiche denkbar, so z.B. die Simulation einer Notfallbehandlung bei akuten Schmerzzuständen. Hierbei ließe sich ein rasches und systematisches Vorgehen mit der MedEmergency-Software trainieren. Eine Anpassung an differierende Lehrmeinungen ist durch Änderung der XML-Inhalte möglich.</Pgraph><Pgraph>Für die Weiterentwicklung des MedEmergency-Players ist die Zukunft der Flash-Plattform von Interesse. Trotz der weiten Verbreitung wird die Bedeutung des Flash-Players als Webbrowser Plug-In weiter abnehmen, während HTML/JavaScript die entsprechenden Aufgaben übernimmt. Diese Entwicklung ist momentan allerdings noch „im Fluss“, so dass eher für die Flash-Plattform ausgereifte „Komplettlösungen“ zur Softwareentwicklung verfügbar sind. Eine aufwändige Anpassung des Me<TextGroup><PlainText>dE</PlainText></TextGroup>mergency-Players an verschiedene Browser(-versionen) ist nicht erforderlich. Die Anwendung hat einen <TextGroup><PlainText>begrenzten</PlainText></TextGroup> Adressatenkreis und lässt sich alternativ auf mobilen und Desktop-Geräten mit der Laufzeitumgebung Adobe Air betreiben. Selbst eine Portierung nach HTML/Jav<TextGroup><PlainText>aS</PlainText></TextGroup>cript wäre aufgrund des modularen Aufbaus denkbar; die Änderung beträfe zudem nur das Frontend. Die Programmlogik ließe sich u.U. mit einer ausgereiften Version des FlexJS-SDK nach JavaScript übersetzen. Weiterhin ist das verwendete PureMVC-Framework von plattformspezifischen Strukturen wie den Flash Event-Klassen unabhängig und existiert auch in einer Version für JavaScript. </Pgraph><Pgraph>Bevor weitere Funktionen implementiert werden, sollte die Software systematisch evaluiert werden. Der Me<TextGroup><PlainText>dE</PlainText></TextGroup>mergency-Player könnte zunächst ergänzend zu einer Ausbildungsmaßnahme oder zum Selbststudium online zur Verfügung gestellt werden. Je nach Zielgruppe können sinnvolle Veränderungen und Erweiterungen erfolgen. Möglich wäre z.B. ein Bewertungssystem oder ein Autorensubsystem zur einfacheren Erstellung virtueller Patienten.</Pgraph></TextBlock> <TextBlock linked="yes" name="Anmerkungen"> <MainHeadline>Anmerkungen</MainHeadline><SubHeadline>Interessenkonflikte</SubHeadline><Pgraph>Der Autor erklärt, dass er keine Interessenkonflikte in Zusammenhang mit diesem Artikel hat.</Pgraph><SubHeadline>Danksagung</SubHeadline><Pgraph>Mein besonderer Dank gilt Herrn Prof. Dr. Martin Haag, Hochschule Heilbronn für fachlichen Rat und Unterstützung.</Pgraph></TextBlock> <References linked="yes"> <Reference refNo="1"> <RefAuthor>Kononowicz AA</RefAuthor> <RefAuthor>Zary N</RefAuthor> <RefAuthor>Edelbring S</RefAuthor> <RefAuthor>Corral J</RefAuthor> <RefAuthor>Hege I</RefAuthor> <RefTitle>Virtual patients – what are we talking about? A framework to classify the meanings of the term in healthcare education</RefTitle> <RefYear>2015</RefYear> <RefJournal>BMC Med Educ</RefJournal> <RefPage>11</RefPage> <RefTotal>Kononowicz AA, Zary N, Edelbring S, Corral J, Hege I. Virtual patients – what are we talking about? A framework to classify the meanings of the term in healthcare education. BMC Med Educ. 2015 Feb;15:11. DOI: 10.1186/s12909-015-0296-3</RefTotal> <RefLink>http://dx.doi.org/10.1186/s12909-015-0296-3</RefLink> </Reference> <Reference refNo="2"> <RefAuthor>Ellaway R</RefAuthor> <RefAuthor>Candler C</RefAuthor> <RefAuthor>Greene P</RefAuthor> <RefAuthor>Smothers V</RefAuthor> <RefTitle></RefTitle> <RefYear>2006</RefYear> <RefBookTitle>An Architectural Model for MedBiquitous Virtual Patients</RefBookTitle> <RefPage></RefPage> <RefTotal>Ellaway R, Candler C, Greene P, Smothers V. An Architectural Model for MedBiquitous Virtual Patients. Baltimore: MedBiquitous Consortium; 2006 [cited 2017 Jan 11]. Available from: http://groups.medbiq.org/medbiq/display/VPWG/MedBiquitous+Virtual+Patient+Architecture</RefTotal> <RefLink>http://groups.medbiq.org/medbiq/display/VPWG/MedBiquitous+Virtual+Patient+Architecture</RefLink> </Reference> <Reference refNo="3"> <RefAuthor>Finkelstein MW</RefAuthor> <RefAuthor>Johnson LA</RefAuthor> <RefAuthor>Lilly GE</RefAuthor> <RefTitle>Interactive videodisc patient simulations of oral diseases</RefTitle> <RefYear>1988</RefYear> <RefJournal>J Dent Educ</RefJournal> <RefPage>217-20</RefPage> <RefTotal>Finkelstein MW, Johnson LA, Lilly GE. Interactive videodisc patient simulations of oral diseases. J Dent Educ. 1988 Apr;52(4):217-20.</RefTotal> </Reference> <Reference refNo="4"> <RefAuthor>Clancy JM</RefAuthor> <RefAuthor>Johnson L</RefAuthor> <RefAuthor>Finkelstein MW</RefAuthor> <RefAuthor>Lilly GE</RefAuthor> <RefTitle>Dental diagnosis and treatment (DDx&Tx): Interactive videodisc patient simulations for dental education</RefTitle> <RefYear>1990</RefYear> <RefJournal>Comput Methods Programs Biomed</RefJournal> <RefPage>21-6</RefPage> <RefTotal>Clancy JM, Johnson L, Finkelstein MW, Lilly GE. Dental diagnosis and treatment (DDx&Tx): Interactive videodisc patient simulations for dental education. Comput Methods Programs Biomed. 1990; 33(1):21-6. DOI: 10.1016/0169-2607(90)90019-6</RefTotal> <RefLink>http://dx.doi.org/10.1016/0169-2607(90)90019-6</RefLink> </Reference> <Reference refNo="5"> <RefAuthor>Finkelstein MW</RefAuthor> <RefAuthor>Johnson LA</RefAuthor> <RefAuthor>Lilly GE</RefAuthor> <RefTitle>A computer management system for patient simulations</RefTitle> <RefYear>1991</RefYear> <RefJournal>Comput Methods Programs Biomed</RefJournal> <RefPage>257-61</RefPage> <RefTotal>Finkelstein MW, Johnson LA, Lilly GE. A computer management system for patient simulations. Comput Methods Programs Biomed. 1991;34(4):257-61. DOI: 10.1016/0169-2607(91)90109-7</RefTotal> <RefLink>http://dx.doi.org/10.1016/0169-2607(91)90109-7</RefLink> </Reference> <Reference refNo="6"> <RefAuthor>Abbey LM</RefAuthor> <RefAuthor>Arnold P</RefAuthor> <RefAuthor>Halunko L</RefAuthor> <RefAuthor>Huneke MB</RefAuthor> <RefAuthor>Lee S</RefAuthor> <RefTitle>CASE STUDIES for Dentistry: development of a tool to author interactive, multimedia, computer-based patient simulations</RefTitle> <RefYear>2003</RefYear> <RefJournal>J Dent Educ</RefJournal> <RefPage>1345-54</RefPage> <RefTotal>Abbey LM, Arnold P, Halunko L, Huneke MB, Lee S. CASE STUDIES for Dentistry: development of a tool to author interactive, multimedia, computer-based patient simulations. J Dent Educ. 2003 Dec;67(12):1345-54.</RefTotal> </Reference> <Reference refNo="7"> <RefAuthor>Schittek Janda M</RefAuthor> <RefAuthor>Mattheos N</RefAuthor> <RefAuthor>Nattestad A</RefAuthor> <RefAuthor>Wagner A</RefAuthor> <RefAuthor>Nebel D</RefAuthor> <RefAuthor>Färbom C</RefAuthor> <RefAuthor>Lê DH</RefAuthor> <RefAuthor>Attström R</RefAuthor> <RefTitle>Simulation of patient encounters using a virtual patient in periodontology instruction of dental students: design, usability, and learning effect in history-taking skills</RefTitle> <RefYear>2004</RefYear> <RefJournal>Eur J Dent Educ</RefJournal> <RefPage>111-9</RefPage> <RefTotal>Schittek Janda M, Mattheos N, Nattestad A, Wagner A, Nebel D, Färbom C, Lê DH, Attström R. Simulation of patient encounters using a virtual patient in periodontology instruction of dental students: design, usability, and learning effect in history-taking skills. Eur J Dent Educ. 2004 Aug;8(3):111-9. DOI: 10.1111/j.1600-0579.2004.00339.x</RefTotal> <RefLink>http://dx.doi.org/10.1111/j.1600-0579.2004.00339.x</RefLink> </Reference> <Reference refNo="8"> <RefAuthor>Boynton JR</RefAuthor> <RefAuthor>Green TG</RefAuthor> <RefAuthor>Johnson LA</RefAuthor> <RefAuthor>Nainar SM</RefAuthor> <RefAuthor>Straffon LH</RefAuthor> <RefTitle>The virtual child: evaluation of an internet-based pediatric behavior management simulation</RefTitle> <RefYear>2007</RefYear> <RefJournal>J Dent Educ</RefJournal> <RefPage>1187-93</RefPage> <RefTotal>Boynton JR, Green TG, Johnson LA, Nainar SM, Straffon LH. The virtual child: evaluation of an internet-based pediatric behavior management simulation. J Dent Educ. 2007 Sep;71(9):1187-93.</RefTotal> </Reference> <Reference refNo="9"> <RefAuthor>Littlefield JH</RefAuthor> <RefAuthor>Demps EL</RefAuthor> <RefAuthor>Keiser K</RefAuthor> <RefAuthor>Chatterjee L</RefAuthor> <RefAuthor>Yuan CH</RefAuthor> <RefAuthor>Hargreaves KM</RefAuthor> <RefTitle>A multimedia patient simulation for teaching and assessing endodontic diagnosis</RefTitle> <RefYear>2003</RefYear> <RefJournal>J Dent Educ</RefJournal> <RefPage>669-77</RefPage> <RefTotal>Littlefield JH, Demps EL, Keiser K, Chatterjee L, Yuan CH, Hargreaves KM. A multimedia patient simulation for teaching and assessing endodontic diagnosis. J Dent Educ. 2003 Jun;67(6):669-77.</RefTotal> </Reference> <Reference refNo="10"> <RefAuthor>Zary N</RefAuthor> <RefAuthor>Johnson G</RefAuthor> <RefAuthor>Fors U</RefAuthor> <RefTitle>Web-based virtual patients in dentistry: factors influencing the use of cases in the Web-SP system</RefTitle> <RefYear>2009</RefYear> <RefJournal>Eur J Dent Educ</RefJournal> <RefPage>2-9</RefPage> <RefTotal>Zary N, Johnson G, Fors U. Web-based virtual patients in dentistry: factors influencing the use of cases in the Web-SP system. Eur J Dent Educ. 2009 Feb;13(1):2-9. DOI: 10.1111/j.1600-0579.2007.00470.x</RefTotal> <RefLink>http://dx.doi.org/10.1111/j.1600-0579.2007.00470.x</RefLink> </Reference> <Reference refNo="11"> <RefAuthor>Lund B</RefAuthor> <RefAuthor>Fors U</RefAuthor> <RefAuthor>Sejersen R</RefAuthor> <RefAuthor>Sallnäs EL</RefAuthor> <RefAuthor>Rosén A</RefAuthor> <RefTitle>Student perception of two different simulation techniques in oral and maxillofacial surgery undergraduate training</RefTitle> <RefYear>2011</RefYear> <RefJournal>BMC Med Educ</RefJournal> <RefPage>82</RefPage> <RefTotal>Lund B, Fors U, Sejersen R, Sallnäs EL, Rosén A. Student perception of two different simulation techniques in oral and maxillofacial surgery undergraduate training. BMC Med Educ. 2011 Oct;11:82. DOI: 10.1186/1472-6920-11-82</RefTotal> <RefLink>http://dx.doi.org/10.1186/1472-6920-11-82</RefLink> </Reference> <Reference refNo="12"> <RefAuthor>Clark GT</RefAuthor> <RefAuthor>Suri A</RefAuthor> <RefAuthor>Enciso R</RefAuthor> <RefTitle>Autonomous virtual patients in dentistry: system accuracy and expert versus novice comparison</RefTitle> <RefYear>2012</RefYear> <RefJournal>J Dent Educ</RefJournal> <RefPage>1365-70</RefPage> <RefTotal>Clark GT, Suri A, Enciso R. Autonomous virtual patients in dentistry: system accuracy and expert versus novice comparison. J Dent Educ. 2012 Oct;76(10):1365-70.</RefTotal> </Reference> <Reference refNo="13"> <RefAuthor>Papadopoulos L</RefAuthor> <RefAuthor>Pentzou AE</RefAuthor> <RefAuthor>Louloudiadis K</RefAuthor> <RefAuthor>Tsiatsos TK</RefAuthor> <RefTitle>Design and evaluation of a simulation for pediatric dentistry in virtual worlds</RefTitle> <RefYear>2013</RefYear> <RefJournal>J Med Internet Res</RefJournal> <RefPage>e240</RefPage> <RefTotal>Papadopoulos L, Pentzou AE, Louloudiadis K, Tsiatsos TK. Design and evaluation of a simulation for pediatric dentistry in virtual worlds. J Med Internet Res. 2013 Oct;15(11):e240. DOI: 10.2196/jmir.2651</RefTotal> <RefLink>http://dx.doi.org/10.2196/jmir.2651</RefLink> </Reference> <Reference refNo="14"> <RefAuthor>Antoniou PE</RefAuthor> <RefAuthor>Athanasopoulou CA</RefAuthor> <RefAuthor>Dafli E</RefAuthor> <RefAuthor>Bamidis PD</RefAuthor> <RefTitle>Exploring design requirements for repurposing dental virtual patients from the web to second life: a focus group study</RefTitle> <RefYear>2014</RefYear> <RefJournal>J Med Internet Res</RefJournal> <RefPage>e151</RefPage> <RefTotal>Antoniou PE, Athanasopoulou CA, Dafli E, Bamidis PD. Exploring design requirements for repurposing dental virtual patients from the web to second life: a focus group study. J Med Internet Res. 2014 Jun;16(6):e151. DOI: 10.2196/jmir.3343</RefTotal> <RefLink>http://dx.doi.org/10.2196/jmir.3343</RefLink> </Reference> <Reference refNo="15"> <RefAuthor>Cook DA</RefAuthor> <RefAuthor>Triola MM</RefAuthor> <RefTitle>Virtual patients: a critical literature review and proposed next steps</RefTitle> <RefYear>2009</RefYear> <RefJournal>Med Educ</RefJournal> <RefPage>303-11</RefPage> <RefTotal>Cook DA, Triola MM. Virtual patients: a critical literature review and proposed next steps. Med Educ. 2009 Apr;43(4):303-11. DOI: 10.1111/j.1365-2923.2008.03286.x</RefTotal> <RefLink>http://dx.doi.org/10.1111/j.1365-2923.2008.03286.x</RefLink> </Reference> <Reference refNo="16"> <RefAuthor>Triola MM</RefAuthor> <RefAuthor>Campion N</RefAuthor> <RefAuthor>McGee JB</RefAuthor> <RefAuthor>Albright S</RefAuthor> <RefAuthor>Greene P</RefAuthor> <RefAuthor>Smothers V</RefAuthor> <RefAuthor>Ellaway R</RefAuthor> <RefTitle>An XML standard for virtual patients: exchanging case-based simulations in medical education</RefTitle> <RefYear>2007</RefYear> <RefJournal>AMIA Annu Symp Proc</RefJournal> <RefPage>741-5</RefPage> <RefTotal>Triola MM, Campion N, McGee JB, Albright S, Greene P, Smothers V, Ellaway R. An XML standard for virtual patients: exchanging case-based simulations in medical education. AMIA Annu Symp Proc. 2007 Oct:741-5.</RefTotal> </Reference> <Reference refNo="17"> <RefAuthor>MedBiquitous Consortium</RefAuthor> <RefTitle></RefTitle> <RefYear></RefYear> <RefBookTitle>Virtual Patient Implementers</RefBookTitle> <RefPage></RefPage> <RefTotal>MedBiquitous Consortium. Virtual Patient Implementers. [cited 2017 Oct 18]. Available from: https://www.medbiq.org/virtual_patient/implementers</RefTotal> <RefLink>https://www.medbiq.org/virtual_patient/implementers</RefLink> </Reference> <Reference refNo="18"> <RefAuthor>Noaman AY</RefAuthor> <RefAuthor>Al Mansour AA</RefAuthor> <RefTitle>A Comparative Study Between Two Types of Database Management Systems: XML-Enabled Relational and Native XML</RefTitle> <RefYear>2012</RefYear> <RefJournal>World Appl Sci J</RefJournal> <RefPage>972-85</RefPage> <RefTotal>Noaman AY, Al Mansour AA. A Comparative Study Between Two Types of Database Management Systems: XML-Enabled Relational and Native XML. World Appl Sci J. 2012; 19(7):972-85.</RefTotal> </Reference> <Reference refNo="19"> <RefAuthor>Pfeil C</RefAuthor> <RefTitle></RefTitle> <RefYear>2009</RefYear> <RefBookTitle>Adobe AIR. RIAs für den Desktop entwickeln. Know-how für HTML/Ajax- und Flash/Flex-Entwickler</RefBookTitle> <RefPage></RefPage> <RefTotal>Pfeil C. Adobe AIR. RIAs für den Desktop entwickeln. Know-how für HTML/Ajax- und Flash/Flex-Entwickler. München: Addison-Wesley; 2009.</RefTotal> </Reference> <Reference refNo="20"> <RefAuthor>Adobe Systems</RefAuthor> <RefTitle></RefTitle> <RefYear>2012</RefYear> <RefBookTitle>Adobe’s view of Flex and its commitments to Flex in the future</RefBookTitle> <RefPage></RefPage> <RefTotal>Adobe Systems. Adobe’s view of Flex and its commitments to Flex in the future. San Jose: Adobe Systems; 2012 [cited 2017 Oct 18]. Available from: http://www.adobe.com/devnet/flex/whitepapers/roadmap.html</RefTotal> <RefLink>http://www.adobe.com/devnet/flex/whitepapers/roadmap.html</RefLink> </Reference> <Reference refNo="21"> <RefAuthor>Hall C</RefAuthor> <RefTitle></RefTitle> <RefYear>2011</RefYear> <RefBookTitle>ActionScript Developer’s Guide to PureMVC</RefBookTitle> <RefPage></RefPage> <RefTotal>Hall C. ActionScript Developer’s Guide to PureMVC. Sebastopol: O’Reilly Media; 2011.</RefTotal> </Reference> <Reference refNo="22"> <RefAuthor>Smothers V</RefAuthor> <RefAuthor>Azan B</RefAuthor> <RefAuthor>Ellaway R</RefAuthor> <RefTitle></RefTitle> <RefYear>2010</RefYear> <RefBookTitle>ANSI /MEDBIQ VP.10.1-2010. MedBiquitous Virtual Patient. Specifications and Description Document</RefBookTitle> <RefPage></RefPage> <RefTotal>Smothers V, Azan B, Ellaway R. ANSI /MEDBIQ VP.10.1-2010 MedBiquitous Virtual Patient Specifications and Description Document. Baltimore: MedBiquitous Consortium; 2010 [cited 2017 October 18]. Available from: http://www.medbiq.org/working_groups/virtual_patient/VirtualPatientDataSpecification.pdf</RefTotal> <RefLink>http://www.medbiq.org/working_groups/virtual_patient/VirtualPatientDataSpecification.pdf</RefLink> </Reference> <Reference refNo="23"> <RefAuthor>Azan B</RefAuthor> <RefAuthor>Smothers V</RefAuthor> <RefTitle></RefTitle> <RefYear>2010</RefYear> <RefBookTitle>ANSI /MEDBIQ VP. 10.1-2010. MedBiquitous Virtual Patient Player. Specifications and Description Document</RefBookTitle> <RefPage></RefPage> <RefTotal>Azan B, Smothers V. ANSI /MEDBIQ VP.10.1-2010. MedBiquitous Virtual Patient Player. Specifications and Description Document. Baltimore: MedBiquitous Consortium; 2010 [cited 2017 Oct 18]. Available from: http://medbiquitous.org/working_groups/virtual_patient/VirtualPatientPlayerSpecification.pdf</RefTotal> <RefLink>http://medbiquitous.org/working_groups/virtual_patient/VirtualPatientPlayerSpecification.pdf</RefLink> </Reference> </References> <Media> <Tables> <NoOfTables>0</NoOfTables> </Tables> <Figures> <Figure format="png" height="465" width="578"> <MediaNo>1</MediaNo> <MediaID>1</MediaID> <Caption><Pgraph><Mark1>Abbildung 1: Verteilungsdiagramm MedEmergency-Player-System</Mark1></Pgraph></Caption> </Figure> <Figure format="png" height="607" width="861"> <MediaNo>2</MediaNo> <MediaID>2</MediaID> <Caption><Pgraph><Mark1>Abbildung 2: GUI MedEmergency-Player mit Icons für Diagnose und Therapie, Untermenü Medikation</Mark1> </Pgraph></Caption> </Figure> <Figure format="png" height="451" width="800"> <MediaNo>3</MediaNo> <MediaID>3</MediaID> <Caption><Pgraph><Mark1>Abbildung 3: Erweiterung Schema durch CounterActionRule</Mark1></Pgraph></Caption> </Figure> <NoOfPictures>3</NoOfPictures> </Figures> <InlineFigures> <NoOfPictures>0</NoOfPictures> </InlineFigures> <Attachments> <NoOfAttachments>0</NoOfAttachments> </Attachments> </Media> </OrigData> </GmsArticle>