Swiss Medical Informatics

SMI 72 SGMI Schweizerische Gesellschaft für Medizinische Informatik Swiss Medical Informatics SSIM Société suisse d informatique médicale Società svizzera d informatica medicale SSMI Swiss Society for Medical Informatics Inhalt/Content/Contenu Editorial Technological choices for mobile clinical applications Ökonomische Auswirkungen der s pitalweiten Einführung des digitalen Diktierens am UniversitätsSpital Zürich Evaluation und Parametrierung eines Patienten datenmanagementsystems Automatisierte Plausibilitätsprüfung der elektronischen Pflegedokumentation auf somatischen Allgemeinstationen Effizienzsteigerung dank Planungssoftware? Implémentation d un itinéraire clinique dans le système d information clinique de l Hôpital du Valais Evolution d internet dans le domaine médical Infomed dossier patient partagé en Valais Modèle de données pour l analyse des flux de patients à l hôpital Intérêt et utilité de la normalisation de concepts par UMLS dans la construction d un dossier patient informatisé Proceedings 24. Jahrestagung SGMI 24 èmes Journées annuelles SSIM Wunsch und Wirklichkeit Espoirs et réalités Quality assurance of venous thromboprophylaxis in a university hospital Establishing CAISIS for biobank projects at the University Hospital Zurich Drug drug interactions who cares? Problems of standards in semantic i nteroperability Schwabe Verlag Basel

Table of contents Editorial Christian Lovis, Marc Oertle 2 Technological choices for mobile clinical applications Frederic Ehrler, David Issom, Christian Lovis 3 Ökonomische Auswirkungen der spitalweiten Einführung des digitalen Diktierens am UniversitätsSpital Zürich Ninoslav Teodorovic, Mechthild Uesbeck, Roland Naef 6 Evaluation und Parametrierung eines Patienten datenmanagementsystems: Ein Erfahrungsbericht Kay Stricker, Patrick Wettstein, Martin Felder, Matthias Kämpf 12 Automatisierte Plausibilitätsprüfung der elektronischen Pflegedokumentation auf somatischen Allgemeinstationen: Entwicklung von Regeln und Überprüfung der Regelgüte Jens Schall, Ursula Hübner 16 Effizienzsteigerung dank Planungssoftware? Jutta Spengler, Andreas Altorfer 18 Implémentation d un itinéraire clinique dans le système d information clinique de l Hôpital du Valais Roger Schaer, Pierre-Auguste Petignat, Alex Gnaegi 23 Evolution d internet dans le domaine médical Natalia Pletneva, Sarah Cruchet, Maria-Ana Simonet, Maki Kajiwara, Célia Boyer 27 Infomed dossier patient partagé en Valais Cédric Michelet, Frédéric Fragnière, Alex Gnaegi 31 Modèle de données pour l analyse des flux de patients à l hôpital Nicolas Anken, Eriam Schaffter, Rodolphe Meyer, Philippe Garnerin 35 Intérêt et utilité de la normalisation de concepts par UMLS dans la construction d un dossier patient informatisé Christine Cohen-Galvagni, Soumeya Achour, Paul Cohen 42 Quality assurance of venous thromboprophylaxis in a university hospital Patrick Beeler, Beatrice Amann-Vesti, Jürg Blaser 45 Establishing CAISIS for biobank projects at the University Hospital Zurich Steffen M. Zeisberger, Max Dürsteler, Rainer Warth, Peter Schraml, Daniel Simeon-Dubach, Simon P. Hoerstrup, Jürg Blaser 47 Drug-drug interactions who cares? Patrick Beeler, Christoph Rosen, Jürg Blaser 48 Problems of standards in semantic interoperability Hans Rudolf Straub, Michael Lehmann 49 1

Editorial Christian Lovis, Marc Oertle Herzlich willkommen zu der 24. Jahrestagung der Schweizerischen Gesellschaft für Medizinische I nformatik SGMI! Zum Thema «Wunsch und Wirklichkeit» können wir Ihnen neben zwei abwechslungsreichen Konferenztagen und vielen Posters auch die Proceedings anbieten. Der Wunsch nach vielfältigen und sorgfältig erarbeiteten Abbildern des Alltageinsatzes von Informatikmitteln im Gesundheitswesen ist damit Wirklichkeit geworden. Das Motto des Kongresses wurde aber nicht deshalb gewählt. Zu oft klafft eine grosse Lücke zwischen der von uns allen als ideal angesehenen Unterstützung durch ICT im Gesundheitswesen und der Realität. Vielfältige Gründe sind dafür verantwortlich, und nicht alle Probleme werden einfach lösbar sein. Nur ein globales Verständnis aller Beteiligten für die spezifischen Umsetzungsprobleme im Gesundheitswesen wird uns Schritte hin zu bestmöglichen Lösungen anbieten. Das Ziel des Kongresses ist es, dieses Verständnis zu fördern, pragmatische Lösungsansätze ebenso zu zeigen wie theoretische Modelle eines Idealprozesses. Und über allem steht die Analyse der Nutzung und der Auswirkungen unserer Systeme durch und für die Pflegenden, Ärzte und alle anderen Berufstätigen des Gesundheitswesens, nicht zu vergessen die Patienten: Wenn wir diese Verwendungen und deren Impact verstehen, diese auch günstig ausfallen, und wir die richtigen Schlüsse daraus ziehen, werden wir weitere Verbesserungen erzielen können und damit dem Wunsch nach Wirklichkeit näher kommen können. In diesem Sinne: lehrreiche und spannende Kongresstage! Cordiale bienvenue aux 24 es journées scientifiques annuelles de la Société Suisse d Informatique M édicale SSIM! Emmenés par le thème «Espoirs et réalités», en plus de deux journées de présentations axées sur la diversité et de nombreux posters passionnants, nous vous proposons les Actes de notre conférence. Le souhait de vous présenter les multiples facettes de réalisations concrètes d implémentation d outils informatiques dans la santé est ainsi réalisé. Le thème de la conférence n a cependant pas été choisi uniquement dans ce but. Trop souvent, nous sommes confrontés à un véritable fossé entre notre vision de ce que les technologies de l information peuvent apporter à la santé, et la réalité de leur traduction dans le quotidien. Il y a de nombreuses raisons qui peuvent expliquer ces écarts, et il ne fait pas de doute que tous les problèmes ne seront pas résolus de manière simple. Seule une compréhension globale et partagée de tous les acteurs sur la complexité bien spécifique du déploiement de ces outils dans la santé pourra progressivement permettre le développement de solutions et de réponses appropriées. Le but du congrès est donc de soutenir cette compréhension commune, en présentant des solutions concrètes mais également des modèles théoriques de processus idéaux. Au-delà de ces considérations, l analyse de l usage et de l impact de ces systèmes par et pour les utilisateurs, médecins, infirmières, toutes les professions de la santé, sans oublier les patients est primordiale: Si l usage est bien compris et les réponses appropriées trouvées, si les impacts sont positifs et mesurables, alors ces systèmes continueront d améliorer les processus et nous nous rapprocherons de notre souhait de les voir fonctionner réellement. C est dans cet état d esprit que nous vous souhaitons une conférence passionnante et enrichissante. 2

Technological choices for mobile clinical applications Frederic Ehrler, David Issom, Christian Lovis University Hospitals of Geneva, Division of Medical Information Sciences, Geneva, Switzerland Summary The rise of cheaper and more powerful mobile devices makes them a new and attractive platform for clinical applications. The interaction paradigm and portability of the device facilitates bedside human-machine inter actions. The greater accessibility to information and decision support anywhere in the hospital improves the efficiency and the safety of care processes. In this study we attempt to ascertain what are the most appropriate Operating System (OS) and Software Development Kit (SDK) to support the development of clinical applications on mobile devices. The Android platform is a Linux-based, open source platform that has many advantages. Two main SDKs are available on this platform: the native Android and the Adobe Flex SDK. Both have interesting features, but the latter has been preferred due its portability at comparable performance and ease of development. Introduction Equipping care providers with collaborative mobile tools, allowing to interact easily in real time with the hospital s information system is an important challenge. It is a critical element in improving the efficiency and the safety of care processes [1]. Until recently these interactions have been limited by devices and interaction models [2]. The new mobile devices represent an important step towards a solution. The development of clinical applications on these devices is not a customary problem of moving an application to a new operating system for two reasons: the pervasive presence of these devices and the disruptive new interaction paradigm introduced by multi-touch screens. Providing physicians with mobile services requires wise technological choices regarding the platform and the development environment [3]. In the following sections we first introduce the context in which we started our development research. Then we present the selection criteria employed to evaluate the candidate technologies. After that we describe the application we developed to assess the functionality of the candidate SDKs. Finally, we present the advantages and drawbacks of the OSs and SDKs we assessed for No conflict of interest relevant to this article was reported. our development, and the technology we ultimately chose to adopt. Background The Geneva University Hospitals (HUG) is a consortium federating the public hospitals in the Canton of Geneva, Switzerland. It provides primary, secondary, tertiary and outpatient care for the whole region with 45 000 inpatients and 850 000 outpatient visits a year [4]. The HUG s Clinical Information System (CIS) is largely an inhouse-developed system. It is a service-oriented and component-based architecture with a message-based middleware. It is written in Java with J2EE and open frameworks. All exchanges are in SOAP or HTTP/XML [5, 6]. All component building blocks of the CIS, including those discussed in this paper, are built in such a way that they comply as far as possible with standards, such as IHE (Integrating the Healthcare Enterprise) profiles, so that they are not dependent on any local legacy system. This includes technical, semantic and human-machine interfaces, such as using a terminology server for the language of the interfaces. Method To define the most appropriate technology to develop mobile clinical applications, we defined several criteria organised along three axes: Hardware: market trends, cost, performance and user acceptance of the mobile devices. Strength of the mobile platform with regard to security, reliability and privacy. Human: availability of competent developers on the labour market and existence of a developer community. Software: complexity of the development environment, cost, user-friendliness and reusability of existing and new developments. It is important to take into account the price of the physical devices supporting the OS, for when each care provider of the hospital is equipped with a mobile device, a small difference on price becomes really significant. The performance, including power autonomy of the device, is Correspondence: Frederic Ehrler University Hospitals of Geneva Division of Medical Information Sciences Rue Gabrielle-Perret-Gentil 4 CH-1211 Geneva 14 frederic.ehrler@hcuge.ch 3

Figure 1 Communication between mobile applications and existing CIS. obviously central, since a favourable course of the healing process often relies on real-time access to the relevant information. The information must obviously remain secured since it concerns the private life of the patient. In addition, we have to consider how quickly developers can master the environment and how easily the work already done inside the CIS can be adapted to the new tools. The choice of widely-used languages, such as ActionScript or Java, would definitely facilitate adoption and development since numerous developers are already familiar with these languages. The existence of a professional development environment, the existence of open source projects in this field, and an adequate developer community which has already addressed the most obvious questions, also facilitate development. To evaluate the features and the ease of development with the different SDKs, we defined a prototype mobile application, a sort of test use case, aiming to simplify the care process. With the help of this application, health professionals simply enter the information concerning the patient during the visit instead of recording all the information on laptops. The application is composed of a succession of screens where the user selects the unit, the room, and finally the patient currently examined. On the last screen the care provider can enter the vital signs of the selected patient. Communication architecture Regarding the architecture, it was mandatory to devise a model that would not create a dependency with any legacy system. Thus, we defined a gateway server providing centralised access for the mobile application to any required information to or from the CIS. Thus, integrating any mobile application would only mean integrating this bridge. It also clearly separates the services that are available remotely from the ones proposed as usual Web services. The gateway server is responsible for formatting the data properly before sending it to the appropriate application on the device. Once the mobile device Table 1 Comparison of the principal existing OSs to be developed on mobile devices (market shares of Western Europe, November 2010). OS ios Symbian Android RIM Developer Apple Nokia Google Blackberry Language Objective-C C++ Java + XML Java Market shares 46.4% 21.77% 15.65% 10.16% receives the data its embedded software is responsible for displaying the data through its interface and allows interaction with the user. Figure 1 shows the link between our mobile application and the current CIS. The services of the existing CIS are externalised through a component named CIS gateway. When a mobile application requires data from the CIS it communicates with the mobile gateway that transmits the request to the CIS gateway. The service directory is then queried to identify the appropriate service from which to retrieve the required information. The information then returns through the same channel. All data transiting through the channel is formatted in XML. Results Choice of the OS The choice of OS is a challenge. There are numerous OSs for mobile devices on the market, some of them with marginal shares. To simplify the work it was decided to address only the four that are currently seen as major players, as per the table 1. The Apple iphone is an interesting product since it is widespread among users [7]. Unfortunately, the development policy of Apple is very restrictive. In addition, the development environment is unique to the OS, thus requiring very specific and dedicated skills and education for the development team. Finally, there is a very limited choice of devices, as only the devices provided by Apple are available on the market. Choosing between Android, Symbian and RIM was trickier. They all possess a significant share on the market, rely on well established language and possess an effi - cient development environment. However, only Android offers a huge choice of devices, ranging from a very small Smartphone to large tablets, a widespread development environment, a large open source community, and a very transparent development policy. Choice of the SDK One would think it is straightforward to adopt the Android SDK to develop on the Android platform. However, it is worth taking into consideration Adobe, a major actor of the IT world that offers development tools for mobile devices running Android. Adobe provides an SDK named Adobe Flex that has the worthwhile advantage of generating programs that can be supported by several platforms unchanged. We rapidly surveyed (table 2) Adobe Flex and Android SDK characteristics to clarify their benefits and limitations. Some restrictions related to the Flex Hero SDK have been identified. As this SDK is an additional layer over the native SDK, there can be a loss of functionalities. Fortunately the Flex SDK can handle the main functions required to interact with the mobile device, such as positioning, multi-touch, inclination, etc. The only limitation identified is the impossibility of creating Android widgets, but this is not required for our application. The additional layer of the Flex SDK can also cause a reduction of performance. However, in our tests 4

Table 2 Comparison of principal existing SDKs to develop on Android platform. Features Flex Hero SDK Android SDK Version Flex 4.5 Hero Froyo 2.2 IDE Flex Builder Burrito Eclipse Language ActionScript 3 + MXML Java + XML Execution platform Adobe-Compatible Android Adobe to program mobile applications. This IDE based on Eclipse offers programming facility to code in ActionScript and MXML. As with the Android SDK, there is an emulator that significantly facilitates the development. Comparing Platforms To improve our comparison we developed our sample application on the two platforms. In the figure 2 it can be seen that there are no marked differences in the humanmachine interaction experience between the two interfaces. Both can display and manipulate lists, radio buttons and text inputs and other graphic component. Conclusion Our constraints, needs and projects led us to prefer the Android OS due its compatibility with the largest number of devices and its open source policy. The selection of the SDK was more difficult as both the Android SDK and the Flex SDK met most needs in terms of features for the development of a mobile application on Android OS. The Flex SDK was finally chosen on the basis of its portability to other platforms at comparable performance and ease of development. Figure 2 Android SDK and Adobe Flex screens to enter vital signs of the patient. we did not observe and did not find objective and serious studies confirming or invalidating this fact. Regarding the Integrated Development Environment (IDE), the two languages possess a dedicated tool that helps developers generate accurate code. For Android SDK Eclipse IDE is perfectly adapted as the code is standard Java language. With the addition of a plug-in, the Eclipse IDE can manage the installed SDK, the documentation, and some drivers to connect the mobile device to the computer. The plug-in offers automated compilation as well an emulator. It allows testing of the application locally instead of loading it into the mobile device. For the Flex SDK, a new version of their development environment, Flex Builder, has been released recently by References 1 Prgomet M, Georgiou A, Westbrook JI. The Impact of Mobile Handheld Technology on Hospital Physicians Work Practices and Patient Care: A Systematic Review. JAMIA. 2009;16:792 801. 2 Kubben P. Neurosurgical apps for iphone, ipod Touch, ipad and Android. Surg Neurol Int. 2010;22:89. 3 Fischer S, et al. Handheld Computing in Medicine. JAMIA. 2003:139 49. 4 Tschopp M, et al. Computer-based physician order entry: im plementation of clinical pathways. Studies in health technology and informatics. 2009:673 7. 5 Borst F, et al. Happy birthday DIOGENE: a hospital information system born 20 years ago. International Journal of Medical Informatics. 1999;54:157 67. 6 Geissbuhler A, et al. Experience with an XML/HTTP-based federative approach to develop a hospital-wide clinical information system. Stud Health Technol Inform. 2001;84:735 9. 7 Payne D, Godlee F. The BMJ is on the ipad. BMJ. 2011;19. 5

Ökonomische Auswirkungen der spitalweiten Einführung des digitalen Diktierens am UniversitätsSpital Zürich Ninoslav Teodorovic, Mechthild Uesbeck, Roland Naef Direktion ICT, UniversitätsSpital Zürich Summary From an economic perspective, the introduction of DRG necessitates that processes be optimised wherever possible with the help of information technology, whilst maintaining the required high levels of quality. The creation of reports, including dictation onto tape, lends itself to this purpose in the USZ. The aim of the project was to perform a cost-benefit analysis of using digital dictaphones instead of the existing analogue ones. The following underlying assumptions were made: The analogue dictaphones would be completely replaced by a modern system for digital dictation. The current processes associated with the analogue dictaphones would be encompassed and optimised in the new system. The digital dictation would be integrated into the USZ electronic patient record systems. A survey was undertaken in the 42 clinics of the USZ in order to assess the current situation. Based on the results, an analysis and an investigation of all processes concerned and USZ information systems were performed. In addition, supplier companies in German speaking regions of Switzerland and Germany were analysed and reference visits were undertaken. The target process for the creation of reports and digital dictation was defined in a pilot project together with three USZ clinics. The current and target processes were analysed and evaluated. The investment costs were treated as fixed asset investments. The cost-benefit analysis consisted of three main criteria, which were further subdivided. The investment calculations and cost-benefit analysis predict a yearly saving in personnel costs of approximately one million Swiss Francs. In addition, non-financial benefits, such as data security and improved dictation quality, can also be taken into account. The results of this study relate to the USZ, but due to its general nature they can also be applied to other hospitals. Die Autoren haben keine Interessenkonflikte im Zusammenhang mit diesem Beitrag deklariert. The introduction of digital dictaphones can have a very positive economic impact. In the case of the USZ a saving of 10% of the previously needed secretarial staff. It should be noted that the benefits and cost savings are not solely achieved by the introduction of a digital dictation solution, but also the optimisation of the report creation process plays an important role. Einleitung Der inhaltliche Schwerpunkt der vorliegenden Studie liegt auf der Erstellung einer Investitionsberechnung und der zugehörigen Nutzwertanalyse, welche die wirtschaftlichen Auswirkungen der Optimierung des Berichterstellungsprozesses am UniversitätsSpital Zürich (USZ) durch die Einführung des digitalen Diktierens dem bisherigen, analogen Diktieren gegenüberstellt. Dazu wurde eine Analyse des Ist-Zustands hinsichtlich der Berichterstellung in den 42 Kliniken des USZ durchgeführt, es wurden die diesbezüglich vorhandenen Prozesse und Informationssysteme des USZ untersucht und die auf dem Markt vorhandenen Anbieter im Bereich digitales Diktieren überprüft. Schliesslich wurde im Rahmen eines Pilotprojekts in drei USZ-Kliniken ein Konzept für das System des digitalen Diktierens erarbeitet und der neue, optimierte Prozess für die Berichterstellung festgelegt. Für die Erstellung der Studie wurde auf Daten zurückgegriffen, die zwischen Mai 2008 und Dezember 2009 erhoben worden waren. Diese betrafen z.b. die Anzahl Diktierer je Klinik, die Anzahl Schreibkräfte, die Anzahl diktierter Berichte, die Grösse der Klinik etc. Zu der aufwendigen Datenerhebung kam erschwerend hinzu, dass sich das USZ seit Anfang 2009 bis heute, also während der gesamten Projektdurchführung, in einem Prozess der Reorganisation befindet. Dabei wurden auch die Führungsstrukturen des riesigen Tankers USZ sowie alle geschäftsrelevanten Prozesse optimiert und verbessert. Die Erarbeitung neuer Prozesse hinsichtlich der Berichterstellung musste hier natürlich in Einklang mit der USZ-weiten Reorganisation erfolgen. Korrespondenz: Ninoslav Teodorovic UniversitätsSpital Zürich Direktion ICT CH-8091 Zürich Ninoslav.Teodorovic@usz.ch 6

Es lässt sich belegen, dass durch die Einführung des digitalen Diktierens und eine Anpassung der zugehörigen Arbeitsabläufe das USZ auch in DRG-Gewässern steuerbar, leistungsfähig und gewinnbringend agieren kann. Zielsetzungen Im Rahmen der Arbeit wird ein Konzept zur Einführung eines Systems für das digitale Diktieren (SDD) am USZ erarbeitet. Der inhaltliche Schwerpunkt liegt auf der Erstellung einer Investitionsberechnung und der zugehörigen Nutzwertanalyse, die die wirtschaftlichen Auswirkungen des digitalen Diktierens dem bisherigen, analogen Diktieren am USZ gegenüberstellt. Die Arbeit hat dabei folgende Zielsetzungen: 1. Ablösung der analogen Diktiergeräte durch ein modernes System für das digitale Diktieren. 2. Jetzige, mit dem analogen Diktieren verbundene Abläufe sollen im neuen System abgebildet und optimiert werden. 3. Die Integration des Systems für das digitale Diktieren in die elektronische Patientenakte des USZ. Ein Grossteil der für die Nutzwertanalyse benötigten Daten wurde im Laufe des Jahres 2009 durch eine Umsetzung dieser Zielsetzungen in drei ausgewählten Pilotkliniken gesammelt. Folgende Teilziele sind mit der Einführung eines SDD zu erreichen: 1. Optimierung des Workflows durch: a. Berichterstellung unmittelbar nach Diktatende. Dadurch schnellere Verfügbarkeit der fertiggestellten Berichte für alle an der Patientenbehandlung beteiligten Personen (Zuweiser, mitbehandelnde Kollegen) b. Wegfall des Transports von Bändchen. 2. Einführung eines möglichst papierlosen Betriebs durch: a. Abschaffen der Bändchen. b. Einsatz von Arbeitslisten, die unter anderem dafür sorgen, dass Korrekturen nicht mehr auf Papier vorgenommen werden müssen. 3. Einsparungen von Verbrauchsmaterial (Bändchen, Papier). 4. Qualitätssteigerung in der Berichtschreibung durch deutlichere Klangwiedergabe. 5. Erhöhen der Patientendatensicherheit durch a. Automatische Zuordnung eines gesprochenen Diktats zum richtigen Patienten b. Zugang zu Patientendaten nur für Berechtigte. 6. Die Voraussetzung schaffen für einen flächendeckenden Einsatz der Spracherkennung. 7. Die Grundlage schaffen für die Zentralisierung der Schreibpools. Abgrenzungen Der Kern dieser Arbeit behandelt das methodisch gestützte Erheben von Ist-Prozessen hinsichtlich der Berichterstellung im USZ, das Erarbeiten der zugehörigen Soll-Prozesse und die Erstellung einer entsprechenden Kostennutzenanalyse. Dabei wird grosser Wert auf die jetzige und zukünftige Personalauslastung gelegt. Es wird nicht auf die Erhebungsmethoden für den im Verlauf dieser Arbeit erarbeiteten Anforderungskatalog für SDD eingegangen. Methoden Zur Aufnahme des Ist-Zustands erfolgte eine Umfrage in den 42 Kliniken des USZ. Auf Basis der Umfrageergebnisse wurde eine Prozessanalyse durchgeführt. Die vorhandenen Informationssysteme am USZ wurden recherchiert und analysiert. Das Anbieterumfeld für digitales Diktieren im deutschsprachigen Raum wurde analysiert und Referenzbesuche wurden getätigt. In einem Pilotprojekt wurde mit drei Kliniken des USZ der Soll-Prozess für die Berichterstellung inkl. des digitalen Diktierens festgelegt. Ist- und Soll-Prozess wurden abgeglichen und ausgewertet. Die zu berechnende Investition wurde als eine Sachinvestition, genauer als eine Anlageinvestition betrachtet. Die Nutzwertanalyse bestand aus drei Hauptkriterien, die wiederum in Unterkriterien unterteilt waren. Resultate Die erarbeiteten Resultate werden nachfolgend in Reihenfolge der in Tabelle 1 aufgelisteten Vorgänge erläutert. Um die qualitative Investitionsberechnung sowie die Nutzwertanalyse erarbeiten zu können, war es notwendig, die Vorgänge sequentiell abzuarbeiten. Tabelle 1. Vorgehensweise bei der Durchführung der Arbeit. Vorgang Aufnahme des Ist-Zustands in den Kliniken Analyse der vorhandenen Informationssysteme Analyse des Anbieterumfelds Konzeption und Festlegen der Soll-Prozesse Wirtschaftlichkeitsberechnung Methoden Recherche, Umfrage in den Kliniken, Strukturierung der Umfrageresultate Recherche Recherche, Referenzbesuche Recherche, Vorprojekt, Auswertung Recherche, Auswertung Tabelle 2 Verhältnis analog zu digital diktierenden Kliniken in Bezug auf diktierte Berichte und Schreibkräfte. Kliniken mit analogem Diktieren und nicht optimierten Prozessen Kliniken 38 4 Berichte pro Monat 17000 12000 Prozentualer Anteil der Berichte 58,6% 41,4% Schreibkräfte in FTE 153 17 Prozentualer Anteil der Schreibkräfte 90% 10% Kliniken mit digitalem Diktieren und optimierten Prozessen 7

Ist-Zustand Die Diktate werden von 713 Personen, vorwiegend Medizinern, vorgenommen und durch 223 Schreibkräfte als Teil ihrer vielfältigen Aufgaben geschrieben. 713 Diktierende teilen sich 657 Stellen, die 223 Schreibkräfte sind oft Teilzeitangestellte und belegen insgesamt 170 Stellen. Tabelle 2 zeigt eine Zusammenfassung des beschriebenen Mengengerüsts. Der in Abbildung 1 dargestellte, modellhafte Berichterstellungsprozess stellt die Schnittmenge aller in der Umfrage ermittelten Prozesse dar. Im beschriebenen Prozess wird angenommen, dass der Bericht durch einen Mediziner erstellt wird und nicht durch einen Assistenten unter Kontrolle eines Oberarztes, wie dies in vielen Fällen vorkommt. Diese Vereinfachung des Prozesses wurde aus Übersichtlichkeitsgründen vorgenommen. Die gleiche Vereinfachung wird auch für den Soll-Prozess gemacht werden. USZ-Informationssysteme im Umfeld der Berichterstellung Die Recherche zeigte, dass die Systeme ifms PathoPro (das Institutssystem der Pathologie) und GE Centricity RIS (das Informationssystem der Institute für diagnostische Radiologie, für Neuroradiologie sowie der Klinik für Nuklearmedizin) als einzige Systeme am USZ bereits die für eine optimale Berichtsunterstützung erforderlichen Werkzeuge besitzen. Im PathoPro sowie im Centricity wird das digitale Diktieren bereits aktiv genutzt. Im GE Centricity ist sogar Spracherkennung möglich und wird von einigen Benutzern erfolgreich angewendet. Das USZ-weit eingesetzte Klinikinformationssystem KISIM verfügte bis anhin über keine Werkzeuge zur Unterstützung des Diktierprozesses. Anbieterumfeld Auf dem Markt existieren viele Anbieter für digitale Diktiersysteme und nur wenige Systemhersteller. Zu den Herstellern, deren Systeme im Gesundheitswesen im Einsatz sind, zählen: Nuance Communications Inc. Healthcare Germany MediaInterface Dresden GmbH WinScribe Inc. 4voice AG Um die Konzeption für das SDD am USZ sowie die Anforderungen der verschiedenen Stakeholder zu definieren, war es notwendig, eine Teststellung des SDD vorzunehmen. Diese sollte mit drei verschiedenen Kliniken durchgeführt werden. Da die Teststellung und die Konzeption im Rahmen eines Vorprojekts gemacht werden mussten, existierten zu diesem Zeitpunkt noch keine klar definierten und vollständigen Anforderungen an das SDD, sondern die Wahl des Anbieters für das Vorprojekt erfolgte aufgrund der Ergebnisse der bereits vorher durchgeführten Referenzbesuche. Zur Wahl standen Nuance und MediaInterface, u.a., da beide Anbieter bereits im Jahr 2009 in der Schweiz grössere Projekte erfolgreich durchgeführt hatten. Bei der Auswahl wurde ausserdem darauf geachtet, welcher der Anbieter einen professionellen und ausgeprägten kundenorientierten Eindruck hinterlassen hatte. Den Ausschlag für die Wahl der MediaInterface gaben neben den oben erwähnten Faktoren auch die Reaktionszeit auf Kundenbedürfnisse sowie die Möglichkeit, direkt mit den Systementwicklern kommunizieren zu können. Konzeption Zunächst wurden folgende Stakeholder inklusive ihrer Rollen und Hauptaufgaben ermittelt. Tabelle 3 Stakeholder für das digitale Diktieren, ihre Rollen und Aufgaben. Stakeholder Rolle Aufgaben Mediziner Anwender Berichte diktieren, Berichte korrigieren, Berichte signieren Schreibkraft Anwender Berichte schreiben, Berichte archivieren bzw. versenden Klinikmanager Prozessverant - wortlicher Prozess mitgestalten, Prozess freigeben ICT Betrieb Hardwareverwaltung und -support, App. Verwaltung und Support, Projektmanagement, Integration Klinische Bereichsleitung Technischer Dienst Controlling Keine Qualität überwachen, Produktivität überwachen Verwaltung der analogen Diktiergeräte entfällt Die aufgrund von Interviews mit den Stakeholdern des USZ ermittelten Anforderungen an das zukünftige Diktiersystem beziehen sich auf folgende Themen: 1. Allgemeines 2. Standards 3. Datenschutz und Sicherheit 4. Verfügbarkeit 5. Schnittstellen 6. Performance 7. Wirtschaftlichkeit 8. Funktionalität 9. Benutzerfreundlichkeit 10. Handhabbarkeit 11. Herstellerkompetenz 12. Dokumentation Aus den erhaltenen Umfrageergebnissen und den ermittelten technischen Gegebenheiten und Möglichkeiten ergab sich schliesslich die in Abbildung 3 dargestellte mögliche Gesamtstruktur des SDD inklusive seiner Anbindung an das Klinikinformationssystem KISIM. Die Graphik bildet nur die allgemeinen und für den Benutzer wahrnehmbaren Geschäftsprozesse ab. An das SDD können dank der Skalierbarkeit des Systems beliebig viele Kliniken angeschlossen werden. Die in Abbildung 3 dargestellten PCs sind die bereits am USZ eingesetzten Standard-Arbeitsplätze, die mit den neuen Funktionen, sprich der Diktiersoftware, ausgestattet werden. 8

Nachfolgende Abbildung 2 zeigt Ist- und Soll-Prozess im Vergleich. In Abbildung 2 ist zu beachten, dass die Arbeitsschritte, die im Soll-Zustand auf der Ebene von «Block B» dargestellt sind, beim Ist-Prozess auf der Ebene von «Block A» dargestellt sind. Der Grund ist, dass bei der Optimierung des Prozesses die besagten Arbeitsschritte nach unten verschoben wurden, u.a., um die fortbestehende Prozessschwäche zu verdeutlichen, die in der weiterhin erforderlichen handschriftlichen Signatur der Papierausdrucke besteht. Der neue Prozess wurde zu Beginn des Vorprojekts festgelegt und während des Vorprojektverlaufs angepasst und bestätigt. Um den neu festgelegten Prozess realistisch testen und bestätigen zu können, war es notwendig, eine einfache Integration des im Vorprojekt verwendeten MediaInterface SDD ins KISIM zu realisieren. Dank der sehr guten Zusammenarbeit der KISIM-Entwickler und des USZ konnte die Integration erfolgreich bewerkstelligt werden. Abbildung 1 Berichterstellungsprozess USZ: Ist- Zustand. Abbildung 2 Ist- und Soll-Zustand des Berichterstellungsprozesses im Vergleich. 9

Abbildung 3 Geplanter Systemaufbau und Integration in die Systemumgebung. Investitionsrechnung und Nutzwertanalyse Abbildung 4 präsentiert die Ergebnisse des Vorprojekts. Es ist ersichtlich, dass sich der Aufwand bei den Diktierenden sowie den Schreibkräften jeweils um ca. 30% reduziert hat. Vergleiche zwischen den drei Kliniken ergaben sehr ähnliche Resultate, was für eine korrekte Ermittlung der Aufwände spricht. Da der Soll-Prozess grösstenteils im digitalen Umfeld stattfindet, ist es in diesem Fall möglich, die meisten Zeiten mittels Datenbankabfragen zu ermitteln. Die Datenbankabfragen dienen hier aber nur zur Kontrolle der im Rahmen von Gesprächen über eine zukünftig mögliche Arbeitsweise ermittelten Werte. Für die Datenerhebung war der persönliche Kontakt mit den befragten Mitarbeitern der drei Kliniken und die Wertschätzung ihrer bisherigen Aufgaben von sehr grosser Bedeutung und trug sicherlich ebenfalls zur guten Qualität der erhobenen Daten bei. Im Weiteren werden die ermittelten Aufwandszahlen genauer betrachtet und die tatsächliche Reduktion des Aufwands für Schreibkräfte und Diktierer vom Ist- zum Soll- Prozess überprüft. Abbildung 4 enthält die entsprechenden Berechnungen für alle drei Testkliniken. Rechnet man die Resultate aus den Testkliniken auf die restlichen 38 Kliniken hoch, so könnten nach der USZweiten Einführung des SDD und des Umsetzens der neuen Prozesse 10,3% der insgesamt im USZ beschäftigten Schreibkräfte eingespart bzw. anderweitig eingesetzt werden. Laut der obigen Berechnung könnte darüber hinaus die Arbeitszeit von 0,88% der am Berichterstellungsprozess beteiligten Mediziner eingespart werden. Da die Mediziner am USZ im Durchschnitt 110% arbeiten und die Situation bezüglich geleisteter Überstunden prekär ist, sollten in diesem Bereich jedoch keine Kürzungen vorgenommen werden. Das SDD soll helfen, die Aufwände der Mediziner zu verringern und die anfallenden Überstunden zu reduzieren. Die durchgeführte Investitionsberechnung prognostiziert im Bereich der personellen Ressourcen ein jährliches Einsparpotenzial von ~1 000 000 CHF (das entspricht 10% der gesamten Jahreslohnsumme für Sekretariatsdienstleistungen). Zusätzlich kann laut der Nutzwertanalyse mit einer positiven Auswirkung auch auf nichtmonetäre Faktoren wie Datensicherheit und Qualität des Diktats gerechnet werden. Die erarbeiteten Resultate beziehen sich auf das USZ, sind aber aufgrund der allgemeingültigen Vorgehensweise bei deren Ermittlung auch auf andere Spitäler übertragbar. Abbildung 4 Aufwandberechnung für die Berichterstellung in allen drei Testkliniken. 10

Diskussion Durch die Einführung des digitalen Diktierens in einem Spital kann mit sehr positiven ökonomischen Auswirkungen gerechnet werden. Im Fall des USZ bestehen diese in Einsparungen von 10% der bisher benötigten Schreibkräfte. Seit Abschluss des Projekts und zum Zeitpunkt der Veröffentlichung dieser Arbeit konnte der Rollout des erarbeiteten SDD auf weitere 37 Kliniken bereits ausgedehnt und die oben erwähnten möglichen Budgetkürzungen im Bereich Personal bereits umgesetzt werden. Dabei ist zu beachten, dass die erreichten Ziele sowie sich daraus ergebende Einsparungen nicht nur durch alleiniges Einführen einer Plattform für digitales Diktieren erfolgen. Die Optimierung der Prozesse rund um die Berichterstellung spielt hier ebenfalls eine zentrale Rolle. Zu erwähnen ist noch, dass die errechneten Einsparungen nur bei Vorhandensein einer krankenhausweiten elektronischen Patientenakte erreicht werden können. D.h., es wird vorausgesetzt, dass ein Krankenhaus, das über die Einführung eines Systems zum digitalen Diktieren nachdenkt, bereits über ein flächendeckend eingesetztes KIS verfügt. Die Einführung des SDD am USZ bringt folgende positive Effekte mit sich: 1. Während der fünfjährigen Nutzdauer werden 4 Millionen CHF in Barwert an festen Kosten eingespart (die Kosten für den zusätzlichen Aufwand in der IT sind bereits eingerechnet). 2. Die Einführung des digitalen Diktierens ist eine der Verbesserungen, die dem USZ den erfolgreichen Einstieg in die Abrechnung nach DRG ermöglichen werden. 3. Neben diesen Einsparungen ist ausserdem mit einer Zunahme der Berichtsqualität, einer Steigerung der Produktivität und somit einer erhöhten Zufriedenheit der Mitarbeiter, Zuweiser und Patienten zu rechnen. Literatur 1 Hoffmeister W. Investitionsrechnung und Nutzwertanalyse. Berlin: Berliner Wissenschafts-Verlag; 2007. 2 Lehmann TM. Handbuch der medizinischen Informatik. München: Hanser; 2005. 3 UniversitätsSpital Zürich: Zahlen und Fakten. Available from: http:// www.usz.ch/ueberuns/zahlen_und_fakten/seiten/default.aspx [updated 05/2010] 4 Viitanen J. Redesigning digital dictation for physicians: A user-centered approach. Health Informatics Journal. 2009;15(3):179 90. 5 McEnery KW, Suitor CT, Hildebrand S, Downs R. RadStation: Client- Based digital dictation system and integrated clinical information, display with an embedded Web-Browser. Proc AMIA Symp. 2000;561 4. 6 Leiner F. Medizinische Dokumentation. Stuttgart: Schattauer; 2006. 7 A large general practice. Informatics in Primary Care. 2003;11:157 65. 8 Thumann P, Topf S, Feser A, Erfurt C, Schuler G, Mahler V. Digitale Spracherkennung in der Dermatologie. Hautarzt. 2008;159:131 4. 9 Thurnheer R. Investitionsmanagement Vorlesungsunterlagen ZHAW (MAS in Managed Health Care). 2008. 10 Ulich E. Arbeitspsychologie. Zürich: vdf Hochschulverlag AG; 2005. 11

Evaluation und Parametrierung eines Patientendatenmanagementsystems: Erfahrungsbericht aus einer Anästhesieabteilung Kay Stricker a, Patrick Wettstein a, Martin Felder b, Matthias Kämpf c a Universitätsklinik für Anästhesie und Schmerztherapie, Inselspital, Bern b Department Intensivmedizin, Notfallmedizin, Anästhesie, Inselspital, Bern c Direktion Dienste, Leiter IT Architektur und Dienste, Inselspital, Bern Summary The electronic recording and handling of clinical data of patients, devices and performance has undergone extensive development in the past few years. There is an increasing need for valid data by insurance companies, quality managers and medical associations. Therefore hospitals and clinics are under pressure to join this trend. The evaluation and introduction of an electronic health record under limited resources creates the risk of choosing an inadequate system. We report on our own experience with the introduction of an anaesthesia information management system in a Swiss university clinic, with emphasis on team aspects, goals, evaluation process and key aspects. Hintergrund Die Mängel manuell dokumentierter Anästhesieprotokolle wurde schon vor 20 Jahren erkannt [1], und erste elektronische Patientendatenmanagementsysteme (PDMS) wurden entwickelt. Bald wurden die Vorteile automatischer gegenüber manueller Datenerfassung erkannt [2, 3]. Trotzdem haben Kliniker [4, 7] und Administratoren [8] teilweise noch Vorbehalte gegenüber solchen Systemen, z.b. in Hinblick auf Kunstfehlerprozesse, Ablenkung, Investitionsvolumen sowie Aufwand für Evaluation und Implementierung [9, 10]. Dennoch kompensieren die Vorteile viele der Einwände und in den vergangenen Jahren sind wegen zunehmender Leistungsfähigkeit verschiedene Arten von elektronischen Krankengeschichten (EHR = elec tronic health records) erfolgreich in unterschiedliche Abteilungen der klinischen und ambulanten Medizin eingeführt worden [9]. Diese EHR können Patientenprozesse über mehrere Spitalabteilungen hinweg unterstützen oder wurden für Die Autoren erklären, dass sie neben der klinischen Arbeit keine Beziehungen zu einem Anbieter unterhalten und dass kein Konflikt zugunsten oder gegen einen Anbieter besteht. einzelne Kliniken und Anwendungsgebiete speziell entwickelt, z.b. für Intensivmedizin oder Anästhesie (AIMS = anaesthesia information management system). Im Rahmen des «Health Information Technology for Economic and Clini- cal Health (HITECH) Act» zur Förderung von Entwicklung und Einführung elektronischer Krankengeschichten wurden in den USA kürzlich 27 Milliarden Dollar bewilligt [11]. Durch solche finanziellen Anreize und zunehmenden Druck von Herstellern und Spitaladministratoren wurde EHR zu einem Trendthema. Bei der PubMed-Suche unter dem MESH-Heading «electronic health record» wurden im Mai 2011 über 1400 wissenschaftliche Artikel angezeigt. Wegen dem Hype dieses Themas besteht durch Zeitdruck oder unausgereifte Systeme das Risiko, dass das Potential eines EHR ungenügend genutzt wird oder dass es Nachteile für Gesundheit und Privatsphäre der Patienten birgt [12]. In diesem Fallbericht beschreiben wir einige Stärken und Schwachpunkte der Evaluation und Implementierung eines AIMS an unserer Klinik und beziehen uns dabei besonders auf das Team, die Ziele, den Evaluationsprozess und die wichtigsten Erkenntnisse. Vorgehen Die Initiative zur Evaluation eines AIMS kam vor fünf Jahren von unserer Klinikleitung. Ziel war die Einführung eines Systems zur Dokumentation und Datenverarbeitung im klinischen Alltag. Bei der Arbeitsgruppe waren ärztliche und pflegerische Kliniker, der Departementsinformatiker, Materialverantwortliche sowie ein leitender Arzt vertreten. Ein Kliniker hatte auf der Intensivstation mit einem PDMS gearbeitet, die anderen Gruppenmitglieder hatten keine Erfahrungen mit PDMS. Die Beschaffung des AIMS wurde im Rahmen einer öffentlichen Submission im Herbst 2009 ausgeschrieben und fünf Firmen haben sich für das Projekt beworben. Erwartungsgemäss bietet der Prozess der Einführung eines AIMS Chancen und Risiken mit positiven wie negati- Korrespondenz: Dr. med. Kay Stricker Universitätsklinik für Anästhesie und Schmerztherapie Inselspital CH-3010 Bern kay.stricker@insel.ch 12

ven Überraschungen. Zur Vorbereitung waren die Besuche von Kliniken mit installierten AIMS sowie der MEDICA äusserst wertvoll. Die Systemadministratoren der besuchten Kliniken waren ausnahmslos bereits, ihre AIMS zu präsentieren und über Vor- und Nachteile zu reden. Obwohl die Rückmeldungen der Benutzer überwiegend positiv waren, lohnte es sich, neben den jeweiligen Administratoren auch die Meinungen der klinischen Anwender (Pflegepersonal, Ärzte) zu hören. Dabei sind deutliche Unterschiede zwischen den Beurteilungen von Administratoren und Benutzern aufgefallen. Die erfolgreiche Einführung eines AIMS hängt wesentlich von der Akzeptanz durch die Benutzer ab, und in einer Klinik wurde von einer erhöhten Personalfluktuation in Zusammenhang mit der Einführung des PDMS berichtet. Positive Aspekte Der grösste Nutzen der Evaluation eines AIMS besteht in der grundlegenden Hinterfragung von eingeschliffenen Prozessen in der Klinik und bei der Leistungserfassung. Vor allem langjährige Mitarbeiter sind mitunter betriebsblind in Bezug auf ineffiziente Prozesse, was zu Mehraufwand oder finanziellen Mindereinnahmen führen kann. Das Evaluationsteam Das Projektteam bestand aus langjährigen klinischen und IT-Mitarbeitern, die das Umfeld der Spital- und Departementsinformatik sowie die klinischen Prozesse sehr gut kannten. Es haben alle involvierten Abteilungen das Projekt proaktiv unterstützt, was die Zusammenarbeit auch über die Klinikgrenzen hinweg erleichterte. Trotz eines motivierten In-House-Teams wurde aufgrund mangelnder Personalressourcen das Teilprojekt «Evaluation und Verträge» an ein Beratungsbüro mit Erfahrung im medizinischen Umfeld vergeben. Dieses Outsourcing erwies sich als vorteilhaft: ein externer Mitarbeiter ist nicht betriebsblind, kann Vergleiche mit Projekten und Abläufen in anderen Kliniken ziehen und er entlastet das Projektteam, indem er die Kommunikation mit Anbieterfirmen koordiniert und kanalisiert. Zudem können Abklärungen bei Anbietern auch während der Ausschreibungsphase anonymisiert erfolgen, wenn ein direkter Kontakt zwischen Spital und Anbieter unzulässig ist. Keiner der klinischen Mitarbeiter war ein ausgesprochener Informatikliebhaber. Dadurch wurden pragmatische Lösungen angestrebt und das Team hat sich nicht in Detaillösungen verstiegen. Vorgaben der Evaluation Das Projekt beschränkte sich auf die Evaluation einer Applikation für die Universitätsklinik für Anästhesie und Schmerztherapie. Zum Zeitpunkt der Ausschreibung waren in unserem Spital mehrere andere Applikationen in Betrieb oder deren Planung weit fortgeschritten. Dadurch war die Abgrenzung gegenüber dem Klinikinformationssystem (KIS), dem OP-Managementsystem und anderen Applikationen vorgegeben und die Anforderungen an die verschiedenen Applikationen wurden gegenseitig respektiert. Evaluationsprozess Eine Eigenentwicklung für ein AIMS wurde a priori ausgeschlossen. Es kam ausschliesslich eine Applikation in Frage, welche das Pflichtenheft aufgrund bestehender Entwicklungen bereits mit entsprechenden Referenzen erfüllt. Bei der Beurteilung wurden Produktepipelines und «Versprechungen» der Anbieter nicht berücksichtigt, sondern nur vorhandene Funktionalitäten bewertet. Als Basis für die Ausschreibungsunterlagen wurden An wen dungsfälle beschrieben, in denen die klinischen Anforderungen für das Pflichtenheft definiert wurden. Die Ausschreibung und Evaluation erfolgte nach Spitalstandard, wodurch die Evaluation schlank und das Risiko eines Rekurses durch unterlegene Anbieter klein war. Die Hauptkriterien und deren Gewichtungen bei der Bewertung waren: 1. Funktionalität, Schnittstellen, Technologie, Sicherheit, Entwicklungspotential (20%) 2. Implementierung, Schulungsaufwand, Betrieb, Support und Wartung, Synergien, Kundendienst (10%) 3. Wirtschaftlichkeit (Lebenszykluskosten über 8 Jahre) (25%) 4. Lösungspräsentation, Bedienungsfreundlichkeit, Ergonomie (30%) 5. Datenauswertung, Reporting (15%) Jedes dieser Kriterien wurde in mehrere Teilaspekte untergliedert. Die einzelnen Bewertungen wurden zum Vergleich der verschiedenen Anbieter in Tabellen dargestellt und zur späteren Nachvollziehbarkeit wurde jede Bewertung kommentiert. Aufgrund dieses Vorgehens war der Entscheid für uns eindeutig und trotz Rücksprachen von zwei Anbietern kam es zu keinem Rekurs. Negative Aspekte Retrospektiv erwies es sich als besonders negativ, dass die Personalressourcen zu knapp bemessen waren, wodurch sich das Projekt verzögerte. Durch Verzögerungen entsteht per se ein Mehraufwand, da das Personal auch in Partnerteams ändert, Partnerapplikationen sich ändern, neue Wünsche und Ziele ins Projekt einfliessen oder andere Faktoren zum Tragen kommen. Tatsächlich hat sich der Anforderungskatalog im Verlauf des Projekts durch Wünsche der Forschungsgruppe, Leistungserfassung und Planung erweitert. In einer Zeit, in der klinisches Personal aus Kostengründen abgebaut wird, ist es für Personalverantwortliche wenig einsichtlich, warum zusätzlich Kliniker für die Evaluation eines IT-Projektes freigestellt werden müssen, insbesondere, wenn die Personalplaner selber keine Erfahrung mit EHR haben. Bei den Anträgen für Personalressourcen musste deshalb betont werden, dass ein AIMS primär ein System für den klinischen Alltag ist und nicht für den Informatiker. Zudem haben wir den eigenen Personalbedarf aus verschiedenen Gründen unterschätzt und zwar v.a. betreffend Parametrierung und Testung: Alle Anbieter haben uns angeboten, Parametrierungen anderer Kliniken zu übernehmen. Tatsächlich ist die Übernahme von Parame- 13

trierungen oder Funktionalitäten aus anderen Spitälern jedoch nur ausnahmsweise möglich, da das Umfeld eines spezifischen AIMS (Partnerapplikationen mit unterschiedlichen Versionen, Schnittstellen, Berechtigungen, Listen etc.) für jedes Spital individuell verschieden ist. Das Evaluationsteam Es liegt in der Natur eines Universitätsspitals und der Zeitdauer eines Projektes, dass Teammitglieder das Spital verlassen. Im Laufe des Projekts haben fast alle Projektmitarbeiter aus verschiedenen Gründen unsere Klinik verlassen. Dadurch ging Fachwissen verloren, Unruhe im Team und Verzögerungen waren die Folge. Obwohl das Projektteam breit abgestützt war, ist zu wenig auf den Einbezug eines Vertreters der Leistungserfassung insistiert worden. Dieser Aspekt hat sich in der zweiten Projekthälfte gerächt und zu Verzögerungen geführt. Vorgaben der Evaluation Aufgrund negativer Erfahrungen einer anderen Klinik betreffend mangelnder Benutzerfreundlichkeit wurde auf diesen Punkt grosses Gewicht gelegt. Tatsächlich ist aus Anwendersicht die einfache Bedienbarkeit zentral für die Akzeptanz. Wie erwähnt, wurde die Leistungserfassung im Vorfeld zu wenig gewichtet. Obwohl die Erfassung von Leistungsdaten im Pflichtenheft verlangt und vom Anwender positiv bewertet wurde, zeigte sich im Nachhinein, dass dieser Parameter ungenügend definiert worden war. Insbesondere wurde zu wenig geklärt, in welcher Applikation erhobene Rohdaten auf welche Weise aufbereitet und weitergeleitet werden. Evaluationsprozess Jede Applikation hat ein spezifisches Datenmodell, welches für die Parametrierung zentral ist. Die klinischen Prozesse und verrechnungstechnischen Aspekte sind zwischen Kliniken und Gesundheitssystemen unterschiedlich und somit auch die Art, welche AIMS-Parameter im Datenmodell wie hinterlegt und verknüpft sind. Obwohl sich im Lauf der Parametrierung in allen Systemen ähnliche Überlegungen aufdrängen, wurden das Datenmodell betreffende Details bei der Evaluation zu wenig berücksichtigt, was beim Verständnis der Parametrierung zu Verzögerungen geführt hat. Diskussion Obwohl die meisten EHR ähnliche Ziele verfolgen und nach Anbieterangaben jedes AIMS alles kann gibt es grosse Unterschiede zwischen den Systemen in Bezug auf Philosophie, Anwendung, Entwicklung und andere Aspekte. Gegen Ende der Implementierung unseres AIMS können wir die Binsenwahrheit bestätigen, dass es kein «bestes» PDMS für die Anästhesie gibt und der Entscheid für ein System immer einen Kompromiss darstellt. Es gibt bestenfalls ein mehr oder weniger passendes System für ein gegebenes Umfeld der Evaluation. Dieses Umfeld ist definiert aus dem Pflichtenheft, den vorhandenen Ressourcen, dem IT-Bereich und kann folgende Aspekte umfassen: Finanzielle Möglichkeiten und Grenzen: Die Offerten betreffend Anschaffung von Hard- und Software, deren Entwicklung, Betreuung und Wartung variierten im mehrjährigen Betrieb um mehr als einen Faktor 3; Vorgaben der zentralen oder Departementsinformatik in Bezug auf Hardware, Software, Betriebssysteme, Netzwerkintegration, Berechtigungen, Directory-Anbindung und Schnittstellen: Die Verwendung von strategischen Betriebssystemen, Hardware, Datenbanken und Applikationsplattformen garantiert den reibungslosen Betrieb der Lösung. Schwierig gestaltete sich die Integration in die IT-Landschaft im OP-Umfeld, weil in diesem Bereich viele heterogene Lösungen existieren. Personelle Ressourcen: Grosse Kliniken haben oft eigene Mitarbeiter mit Vorkenntnissen und Interesse an Informatik, für welche der Einsatz in einem PDMS-Team eine willkommene Abwechslung oder sogar Beförderung bedeutet. Sind keine entsprechenden In-House- Ressourcen vorhanden, müssen die entsprechenden Dienstleistungen beim Lieferanten oder bei Drittunternehmungen eingekauft werden. Synergien mit anderen Applikationen: Einzelne Anbieter haben dezidierte Lösungen für spezifische Abteilungen, z.b. ausschliesslich für die Anästhesie. Andere Lösungen können den ganzen Patientenprozess abbilden von der umfassenden Datenerfassung der Notfallstation über Anästhesie und Intensivmedizin bis hin zur Pflegedokumentation der Abteilungen. Soll eine Applikation auf mehr als einer Klinik eingesetzt werden (Anästhesie und Intensivmedizin und Notfallstation), so steigt der Projektaufwand nicht zwingend um den Faktor 2 oder 3. Es wird aber aufgrund der verschiedenen klinischen Bedürfnisse schwieriger werden, einen Kompromiss im Pflichtenheft und in der Evaluation zu finden. Spezifische Ausschreibungen für einzelne Kliniken können deshalb zu pragmatischen und schnellen Lösungen führen, auch wenn nicht alle Synergien berücksichtigt werden. Klinisches Umfeld: Soll das AIMS nicht nur im Perimeter eines Operationssaals, sondern auch im mobilen Bereich (office based anesthesia) eingesetzt werden, so steigen die Anforderungen an Hardware, Netzwerk, lokale Verfügbarkeit und andere Faktoren deutlich. Die entsprechenden Limiten (z.b. WLAN) führen dazu, dass in vielen Spitälern trotz installierten und funktionierenden EHR parallel noch auf Papier dokumentiert werden muss. Projektziele: Während einzelne Applikationen als reine Dokumentationssysteme deklariert werden, bieten andere eine Unterstützung der klinischen Entscheidungsfindung an. Verantwortlichkeiten: Schliesslich ist es zentral, wer die treibende Kraft hinter einem PDMS ist. Oft wird der Wunsch nach einem EHR aus den Kliniken an die Spitalleitung herangetragen, während aus unserer Sicht der Weg umgekehrt sein sollte. Der Kliniker kann noch lange mit Papierdokumenten leben, die Spitalleitung hat aber ein zentrales Interesse an Prozessoptimierung und 14

Kennzahlen. Ist der Auftraggeber die Spitalleitung, so sind die nötigen Personalressourcen aus Kliniksicht einfacher zu erhalten. In Bezug auf die Parametrierung gibt es keinen Free Lunch, d.h., hohe Flexibilität und Leistungsfähigkeit bei einfacher Parametrierung gibt es nicht. Ein System mit grossen Freiheiten in Bezug auf Parametrierung und Entwicklung bedingt zwangsläufig ein grösseres Customizing, d.h. Anpassung der Applikation an die eigenen Bedürfnisse. Hat man die Ressourcen für eine eigene Parametrierung nicht, so muss man ein System mit einfacheren Funktionalitäten wählen. Ohne die Ressourcen für eine spätere Anpassung landet man bei der Philosophie «never touch a running system» und darf sich später nicht über fehlende Entwicklungsmöglichkeiten wundern. Der Aufwand für das Customizing einer Applikation an die eigenen Bedürfnisse ist grundsätzlich unverändert, egal ob man dies beim Anbieter einkauft oder eigenes Personal freistellt. Das Customizing durch den Anbieter wird teilweise als einfachere Variante dargestellt, bietet aber aus unserer Sicht keine Vorteile. Der Anbieter braucht trotzdem intensiven Kontakt mit den Klinikern zur gewünschten Parametrierung, Testung und Schulung, und ohne klinikinterne Erfahrungen mit der Anpassung der Oberfläche wird man finanziell, zeitlich und funktionell vom Anbieter abhängig bleiben. Auf jeden Fall ist in der Anfangsphase ein intensiver Kontakt mit und eine Schulung der Parametrierung durch den Anbieter unerlässlich. Schliesslich müssen die Grenzen der Leistungsfähigkeit einer Applikation frühzeitig kommuniziert werden, um die Mitarbeiter aus Klinik, Forschung oder Leistungserfassung nicht zu enttäuschen. Ein pragmatischer Ansatz mit einer 80/20 Lösung führt oft schneller zum Ziel als der Versuch, jegliche Spezialfälle und Wünsche zu berücksichtigen. Obwohl einige Anbieter von AIMS ihre Applikation als Dokumentationssoftware bezeichnen, ist es dennoch so, dass am Ende des Tags Leistungs- und andere Daten aus dem System exportiert werden müssen. Das frühe Einbinden der Rechnungsabteilung ist zwingend nötig: «perhaps the largest end-user of any AIMS actually the anesthesia billing office» [13]. Die Erwartungen, die an ein EHR in Bezug auf Rentabilität, Sicherheit, Prozessoptimierung und anderes gesteckt werden, können oft gar nicht erfüllt werden [7]. Insbesondere die Hoffnung auf schnellere Leistungserfassung und Rechnungsstellung muss aufgrund der Abhängigkeiten zu Umsystemen in einem Grossspital relativiert werden. Obwohl, wie oben erwähnt, ein pragmatisches Vorgehen der Berücksichtigung jeglicher Eventualität vorzuziehen ist, muss das Pflichtenheft äusserst sorgfältig auf Basis von Anwendungsfällen erstellt werden. Dies ist zentral für die Ausschreibungsunterlagen und Evaluation und erleichtert spätere Vertragsverhandlungen. Letztere sind umso einfacher, je genauer die Ausschreibungsunterlagen sind und Faktoren beinhalten wie minimale Verfügbarkeit, Bonus- Malus-Regelungen oder die geistigen Eigentumsrechte an späteren Weiterentwicklungen. Schliesslich ist zu betonen, dass ein eingeführtes PDMS per se noch keine Prozessoptimierungen schafft. Das PDMS kann helfen, Prozessmängel zu erkennen, die Umsetzung mit teilweise unangenehmen Gesprächen muss der Kliniker aber selber vornehmen. Einzelne grosse medizintechnische Firmen können umfassende Systeme anbieten inklusive medizin-technische, patientennahe Geräte, Hardware, Netzwerk und Software, während sich andere, v.a. junge und kleinere Firmen auf Teilaspekte spezialisiert haben. Die Wahl eines grossen und umfassenden Anbieters kann den Vorteil haben, dass im Fall einer Dysfunktion ein einzelner Ansprechpartner die Verantwortung übernimmt, während bei kleinen «Teil- Anbietern» ein «Fingerpointing» auf Partnerfirmen droht. Die Wahl der ersten Option «erkauft» man sich jedoch mit einer möglichen Abhängigkeit und mangelnder Flexibilität bei späteren Ersatzgeschäften. Die Innovationsbereitschaft ist bei beiden Varianten nicht selbstverständlich. Während grosse Firmen oft träge auf Trends und Kundenanforderungen reagieren, fehlen kleineren Anbietern eventuell Ressourcen und Innovationskapital. Literatur 1 Rowe L, Galletly DC, Henderson RS. Accuracy of text entries within a manually compiled anaesthetic record. Br J Anaesth. 1992;68:381 7. 2 Reich DL, Wood RK Jr, Mattar R, Krol M, Adams DC, Hossain S et al. Arterial blood pressure and heart rate discrepancies between handwritten and computerized anesthesia records. Anesth Analg. 2000;91: 612 6. 3 Benson M, Junger A, Michel A, Sciuk G, Quinzio L, Marquardt K et al. Comparison of manual and automated documentation of adverse events with an Anesthesia Information Management System (AIMS). Stud Health Technol Inform. 2000;77:925 9. 4 Bowens FM, Frye PA, Jones WA. Health information technology: integration of clinical workflow into meaningful use of electronic health records. Perspect Health Inf Manag. 2010;7:1d 5 Mangalmurti SS, Murtagh L, Mello MM. Medical malpractice liability in the age of electronic health records. N Engl J Med. 2010;363:2060 7. 6 Slagle JM, Weinger MB. Effects of intraoperative reading on vigilance and workload during anesthesia care in an academic medical center. Anesthesiology. 2009;110:275 83. 7 Muravchick S, Caldwell JE, Epstein RH, Galati M, Levy WJ, O Reilly M, et al. Anesthesia information management system implementation: a practical guide. Anesth Analg. 2008;107:1598 608. 8 Egger Halbeis CB, Epstein RH, Macario A, Pearl RG, Grunwald Z. Adoption of Anesthesia Information Management Systems by Academic Departments in the United States. Anesth Analg. 2008;107:1323 9. 9 Ehrenfeld JM, Rehman MA. Anesthesia information management systems: a review of functionality and installation considerations. J Clin Monit Comput. 2011;25:71 9. 10 Weinger MB. Electronic health records. N Engl J Med. 2010;363: 2372 3. 11 Blumenthal D, Tavenner M. The meaningful use regulation for electronic health records. N Engl J Med. 2010;363:501 4. 12 Taylor RF. Electronic health records. N Engl J Med. 2010;363:2373; author reply 2374. 13 Sandberg WS. Anesthesia information management systems: almost there. Anesth Analg. 2008;107:1100 2. 15

Automatisierte Plausibilitätsprüfung der elektronischen Pflegedokumentation auf somatischen Allgemeinstationen Entwicklung von Regeln und Überprüfung der Regelgüte Jens Schall a, Ursula Hübner b a Stabsstelle EDV der Pflegedirektion, Universitätsklinikum Aachen A.ö.R., Deutschland b Forschungsgruppe Informatik im Gesundheitswesen, Fakultät Wirtschafts- und Sozialwissenschaften, Hochschule Osnabrück, Deutschland Summary An electronic nursing record is implemented in many hospitals, although applications for quality assurance of the documentation contents have not yet been published. Therefore, this study examined whether rules for plausibility checks may be operationalised and used as rules in an expert system. Rules concerning 8 subject areas of nursing action were identified and transformed into codes for data interpretation. The rules were applied on data excerpted from 29,776 electronic nursing records from the university hospital Aachen. The expert system classified each nursing record into one of five possible classes ranging between applicable and not applicable. To exam the quality of control, a control sample of 15 nursing records were evaluated by 3 nursing experts. A total of 77.3% of the nursing records were rated applicable or rather applicable concerning the total-plausibility by the expert system, and 7.07% were rated rather not applicable or applicable. The most frequent cause of implausibility of data was a missing description of the patient s condition aligned with a documented intervention. The evaluations of the nursing experts deviated highly from the rating of the expert system, in addition to been inconsistent with one another. The results prove a deficit of documentation concerning the patient s condition, a deviation among experts evaluations, and the facility of expert systems to be used as support in quality assurance. Einleitung Die inhaltliche Plausibilität ist für die Verwendung einer Pflegedokumentation als Unterstützung im Behandlungsprozess und zum revisionssicheren Leistungsnachweis pflegerischen Handelns von Die Autoren haben keine Interessenskonflikte im Zusammenhang mit diesem Beitrag deklariert. hoher Relevanz [1]. Zudem gewinnt die Pflegedokumentation bei der Abrechnung von Behandlungsfällen innerhalb des deutschen DRG-Systems an Bedeutung. Somit steigt auch die Bedeutung einer Qualitätssicherung der Dokumentation. Regelbasierte Expertensysteme zur automatisierten Plausibilitätsprüfung elektronischer Pflegedokumentationen sind bislang nicht beschrieben, werden jedoch in anderen Bereichen der medizinischen Dokumentation bereits angewendet [2]. In dieser Studie sollen Plausibilitätsregeln identifiziert, bei einem grossen Datensatz elektronischer Pflegedokumentationen angewendet und hinsichtlich ihrer Aussagekraft untersucht werden. Methodik Als Rohdaten dienten 29 776 elektronische Pflegedokumentationen von somatischen Allgemeinstationen des Universitätsklinikums Aachen aus dem Zeitraum von April bis Dezember 2010. Es wurden 1 378 381 Pflegeinterventionen und 165 267 Zustandsbeschreibungen ausgelesen. Aus Literatur [2, 3] und Protokollen nach der Methode des lauten Denkens [4] von zwei Pflegeexperten wurden Plausibilitätsregeln für acht Themenbereiche pflegerischen Handelns identifiziert (Atmung, Ausscheidung, Körperpflege, Ernährung, Bewegung, Dekubitusrisiko, Dekubitus, sonstige Wunden). Als massgebliche Basis der Plausibilitätsprüfung dienten Angaben über die durchgeführten Pflegeinterventionen (nach dem LEP nursing 3.1-Interventionskatalog) und strukturierte Zustandsbeschreibungen zum Patienten (z.b. Pflegeprobleme, Wunddokumentationen, Pflegeanamnesen). Zur Prüfung der Pflegedokumentationen wurde auf Grundlage der identifizierten Regeln ein Expertensystem in SAS umgesetzt. Dieses ermittelte pro Themenbereich eine Plausibilitätsbewertung in Form von Prozentanga- Korrespondenz Jens Schall Stabstelle EDV der Pflegedirektion Universitätsklinikum Aachen A.ö.R Pauwelsstraße 30 DE-52074 Aachen schall.jens@gmail.com 16

ben (plausible Angaben/Gesamtangaben). Anschliessend wurde die Gesamtplausibilität für jede Pflegedokumentation einer von fünf möglichen Klassen (von «trifft nicht zu» bis «trifft zu») zugeordnet. Zur Überprüfung der Aussagekraft gaben drei Pflegeexperten ein Urteil zur Plausibilität einer geschichteten Stichprobe (n = 15 Pflegedokumente, 3 je Gesamtplausibilitätsklasse) anhand einer 5-poligen Likert-Skala («trifft nicht zu» bis «trifft zu») ab. Resultate Bei 77,3% der Pflegedokumentationen wurde die Gesamtplausibilität durch die SAS-Auswertung mit «trifft zu» oder «trifft eher zu» beschrieben, in 15,5% mit «weder noch» und in 7,07% Fällen mit «trifft eher nicht zu» und «trifft nicht zu». In 0,13% der Fälle konnte keine Datenauswertung durchgeführt werden. Der häufigste Grund für eine Implausibilität war eine fehlende Zustandsbeschreibung bei einer dokumentierten Intervention, nicht jedoch umgekehrt (nur max. 1,3% der Fälle). Die Einschätzungen der Pflegeexperten und des Expertensystems wichen stark voneinander ab (Kendall s W = 0,119), genauso wie diejenigen der Pflegeexperten untereinander (Kendall s W = 0,114). Diskussion In fast einem Viertel der Dokumente ergab die automatisierte Plausibilitätsprüfung ein Ergebnis von «weder noch» plausibel und schlechter. Dies ist im Wesentlichen darauf zurückzuführen, dass die Benennungen von Patientenzuständen (als Auslöser von Interventionen) in der Pflegedokumentation nicht hinreichend waren. Die Ergebnisse zeigten auch, dass die Einschätzungen der Experten untereinander und vom Expertensystem stark abwichen, dies steht im Einklang mit Studien über medizinische Diagnosen [5]. Die Nutzung des Vier-Augen-Prinzips bei der Plausibilitätsprüfung ist auch unabhängig von der Nutzung eines Expertensystems unerlässlich. Bei der Qualitätssicherung kann ein Expertensystem eine effiziente Hilfe für einen Pflegeexperten darstellen, eine vollständige Übernahme dieser Funktion durch das Expertensystem ist jedoch nicht sinnvoll. In der automatisierten Plausibilitätsprüfung und den Expertenprüfungen wurden keine unstrukturierten Daten berücksichtigt, wie sie bislang einen grossen Teil der Dokumentation ausmachen. Eine Pflegedokumentation sollte möglichst viele strukturierte Elemente in Form von standardisierten Katalogen und Terminologien enthalten, um automatisiert prüfbar zu werden. Die Sprache und Struktur von Zustandsbeschreibungen sollte jedoch grundsätzlich auf Ihre Gebrauchstauglichkeit für den Pflegealltag geprüft werden, eine Zurückhaltung bei der Dokumentation von Patientenzuständen könnte sonst hierin begründet sein [6]. Diese Arbeit bietet eine Basis für weitere Forschungen in diesem Bereich, wie die Ausweitung einer automatisierten Plausibilitätsprüfung auf andere Bereiche der Pflegedokumentation (z.b. Zuleitungen/Ableitungen, Medikation), die Verknüpfung mehrerer Themenbereiche (z.b. Bewegung und Ausscheidung) und die Möglichkeiten zur Prüfung von Freitext-Dokumentationen. Literatur 1 Projektgruppe P 42 der MDK-Gemeinschaft: Grundsatzstellungnahme Pflegeprozess und Dokumentation. Handlungsempfehlungen zur Professionalisierung und Qualitätssicherung in der Pflege. 2005. Online verfügbar unter: http://www.mds-ev.org/media/pdf/p42_pflegeprozess1.pdf [zuletzt aktualisiert am 06.04.2005, zuletzt geprüft am 12.10.2010]. 2 Schmitz A. Plausibilitätsregeln edmp Diabetes mellitus Typ 1 und typ 2. 2008. Online verfügbar unter: http://www.vdek.com/vertragspartner/ DMP/diabetes2/plausibilitaetsrichtlinie/anl_3_dm1_und_2_edmp.pdf [zuletzt aktualisiert am 28.01.2008, zuletzt geprüft am 25.10.2010]. 3 Rossbruch R. Die Pflegedokumentation aus haftungsrechtlicher Sicht. In: Pflegerecht 2008;(6):126 131. 4 Frommann U. Die Methode «Lautes Denken». Online verfügbar unter: http://www.eteaching.org/didaktik/qualitaet/usability/lautes%20denken_eteaching_org.pdf [zuletzt geprüft am 15.4.2011]. 5 Stausberg J, Lehmann N, Kaczmarek D, Stein M. Reliability of diagnoses coding with ICD-10. In: Int J Med Inform. 2008;77(1):50 7. 6 Maanen Hv. Die Entwicklung einer Pflegefachsprache aus einer pflege wissenschaftlichen Perspektive: Das Warum und Wozu. In: Pflege 2002;15:198 207. 17

Effizienzsteigerung dank Planungssoftware? Ein erster Schritt zu E-Health 1 Jutta Spengler a, Andreas Altorfer b a BEDAG Informatik AG, Bern b Abteilung für Psychiatrische Neurophysiologie, Universitätsklinik und Poliklinik für Psychiatrie, Bern Summary Objective: The primary goal of this study was quantitative investigation of the benefits of planning software for outpatient care. The second objective was to investigate whether health service providers are aware of a substantial benefit in using the new application. Methods: The performance of health service providers was investigated in a comparative study before and after the introduction of planning software. A paper survey was also conducted to ascertain their subjective experiences before and after implementation of the planning software. Results: The results of this investigation showed no significant effect in terms of financial efficiency. In this respect, the introduction of planning software had no significant effect on the return achieved. However, introduction of the planning system generated significantly greater satisfaction among the health service providers (Chi2 = 38.03, p <.001). Conclusion: The results of this study confirm that the introduction of planning software is of benefit to health service providers. However, an isolated solution embodying one sub-process only (planning), is of limited value for the overall treatment process. The planning system is just one part of a combined treatment process. In this respect it is important to integrate a specialised tool into an overall system of organisation and documentation. Nevertheless, the results obtained describe important planning elements which may be integrated into a clinical information system (CIS). Einleitung Die Autoren haben keine Interessenkonflikte im Zusammenhang mit diesem Artikel deklariert. Um die hohe Informationsdichte zu bewältigen und Arbeitsabläufe in der ambulanten Sprechstundenplanung der psychiatrischen Poliklinik effizienter zu gestalten, wurde in den Universitären Psychiatrischen Diensten Bern (UPD) im Juni 2008 eine Ressourcen- und Agendenplanung eingeführt. 1 Studie im Rahmen der Master Thesis, MAS Medical Informatics, Medical Technology Center, an der Berner Fachhochschule, Titel: Efficiency-evaluation of a planning software for outpatient care. Ziel der vorliegenden Studie ist es, den Nutzen der eingeführten Planungssoftware durch einen Vorher-Nachher- Vergleich nachzuweisen. Folgende Aspekte wurden untersucht: Effizienz: Werden die Sprechstundenangebote besser genutzt (Anzahl vereinbarte Stunden, Anzahl effektiv abgerechnete Leistungsstunden)? Werden die ambulanten Leistungen besser abgerechnet (Verhältnis der vereinbarten Stunden zu den erfassten Leistungen)? Sind die Anwender besser ausgelastet (Anzahl vereinbarte Stunden pro Mitarbeiter bzw. Anzahl abgerechnete Leistungsstunden im Verhältnis zur Arbeitszeit [Produktivität])? Nutzen: Erlebt der Anwender einen nachweisbaren Nutzen durch die Anwendung der Ressourcen- und Agenden- Planungssoftware? Die steigenden Gesundheitskosten zwingen die Leistungserbringer, betriebswirtschaftliche Ansätze umzusetzen. Die neue gesamtschweizerische Spitalfinanzierung, welche per 1. Januar 2012 [1] umgesetzt wird, erhöht den Druck zusehends. Im Weiteren steht das medizinische Fachpersonal täglich im Spannungsfeld, qualitativ hochstehende Leistungen zu erbringen und möglichst kostengünstig zu arbeiten. Dabei verschlechtern sich die Arbeitsbedingungen, da als Folge eines zunehmenden Personalmangels in vielen Spitälern Überbelastungen zur Regel werden. Laut einer Studie der Stiftung Careum soll der Personalmangel bis zum Jahr 2030 mit ca. 190 000 fehlenden Gesundheitsfachpersonen gravierende Ausmasse annehmen [2]. Die Behandlung der Patienten muss gemäss der Leistungsvereinbarung mit den kantonalen Gesundheitsbehörden und den Vorgaben der Krankenversicherer hohe Korrespondenz: Jutta Spengler MAS Medizininformatik BEDAG Informatik AG Gutenbergstrasse 3 CH-3011 Bern jutta.spengler@bedag.ch 18

Qualitätsstandards erfüllen. In diesem Zusammenhang scheinen sich elektronische Informationssysteme zur Dokumentation geradezu aufzudrängen. Laut der Studie «Swiss ehealth Barometer» sind Faktoren wie elektronische Hilfestellungen zur Arbeitserfüllung (z.b. Kataloge, Guidelines, Interaktionsprüfungen bei der Medikation, etc.) und die geforderte Effizienzsteigerung Treiber von e-health [3]. Ausgangslage Die Sprechstundenplanung und die Zuteilung der zuständigen Assistenz- und Oberärzte wurden in der psychiatrischen Poliklinik in der Vergangenheit auf Excel vorgenommen, wöchentlich angepasst und ausgedruckt. Damit die Poliklinik den wachsenden Ansprüchen an eine effiziente und transparente Patientenplanung Rechnung tragen konnte, wurde als Alternative im ersten Quartal 2008 eine Ressourcen- und Agenden-Planungssoftware evaluiert, implementiert und im Juni 2008 operativ dem Betrieb übergeben. Fragestellungen Die Verwendung eines Planungsinstruments ist nur dann sinnvoll, wenn eine effektivere Verteilung der Termine vorgenommen werden kann und wenn die Benutzer gegenüber früheren Varianten der Agendenführung einen nennenswerten Nutzen erfahren. Effizienz Die Effizienz des Planungsinstruments soll mit der Erfassung der erbrachten Leistung und des tatsächlich abgerechneten Ertrags gemessen werden. Es wird gegenüber der vorherigen Agendenführung eine Effizienzsteigerung in den erhobenen Kennwerten von mindestens 15% erwartet. Eine optimale Planung schliesst eine Auslastung des Leistungserbringers mit ein, die seine Verfügbarkeit im jeweiligen Angebot möglichst vollständig nutzt. Es wird gegenüber der vorherigen Agendenführung eine um mindestens 15 Prozent höhere Auslastung der Therapeuten erwartet. Nutzen Neben einer Effizienzsteigerung in der Planung der Termine wird auch ein positiver Effekt des Planungsinstruments auf die Personen erwartet, welche die tatsächlichen Termine vergeben und somit als Anwender ein zufriedenstellendes Instrument benützen sollen. Es wird gegenüber Abbildung 1 Mittelwert in CHF und Std Err, Ertrag pro Minute, geplante Fälle. der vorherigen Agendenführung im Excel eine signifikant höhere Zufriedenheit erwartet. Methoden Erhebung der Effizienz Im Rahmen einer retrospektiven Vergleichsstudie wurden erfasste TARMED-Leistungsdaten pro Patient der Organisationseinheit «Poliklinik Sprechstunden» mit der vorherigen Agendenplanung und dem neuen Planungsinstrument verglichen und in Relation zu den geplanten und den effektiv abrechnenden Erbringern gesetzt. Es wurden zwei vergleichbare Gruppen gebildet, die in einem Zeitraum von 15 Monaten mehr als 10 000 Beobachtungseinheiten aufweisen (vgl. Tab. 1). Tabelle 1 Stichprobeneinteilung: Gruppen, Zeitraum, genutzte Daten. Gruppe Zeitraum von Zeitraum bis Monate Fälle A 01.03.2007 31.05.2008 15 11 352 B 01.06.2008 31.08.2009 15 10 963 Erhebung des Nutzens Wir wollten den heutigen Benutzern der Planungssoftware die Gelegenheit geben, das Produkt aus ihrer Sicht zu bewerten. Die Zufriedenheit der Nutzer wurde mit einem Fragebogen zur Ergonomie erfasst (adaptiert nach dem Fragebogen «Beurteilung von Software auf Grundlage der Internationalen Ergonomie-Norm ISO 9241/10» [4]). Es konnten 40 Anwender für die Erhebung der Anwenderzufriedenheit gewonnen werden. Die Daten wurden anonym erhoben. Um den Rücklauf zu sichern, konnte der Fragebogen elektronisch oder auf Papier ausgefüllt werden. Resultate Erfassung der erbrachten und abgerechneten Leistungen Eine positive Wirkung der eingeführten Planungssoftware in der postulierten Höhe (15%) konnte bei den geplanten Sprechstunden nicht nachgewiesen werden. Auf der Fallebene (Perspektive behandelter Fall unabhängig vom Erbringer, Gruppen N A= 1582 und N B = 1944) konnte keine Effizienzsteigerung in den erbrachten und effektiv abgerechneten Leistungen beobachtet werden. Zwischen den Gruppen A und B zeigte sich eine Differenz von 6,39%. In der Gruppe B wurden durchschnittlich 0,27 Franken mehr Ertrag pro Minute erwirtschaftet (vgl. Abb. 1). Bei ungeplanten (d.h. kurzfristig vereinbarten) Sprechstunden konnte auf der Fallebene zwischen den beiden Gruppen ein signifikanter Unterschied im mittleren Ertrag pro Minute Sprechstundenzeit festgestellt werden (N A = 546 und N B = 701, t = 4,208, p <0,0001). Wir beobachten zwischen den Gruppen A und B eine Differenz von 19