Swiss Medical Informatics - SMI 55

SMI 55

SGMI • SSIM • SSMI

SGMI SSIM SSMI

Schweizerische Gesellschaft für Medizinische Informatik Société suisse d'informatique médicale Società svizzera d'informatica medicale Swiss Society for Medical Informatics

Swiss Medical Informatics

Schwerpunkt / Thème principal: Open Source – Open Standards – Open Access Schwabe AG Verlag · Basel

Swiss Medical Informatics Table of contents

SGMI SSIM SSMI

Table of contents

2 Editorial (B. Sauter) 3 Open Source Software in the biomedical domain (S. Meystre, H. Müller)

16 Open-Source-Systeme in der Mailumgebung am USZ (A. Senn)

22 Online radiological examination: open-source tool for federal certification (J. Billet, T. Zand, C. Lovis)

27 Was haben Open Standards mit eHealth, eGovernment und eGovernance zu tun?

(M. Denz)

29 Kooperation der SGMI mit der Fachgruppe eHealth des Vereins eCH und der europäischen CEN/ISS «eHealth Standardization Focus Group» (M. Denz, M. Demarmels, M. Colomb)

32 Die Schweizer Versichertenkarte im Spannungsfeld internationaler Standards (M. Colomb, B. Arnet, M. Denz)

36 HL7 – Arbeiten am offenen Standard (B. Heggli)

39 Freier Zugang zu wissenschaftlicher Information (I. Zimmermann)

44 News/Impressum

SGMI SSIM SSMI

Swiss Medical Informatics Editorial

Editorial Benno Sauter

Kontaktadresse: Dr. med. Benno Sauter Leiter Wissensmanagement Schweizer Paraplegiker-Zentrum 6207 Nottwil E-mail: benno.sauter@paranet.ch

2

Open Source – Open Standard – Open Access: Auf den ersten Blick scheinen diese Dinge nicht viel gemeinsam zu haben.

Doch in einer Zeit, in welcher der Kostendruck auf das Gesundheitswesen immer stärker wird und nach und nach bis an die Schmerzgrenze der möglichen und sinnvollen Massnahmen reicht oder diese gar übertrifft, ist es angebracht, auf breiter Basis nach Sparpotentialen zu suchen und diese umzusetzen. Gleichzeitig aber gilt die moderne Informations- und Kommunikationstechnologie auch im Gesundheitswesen als Schlüsseltechnologie, die es einzusetzen gilt. Dennoch investieren immer noch zu wenig Unternehmen im Gesundheitswesen in den konsequenten Einsatz von Informations- und Kommunikationstechnologie (IKT), da die Budgets für neue Anschaffungen und auch für die steigenden laufenden Kosten nicht ausreichen. Der Begriff «Open», welcher den Produkten im Titel gemeinsam ist, bedeutet neben «offen» auch kostenfrei. Es ist daher im Zusammenhang mit Kosten aller Art interessant, so genannte kostenfreie Produkte und Dienstleistungen auf ihre Tauglichkeit zu überprüfen.

In der vorliegenden 55. Ausgabe von «Swiss Medical Informatics» haben wir zunächst eine Reihe von Artikeln für jene bereitgestellt, die sich mit den Fragen rund um Open Source auseinandergesetzt haben oder sich damit noch befassen werden. Wir haben versucht, die Thematik möglichst breit abzudecken und praktische Beispiele zu geben, die sich direkt und indirekt mit generellen Fragestellungen beschäftigen, um alle Interessierten anzusprechen. Es ist sicherlich sehr interessant, zu sehen, wie die vorgestellten Open-Source-Projekte implementiert wurden bzw. wie sich die eingesetzten Produkte bewährt haben. Aus Platzgründen haben wir uns auf medizininformatische Anwendungen beschränkt – viele Gesundheitsinstitutionen könnten aber auch von weiteren Open-Source-Produkten wie Content-Management-Systemen oder eLearning-Plattformen profitieren.

Aus diesem Grund wird im kommenden SMI 56 die Thematik rund ums eLearning nochmals aufgegriffen – für in diesem Zusammenhang an Open-Source-Produkten Interessierte sei vorab auf die sehr gute Site http://www.opensourcecms.com verwiesen – eigentlich ein Muss für alle, die

diese Zeilen lesen. Spätestens seit Herbst 2005, als der Open Source Webbrowser «Firefox» freigegeben wurde und dieser wegen seinen Vorzügen nicht mehr aus den Schlagzeilen kam, wissen alle, dass OpenSource-Produkte mindestens ebenso gut wie gekaufte Software sein können. Möglicherweise auch wegen der dadurch gestiegenen Nachfrage hat Google eine spezielle Plattform für Open-Source-Produkte eingerichtet (http://code.google.org).

Offene Standards sollen auch zukünftig im Gesundheitswesen dafür sorgen, dass die interinstitutionelle Kommunikation und die Kosten dafür möglichst gering gehalten werden können. Die Bestrebungen, welche in einer offiziell dafür zusammengesetzten Fachgruppe zusammengestellt wurden, sind in einem Beitrag dargestellt. Ein konkretes Beispiel für die Umsetzung offener Standards ist im Zusammenhang mit dieser Arbeitsgruppe beigefügt. Ein weiterer spezieller Beitrag zum Thema Open Standards zeigt in dieser Ausgabe, wie und mit welchem Einsatz die damit befassten Arbeitsgruppen in internationaler Zusammenarbeit operieren.

Ebenso aufschlussreich wie interessant ist der Artikel, welcher die Initiativen Open Archives und Open Access in der Welt der Fachpublikationen vorstellt. Vor allem auch im medizinischen Sektor wird dieses Anliegen letztlich auch aus Kostengründen von einer wachsenden Anhängerschaft mitgetragen.

Ob Open Access, Open Standard oder Open Source – allen gemeinsam ist, dass eine gute Idee und viel persönliches Engagement von Menschen mitgetragen werden, die auf das gemeinsame Ziel hinarbeiten.

Energie, die sich nicht primär nur von Gewinnmaximierung nährt, sondern primär aus Spass, persönlicher Überzeugung und ein wenig Ehrgeiz bezogen wird und die daran teilhabenden Menschen eint – ein guter Zug, auf den aufzuspringen es sich sicher auch finanziell lohnen kann.

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Open Source Software in the biomedical domain Electronic health records and other useful applications

Stéphane Meystrea

Summary

Henning Müllerb

There are few subjects in computer science where the discussion is more emotional than Open Source Software (OSS). People are either strongly favouring its use or are straightforward against it, often without knowing the details of available software or the licensing conditions.

a

Department of Medical Informatics, University of Utah, Salt Lake City, Utah, USA

b

Department of Medical Informatics, University Hospital of Geneva, Geneva, Switzerland

This article gives an overview of available OSS in the medical domain, mainly centred on available open source Electronic Health Records. Much of the software for a hospital infrastructure can be obtained free of charge, but the main costs in a hospital environment are on adaptations of software for a particular setting and on maintenance.

These costs also apply to open source software, which is therefore not without cost.

The article also outlines the advantages and problems of OSS through a review of the literature to de-emotionalise the debate and concentrate rather on the facts. In addition, the potential of OSS is being described, for example in developing countries.

Key words: Open Source Software; OSS; free software; libre software; FOSS; FLOSS; medical records systems; computerised

Introduction

Correspondence: Stéphane Meystre Department of Medical Informatics University of Utah School of Medicine Room AB194 Salt Lake City, UT 84132–2913 E-mail: s.meystre@utah.edu

SMI 2005; No 55

Medical errors and patient safety have become very timely topics in healthcare since a few years, especially after the U.S. Institute of Medicine (IOM) Report estimating that medical errors were the cause of 44’000 to 98’000 deaths every year in the U.S. [1]. In a later report, Paul C. Tang, Chair of the IOM Committee on Data Standards for Patient Safety said that “electronic health records that allow care providers to gather, store, and use health information more efficiently could increase the effectiveness of care and greatly reduce errors and costs”[2]. Several barriers to the wide adoption of Electronic Health Records (EHR) remain. In primary care, barriers like excessive cost, instability of vendors, and

lack of common data standards have been mentioned [3].

Free and Open Source Software (FOSS) is software with an openly published source code, usually available at no charge, and often developed by voluntary effort and participation of a large number of people [4].

FOSS reduces ownership and development costs. It also avoids the vendor “lock-in”, and improves the use of data standards, as FOSS is known for embracing standards. As Kantor et al. mention, FOSS may turn out to be the force that helps overcome barriers to the use of the EHR in primary care and in the rest of the health care system [5]. The FOSS movement is gaining growing interest among scientific communities and among healthcare and public administration organisations. The possibilities offered by FOSS are also important for developing countries [6], where licensing and cost issues have encouraged many to adopt open source products, to the point that whole countries such as Peru have mandated the use of FOSS in their administration. Australia and the state of Massachusetts in the U.S. have strongly encouraged the use of FOSS in public services. The WHO plans to use FOSS to monitor AIDS patients in countries where there is not enough money to even buy basic medication [7]. In Europe, the Free/Libre and Open Source Software (FLOSS) Survey and Study commissioned by the European Commission in 2001–2002 [8] popularised the movement.

Cities like Munich and Paris are encouraging their public services to use FOSS. The European Commission is regularly funding projects through its research frameworks.

The fifth Framework (1998–2002) placed a strong emphasis on projects yielding FOSS as one of the outputs. It funded projects like SPIRIT1 with the aim to accelerate the use of open source software in healthcare, disseminating best practice in FOSS and news about FOSS projects. In the UK, the NHS

1 http://www.euspirit.org/

3

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

(National Health Service) Information Authority encouraged development and research in the open source field, and cosponsored the 2001 annual meeting of the OSHCA (Open Source Health Care Alliance) in London. Despite interest in open source solutions by the NHS, a recent licensing agreement was signed with Microsoft to provide most of the software needed across the British healthcare system, locking all users into Windows and Microsoft Office for nine years. The deal mentioned that Microsoft would develop “a health specific user interface for clinical systems” at “no charge” to the NHS [9].

Another important aspect in Europe is the support of several languages in software.

Whereas the most popular software products such as Windows are translated into languages that have a major market, specialised software is often only available in its original language, most often English. Open source licenses allow translating the software into any other language, which is not possible for closed source software. Rare languages can thus be supported by FOSS like OpenOffice that exists in many languages.

For health-related software, we will mention in the text when the software is available in a German or French version. Several open source software packages have a description of how to perform a translation easily.

Background FOSS is also named Open Source Software (OSS), Free Software, Libre Software, or Free/Libre and Open Source Software (FLOSS). These names are used for freely modifiable and redistributable software, and do not refer to zero-cost software. Free Software was the name originally used, and “Open Source” is a name created to avoid confusion over the term “free” in the Eng-

Open source (source code freely available) No or limited cost to the user

Non-commercial FOSS

Closed source (source code not available)

Commercial FOSS

Figure 1. Classification of software [8].

4

Short history of FOSS In the 1960s and 1970s, revenues in computer business were generated through hardware products, the latter usually having their own operating system. UNIX was developed by the AT&T Laboratories to be deployed on multiple hardware platforms.

It was available at low cost for academic institutions, often including the source code for direct changes by scientists. In the 1980s, UNIX became restricted to paid licenses and was delivered without source code. Other hardware companies started developing proprietary UNIX operating systems. At that time, Richard Stallman started a project to develop a free alternative to the UNIX operating system called GNU (GNU’s Not UNIX). He established a fairly restrictive license using the term copyleft to protect the rights of open source software and their derivations and created the Free

Freeware Shareware3

Some cost to the user

lish language. Both names refer to a similar sort of software but emphasise different rationales. Free Software is advocated by the Free Software Foundation (FSF2) as a more ethical and social movement, emphasising the freedom to run, study, redistribute, and improve the software, as detailed in the Free Software Definition [10]. Open Source Software has a more practical definition [11] as defined by the Open Source Initiative. The main concepts of the definition are the free redistribution of software that includes source code, certain authorisations or prohibitions of derived works, and prohibition of discrimination against persons, groups, or fields of endeavour. FOSS and FLOSS are hybrid terms for both the Free Software movement as well as Open Source Software. The name “Libre Software” was created by the European Commission in 1992, to avoid the English ambiguity with “Free Software” and the misunderstandings of “Open Source” alike. All those names should not be confused with Freeware or Shareware. Availability of source code and cost can be used to classify software into four groups (figure 1).

Commercial/Proprietary software

2 http://www.fsf.org/ 3 No cost during the initial evaluation period.

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Software Foundation (FSF) in 1985 to support his project. In the 1990s, many open source projects emerged. The most prominent example is Linux, a UNIX-like operating system developed to run on personal computers. Linus Torvalds, a now famous Finnish computer scientist, developed the kernel for an open source operating system he called Linux. He released an early version as open source and asked for help and feedback. In 1991, a modified version of UNIX was released as freely downloadable source code by the University of California at Berkeley. It was called BSD (Berkeley Software Distribution) and is now an open source version of UNIX used by many others. In 1997, Eric Raymond and Bruce Perens founded the Open Source Initiative (OSI4) in order to establish a more pragmatic approach to software licensing. They developed the Open Source Definition to promote FOSS in the business world. The history of FOSS is described in details in two books, “The Cathedral and the Bazaar” [12], and “Open Sources – Voices from the Open Source Revolution” [13].

In the healthcare domain, the COSTAR ambulatory medical record was one of the first FOSS in the late 1970s, even before the definition of FOSS existed [14]. The U.S. Veteran’s Administration system called VistA was also a pioneering healthcare FOSS but the use of FOSS in healthcare has received more attention only since a few years. Organisations to promote the use of FOSS in healthcare have been created, such as OSHCA5 and working groups in the International Medical Informatics Association (IMIA) and the American Medical Informatics Association (AMIA). The OBF6 (Open Bioinformatics Foundation) has contributed to the rapid development of FOSS that has occurred in our sister field of bioinformatics. In other medical domains like Radiology, FOSS played an important role to create standards: DICOM (Digital Imaging and Communication in Medicine, standardised since 1995) became the standard for communication between imaging modalities, archives and Radiology Information Systems (RIS). From thebeginning, the Radiological Society of North America (RSNA) helped creating open source software to promote the standard and facilitate development based on this software7. This open source software is still used by many

SMI 2005; No 55

vendors in their software and modalities and was the basis for the success of this standard.

FOSS licenses Open Source does not mean public domain, which implies no copyright or license limitations and allows others to copyright and impose their own restrictions on derived material. Open source licenses share two characteristics: the source code has to be made available, and license fees are typically waived. The most common license is called GPL (GNU General Public License), and is used in the GNU project and by Linux. It does not restrict copying and redistribution, but source code must be made available to the user, and the license has to be enclosed with the distributed software. Modifications are allowed and derivative work is permitted but has to be published under the GPL again. This “viral” effect makes GPL not very business-friendly. To answer this problem, the FSF also offers the LGPL (GNU Lesser General Public License). This license allows commercial software to use FOSS without being “contaminated” by the GPL. This allows creating part of a project in GPL but the libraries in LGPL to ease commercial add-ons to software. Many open source projects created their own licenses, often based on the GPL or LGPL and containing only small modifications.

The MPL (Mozilla Public License) was developed by Netscape to release the code of its Netscape web browser. The main difference with the GPL is the possibility to incorporate software under MPL into software products that can be licensed without “contamination”. The BSD License and the Apache Foundation’s licenses are similar to the LGPL or MPL license, but do not require derived work to be free again. There is no “viral” effect. The large number of licenses for open source software creates a lot of confusion. A project to reduce this and create a flexible license framework is the Creative Commons initiative8. Creative Commons contains licenses for software but 4 5 6 7 8

http://www.opensource.org/ http://www.oshca.net/ http://www.open-bio.org/ http://dicom.offis.de/dcmtk.php.en http://creativecommons.org/

5

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

also for digital art and music. The toolbox of licenses allows a flexible use of licensing, always having in mind to promote the distribution of content in a free way.

forge10, and OSDIR11. Some of the most common and famous FOSS projects are described below, starting with general projects and following with projects really focused on the medical domain.

Open Source in healthcare The academic literature about FOSS in healthcare is very limited. In 2000, Douglas Carnall published a letter advocating the use of FOSS in healthcare [15], with a more complete electronic version also [16]. In 2002, Graham Wright and Peter Murray published a paper to propose the creation of the IMIA open source working group [17].

An interesting white paper about the use of FOSS by the UK NHS was published, but then removed in 2004 when the NHS finally contracted with Microsoft. In 2003, Clement McDonald and colleagues have described open source, its use in healthcare, and the FOSS developed at the Regenstrief Institute for Health Care in Indianapolis (Indiana, U.S.) [18], and Gareth Kantor and colleagues published a letter to support the use of FOSS in primary care [5]. Other articles discuss the various aspects in which open source can help the health systems [19, 20].

Methods An extensive literature and electronic information search was conducted at the end of 2004, using the following terms: open source, free software, FOSS, FLOSS, OSS, free medical record, free electronic medical record, free EMR, free EHR, free CBPR, free CPR, and free record. Documents that were retrieved came from academic literature, MEDLINE, library databases, conference proceedings, and Internet websites.

This collection of literature and electronic information was then reviewed for its value and for the development of a global view of FOSS in healthcare, with an emphasis on EHRs. Several programmes were installed and tested locally to get a better idea of the quality of available software and problems.

Results In general, tens of thousands of FOSS applications exist and are available on Internet websites, such as freshmeat9, Source-

6

General open sources software usable in a medical context Apache is the most widely used web server in the world, with a current market share of almost 70%12. It was developed by the U.S. National Centre for Supercomputer Applications. Since 1999, the Apache Software Foundation is responsible for its development [21]. It can be used for all web-based applications and user interfaces and works on a large number of computer platforms.

Linux is a famous operating system kernel.

It provides basic functionalities of the operating system. The Linux kernel, when combined with other components of an operating system (GNU, X-Windows windowing system, gcc compiler, etc.) results in a socalled “Linux distribution”, like the wellknown Red Hat, SUSE, or Mandrake products. Many people refer to this combination as just “Linux”, and others refer to it as “GNU/Linux” for GNU-based distributions. It is a stable server platform that is gaining in market share and importance.

Most large companies already use Linux and it is also used in hospitals, often as file or print server. It represents about 25% of the server operating systems, and 4% of the desktop operating systems worldwide.

Knoppix is a Linux Distribution that can be run on a CD-ROM and that does not need any installation. It also contains other FOSS like OpenOffice, enabling a full working desktop system to be run from the CDROM. OpenOffice13 is the open source version of StarOffice, an office suite product from Sun Microsystems, similar to Microsoft Office. FreeBSD14 was released in 1993, and was initially built on the Berkeley

9 10 11 12

http://www.freshmeat.net/ http://sourceforge.net/ http://osdir.com/ http://news.netcraft.com/archives/ web_server_survey.html 13 http://www.openoffice.org/ 14 http://www.freebsd.org

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Software Distribution (BSD). It is the most popular open source project built on the BSD. Other similar products exist, like NetBSD and OpenBSD. Solaris, the operating system developed by Sun Microsystems, will be released in 2005 as FOSS under the name OpenSolaris15. GNOME16 and KDE 17 are graphical user interfaces that run on top of Linux, providing user-friendly computing to the non-programmer open source community. Mozilla18 is an open source project initiated by Netscape, including a web browser, an e-mail client, and a webpage design application. Its first version was released in 2002 and different versions now exist. Most popular is the web browser, Firefox, released in 2004 and the e-mail client Thunderbird.

MySQL19 is a relational database server initially developed in 1994 and released under the GPL in 2000. Payable versions also exist to allow its use in commercial solutions.

MySQL is used by many large companies and organisations like Motorola, Yahoo!, NASA, the U.S. Department of Defence, Associated Press, and as background database server for many web-based applications.

Different open source programming languages have been developed, especially for dynamic web pages. Perl (Practical Extraction and Report Language) was developed in 1987 for text manipulation, and is now used for a wide range of tasks including system administration, web development, network programming, etc. A great number of Perl modules are available at the CPAN (Comprehensive Perl Archive Network), including modules for creating HL7 (Health Level 7) medical applications. PHP (PHP Hypertext Preprocessor) started in 1995 as a set of Perl scripts called “Personal Home Page Tools”. It is the most popular open source scripting language for web applications. Python20 is another language released in 1991 that evolved quickly into a powerful interpreted object-oriented language. For dynamic Internet websites, one of these programming languages and other FOSS are typically combined to form a “LAMP” system. It contains Linux as the operating system, Apache as the web server, MySQL for the database, and PHP/Perl/ Python for the middleware programming language.

SMI 2005; No 55

Open Source in healthcare FOSS applications in healthcare are only a little fraction of all FOSS, and are listed in various websites. A quite comprehensive list of FOSS projects in healthcare can be found on Yves Paindaveine’s homepage21. Good sources of information are LinuxMedNews22, the OpenHealth23, and AAFP CHIT24 (American Association of Family Physicians’ Center for Health IT) websites. Health Informatics Europe25 has some useful information. In French, the Médecine libre website26 is a good information source. An electronic journal on FOSS in healthcare has been created, the “Journal of Open Source Medical Computing”27.

Open Source Health Records Most open source EHRs are intended for small physician practices, but some are specifically developed for hospitals such as OpenVistA and care2x. OpenVistA28 is the open-source version of VistA, a very complete Computer-Based Patient Record (CBPR) using the MUMPS programming language. It is probably the largest healthcare FOSS collection worldwide. It was developed by the U.S. Department of Veteran’s Affairs (VA), and has been used throughout this organisation since 1982.

It was first known as DHCP (Decentralised Hospital Computer Programme) [22].

Many other organisations have adopted

15 16 17 18 19 20 21 22 23 24 25 26 27 28

http://www.opensolaris.org http://www.gnome.org/ http://www.kde.org/ http://www.mozilla.org/ http://www.mysql.com/ http://www.python.org/ http://homeusers.brutele.be/ ypaindaveine/opensource/inventory.html http://www.linuxmednews.com/ http://www.minoru-development.com/en/ healthcare.html http://www.centerforhit.org/x135.xml http://www.hi-europe.info/library/ opensource/default.htm http://medecinelibre.nuxeo.org/ http://www.josmc.org http://www.worldvista.org/ openvista/index.html

7

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

VistA worldwide, like hospitals in the U.S., Malaysia, India, Finland, Germany, Egypt, Uganda, Nigeria, Colombia, and Pakistan.

The source code was made available under the U.S. Freedom of Information Act (FOIA), and is in the public domain.

Despite the availability of source code, it is difficult to set up a working installation, mostly due to the knowledge needed in the MUMPS language and the complexity of the application. Medsphere29 provides a commercially supported version of OpenVistA. A fully open source version is also available using an open source version of MUMPS called GT.M running on Linux.

We tried installing the software but the installation of GT.M was already difficult, and only a bootable CD version supplied

by VistA was finally tested.

Care2x30 is a complete software package for hospitals and health care organisations (available in German and several other languages, with a description on how to perform a translation). It is designed to integrate data, functions and workflows in a healthcare environment. It contains currently four major components: hospital/ health service information system, practice management (for general practice), central data server, and health eXchange protocol.

Each of these components can work individually. Care2x is used in Italy since December 2004, at the “Policlinico Umberto I di Roma” in Rome. The system also exists as a Mac OS X version. Life demonstrations of the modules are available on Care2x website. The system is based on Linux, MySQL and PHP. The interface is based on web technologies and can be used with any web browser. Input screens can easily be adapted to a hospital’s needs and installation is easy.

FreeMED31 is a practice management and EHR system based on MySQL and PHP, working well on a Linux system. It is HIPAA-compliant (Health Insurance Portability and Accountability Act), and provides billing with a separate application called FreeB. It is “Episode of Care”-based, and allows the tracking of detailed medical data, with preservation of the diagnosis and reasons for medical encounters. Outcome data can be abstracted locally. Commercial support for FreeMED is available. It is easy to install and to customise for a local environ-

8

ment. OpenEMed 32 is a Java application developed at Los Alamos National Laboratory. It is an intuitive patient record system with multimedia support and remote sharing of medical data. It uses a platform independent language (Java), distributed objects, and distributed databases, with public key encryption. A prototype has been released as FOSS. OSCAR 33 (Open Source Clinical Applications and Resources) is a web-based office management and medical record system for family practice developed and used at McMaster University (Hamilton, Ontario, Canada.). It provides registration, scheduling, medical records, and a Canadian billing component. It also offers a patient portal. It is open source at all levels, running on a Linux or BSD system and based on Zope and MySQL. Installation and changes are easy. GEHR 34 (Good Electronic Health Record) is a framework for developing medical record systems, derived from a European research project [23]. It is not a medical record or office practice system per se, but an international attempt to develop open standards for record interchange between different systems. Systems based on GEHR have been developed, and work is underway in Australia to make the system available in the entire country. Access GP 35 is a general practice EHR based on MS Access and Word. It provides patient registration and records with multimedia content, calculators, scheduling, billing, and other administrative tasks. FreeEHR is based on FileMaker, designed by physicians and used in the U.S. and developing countries.

Developed on Mac OS, it also runs on Linux and Windows, providing a patient record with multimedia content, growth charts, practice statistics, scheduling, prescribing, and billing. Running on a proprietary database management system, it is not fully open source. The GNUMed 36 group is developing a system for general practice, but

29 30 31 32 33 34 35 36

http://www.medsphere.com/ http://www.care2x.com/ http://www.freemed.org/ http://www.openemed.org/ http://www.oscarmcmaster.org/ http://www.gehr.org/ http://www.accessgp.com/ http://www.gnumed.org/

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

is not ready for clinical use yet. It uses Python for programming, is based on PostgreSQL, and is cross-platform. A German version is developed at the same time as the English version.

OIO (Open Infrastructure for Outcomes37) is an EHR and Quality Assurance System aiming to facilitate data portability. Major components of the OIO system are the web-accessible Server and Library. The OIO Server is a flexible web-based data management system that manages users, patients, and information about patients. The OIO Library is a metadata repository that facilitates sharing of metadata between users and OIO Servers. The OIO Library also hosts a database of open source medical software projects and related documents. OpenEMR 38 is a practice management and EHR application with e-prescribing and billing functions enhanced by FreeB. OpenEMR also exists for Mac OS X. In the Netherlands, OpenKaart 39 (in Dutch and English) is a general practice system developed incrementally, with preliminary parts being available such as OpenSDE, a patient data entry tool. SQL Clinic 40 is a multi-specialty EHR that is HIPAA-compliant. It offers administrative tools, alerting functions, and quality assurance features. The system is fully open source and programmed in Perl. It uses the Apache server on a Linux or FreeBSD system, with PostgreSQL or MySQL. A Windows version is also available. SQL Clinic is in use in the U.S. and South Africa. Tkfp41 is an EHR for small practices such as in family practices, paediatrics, internal medicine, or primary care, with billing features.

It has been in use in two small physician practices in the U.S. since 5 years. It is based on Tcl/Tk, but also C,C++, Python, and Perl, running on Linux and Windows XP. TORCH 42 (Trusted Open source Records for Care and Health) is a multi-specialty application derived from FreePM and based on Zope. It is a web-enabled EHR application. TORCH is usable in single practitioner and multi-site practices.

Some promising open source EHRs are currently in development, like Res Medicinae 43, a German project using CYBOL (Cybernetics Oriented Programming), an XML-based programming language and as such completely platform-independent (available in German). OpenEHR 44 is a British founda-

SMI 2005; No 55

tion developing open-source specifications, software and knowledge management resources. An interoperable, life-long electronic health record is projected, but only specifications are available yet that are already used in some ER projects [24].

X-Sys Life Record 45 is a web-based EHR already available for testing and scheduled for release in February 2005.

Other medical open source applications Other open source applications developed for healthcare range from decision support tools, to terminological resources. A Linux distribution for healthcare has even been developed – Debian-Med 46 – to ensure smooth integration of third party medical software into Debian. It is distributed via the well-known Debian Linux distribution and includes a very large number of programmes with an official, unofficial, or not yet a Debian package status. Packages are listed in categories, like practice management, hospital management, imaging, pharmacy and research. All packages are included and tested in the distribution.

BolinOS 47 (also available in French and German) is a Content Management System developed with medical web-based applications in mind. It uses standard FOSS: PHP, Apache, MySQL. A version for healthcare is available: BolinOS Med. This medical online authoring software and web-based system is suited for many configurations in internal medicine, radiology, surgery and research, from individual healthcare professionals to large hospital structures. It provides a DICOM viewer and other image formats, XML compatibility, coding (ICD-

37 38 39 40 41 42 43 44 45 46 47

http://www.txoutcome.org/ http://www.openemr.net/ http://www.openkaart.org/ http://www.sqlclinic.net/ http://tkfp.sourceforge.net/ http://www.openparadigms.com/ http://resmedicinae.sourceforge.net/ http://www.openehr.org/ http://www.liferecord.com/ http://debian.org/devel/debian-med http://www.bolinos.com/

9

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

10) modules and options like synchronisation with Palm OS handheld devices. It is used at the radiology of the University Hospitals of Geneva to manage the Intranet and personal pages. iPath 48 is a general-purpose telemedicine platform, more focused on telepathology. The core functionality is the “iPath-Server” with specialised modules developed on top of it. The most important module is a microscope controller, a combination of a client application for a remote workstation and a Java applet allowing controlling a microscope remotely over the Internet. TeleMedMail is another telemedicine application developed to allow telemedicine in developing countries where network connections are often of poor quality. It includes text entry, image processing and compression, and encryption, and uses email to transmit data with images [25].

DOCS4DOCS is being developed at the Regenstrief Institute for Health Care in Indianapolis as a report distribution system for delivering clinical documents such as laboratory reports, discharges summaries, and radiology reports. In these reports, the system captures reports as HL7 messages or print streams and stores them as PDF fragments. The office practices subscribe to the service for their physicians, and define the kind of report they want to receive. The reports are stored as PDF fragments that can be combined into a PDF document in any sort order for printing or archiving.

This system is written in Java, uses PostgreSQL as its database, and runs on the Apache web server, all open source applications. This programme has been delivering reports to more than 100 office practices in Indianapolis in 2003 already, and is planned to be made available under the Apache open source license [18].

Some medical controlled vocabularies and ontologies are available as open source, like LOINC and OpenGALEN [26]. Protégé is a famous ontology and knowledge-base editor [27]. For decision support, the Arden Syntax allows the encoding and exchange of medical knowledge [28], and CLIPS49 allows developing rule-based expert systems.

Finally, MedNotes50 is a decision support resource with many decision support tools for various platforms.

10

Discussion Even if many FOSS solutions exist for the medical domain, they are only seldom used in big hospitals in Europe or North America, because budget for large proprietary software is often available and the responsibility of persons responsible for information systems is important. Barriers to the open source movement in the healthcare industry are numerous. Almost all software is currently more or less proprietary. The health information technology leadership tends to be conservative, and senior management has been eliminating the in-house technical and developmental teams that could best leverage FOSS to the advantage of the institution. Furthermore, healthcare systems operate large, complex, and are 24-hours nonstop operations. They face heavy and changing regulatory burdens, and have strong implementation, support and maintenance requirements. All these needs are not always fulfilled by FOSS. Vendors will need to be convinced by open source software to make it a success as only few hospitals still have real development teams that could customise and maintain an open source solution.

In the related field of bioinformatics, a large proportion of the software used is open source. Numerous FOSS for microarray analysis, genome annotation, visualisation, clustering, and other tasks have been developed and are widely used in this young community where commercial software was far less present than in the healthcare domain. This successful development of FOSS could be a good example for the healthcare domain.

In the general domain, the level of use of FOSS varies widely between countries. In a survey conducted in Europe in 2001–2002, 43.7% of the German establishments were using FOSS, but only 17.7% of the Swedish establishments [8]. A study commissioned by the UK Government in 2001 [29] predicted that within five years, FOSS could take 50% of the volume of the software infrastructure market, and that in the devel-

48 http://ipath.sourceforge.net/ 49 http://www.ghg.net/clips/CLIPS.html 50 http://www.smartie-ist.org/en/

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

oping world, FOSS on the desktop may soon become a significant competitor to Microsoft. During the FLOSS survey [8], the most frequent reasons to use FOSS were: higher stability and better protection against unauthorised access, also with higher performance; low or zero license fees; indirect cost savings from using FOSS, for installation, administration, andcustomisation; only fourth came the open and modifiable source code. Another reason frequently mentioned was “because we want to be more independent from the pricing and licensing policies of the big software companies”.

FOSS has many advantages, but also disadvantages. There is a lack of formal scientific evaluation of the benefits regularly reported by users of FOSS. Reliability and security are important qualities of FOSS. Source code can be inspected by many, and can be maintained even if the original developers are no longer available. The quality builds on many high quality already available components. Developers can build on them and spend their time exploring new and unsolved problems rather than duplicating efforts [12]. Frequent and close peer review of source code results in software being better engineered, more secure and less “buggy” than commercial products. About 120’000 programmers worldwide contribute to the development of Linux. As Linus Thorvalds said, “given enough eyeballs, all bugs are shallow”. There is no evidence yet, that FOSS applications are more reliable than commercial products, but availability of source code makes immediate fixes for identified problems possible.

FOSS has generally a lower total cost of ownership than proprietary software, which is its largest economic advantage. The absence of licensing cost is a major attraction, but for most organisations, licensing is only a fraction of the total cost:customisation, implementation, training, maintenance, and upgrading cost far more. Dependence from vendors is reduced, avoiding the “lock-in” with its related problems when vendors disappear or decide to stop supporting proprietary software. Many healthcare organisations have made the painful experience of a supplier going bankrupt, leaving them with the need to change the system.

Some happy few had source code kept with a third party escrow, a way to reduce the

SMI 2005; No 55

risks of vendor lock. For many other reasons, vendors can demand high prices, knowing that changing the system or the vendor would be even more expensive for the client.

FOSS has a higher compatibility with open standards than proprietary software. It runs on a wide range of hardware, and interoperates with most operating systems. FOSS also has other benefits, ranging from the fact that user needs are often a major driving force behind the development of solutions, to the flexible development process with rapid reactivity and innovation spread. A major quality is the improved accessibility to products in developing countries. The use of FOSS has become a central issue in strategies to reduce the digital divide, the growing technological and commercial gap separating industrialised rich countries from developing poor countries. Cost is the first argument, knowing that few developing countries can afford the cost of proprietary software (not talking about maintenance contracts). For example, in Vietnam, the cost of Microsoft Windows XP and Office is higher than the average annual income! National sovereignty is another argument against proprietary software (often American like Microsoft’s products) from public administration in other countries. Minorities remain at the mercy of large multinational companies regarding support for their culture and language when using proprietary software, while FOSS gives them the freedom to modify all software according to their needs.

In healthcare, FOSS would provide healthy competition to the existing closed source commercial market, encouraging innovation whilst promoting compatibility and interoperation. This ultimately will lead to systems that are lower cost, better quality, and more responsive to changing clinical and organisational requirements [4].

A disadvantage of FOSS is the problem of accountability in the case of errors, since FOSS does not have any established line of accountability. However, vendors should step in here. Another potential disadvantage could arise when FOSS vendors have support as their main revenue stream. They could then have a perverse incentive to increase the number of support calls.

11

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Initiatives to encourage the use of FOSS are developing, particularly in Europe and in Asia. In Europe, the European Commission’s initiative called “eEurope 2005: An Information Society”, set the target “to promote the use of open source software in the public sector and e-Government best practice through exchange of experience across the European Union”. The UK Government has issued a policy for use of FOSS within the UK Government [30]. This policy states that the UK Government will consider OSS solutions alongside proprietary ones. But it also says that it will only use products that support open standards, that it will seek to avoid lock-in to proprietary IT products, and that it will consider obtaining full rights to bespoke software code, all three requirements suggesting that the use of FOSS is obviously wanted. The French Agency for Information and Communication technology was given the assignment in 2001 to ensure governments projects use FOSS whenever possible. In 2004, the administration of Paris announced that it was considering replacing its proprietary Microsoft systems with FOSS such as Linux, OpenOffice, and Mozilla. In Germany, the city of Munich had taken this decision in 2003 already and has installed the first working test desktops.

Around the world, many countries have adopted laws or are discussing laws about the use of FOSS in their government. The state of Rio Grande do Sul in Brazil was the first administration to make FOSS use mandatory in government agencies and non-government-managed utilities. In China, the government decided that the nation should not be subject to another nation’s software. An important effort is put into a national version of Linux, called “Red Flag Linux”. To fight in the desktop area, China has teamed up with South Korea and Japan to develop a Linux-based system for their countries [31]. The Peruvian government has introduced a bill in 2002 regarding the use of FOSS in its government and saying that companies could charge for software and support, but that the source code must be open source to be used in any government application. In Malaysia, the public sector open source master plan made available in 2004 states that “in situations where advantages and disadvantages of OSS

12

and proprietary software are equal, preference shall be given to OSS” [32]. Besides these countries, many others are actively looking at having legislations regarding the use of FOSS, including South Africa, Ukraine, Portugal, and Bulgaria.

To accelerate an open source movement in healthcare, most helpful would be a policy to encourage or require that all software developed with public funds to be released under an open source license. Leaders in the bioinformatics field have argued that in the U.S., all federally funded bioinformatics software should be licensed under the open source model [33]. Public funding agencies should also require the use of widely deployed health informatics standards in all funded development. They should encourage the use of existing low level open source building blocks as the foundation for building the next level open source software.

Finally, having a mechanism to promote awareness of the potentials of FOSS among the medical community can be extremely helpful. The AAMC (American Association of Medical Colleges) is currently considering a proposal to maintain an open source web site. Their initial aim is to educate university medical centres about the benefits of general open source software. To advocate the use of FOSS in healthcare, different organisations have been created in the last years, like OSHCA and the IMIA and AMIA working groups in open source. To stimulate the adoption of EHRs by doctors in the U.S., the Centre for Medicare and Medicaid Services (CMS) is developing a version of VistA, called VistA-Office in conjunction with VA officials. This new system is targeted to small medical practices that have one to eight doctors. It will provide them with a number of modules adapted from VistA, including the CBPR. It will also have new modules for paediatricians and gynaecologists and a patient registration system. The system is planned to be available in July 2005. A license fee will be needed for the underlying Caché programming language, a language based on MUMPS [34].

The development of FOSS also depends on economic and organisational factors that will have to be taken into account. Organisations developing and/or providing FOSS can be profitable by selling products or serv-

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

ices. Products can be packages easing the installation and use of FOSS, like Linux distributions, or proprietary products including FOSS. Different services can be sold like consulting, application implementation and integration, customisation, training, support, and application management, ensuring that the software is continuously performing in the way desired. Large companies developing open source products such as IBM or Sun Microsystems have motivations like standardisation alternative operating systems, therefore reducing costs due to multiple software versions. They also lower the cost of software bundles by integrating FOSS, and improve compatibility of their own hardware or software products when making it compatible with FOSS. Finally, some strategic considerations motivate open source developments, to weaken competitors or enhance the popularity of their own products.

In the long run, any successful open source application will need an organisational structure to allow the process to grow, and money to finance further development.

Linux and Apache are successful examples.

The Linux model uses a centralised control organisation model largely controlled by the original author and a group of close colleagues. Proposals for new applications are rigorously screened on the basis of the programme code quality, and the extent of current use of the proposed addition. Less than 1 in 50 proposals is adopted. The Apache consortium is based on a loose confederation in which the participating organisations vote on proposals for new directions.

The development of FOSS also depends on the acceptance and use of standards. Linking open source modules to independently developed commercial software packages is facilitated by a strong underpinning of deployed standards. Standard interfaces between knowledge sources, communication tools, and patient records, together with interpersonal communication skills, will enable the presentation of new material, and revision of the old, to proceed in real time in the consultation, enabling doctors to be better guides and teachers for those whom they serve [16].

This article can only highlight a small fraction of the open source projects that are

SMI 2005; No 55

usable in the medical field. The field is in constant movement and new projects are created regularly, which is also one of the problems with open source software.

Although there are a few well-known projects with high visibility and very good quality, there are a large number of projects for which the quality is very hard to estimate. It is not sufficient to just create a project and make it open source to attract programmers and users. Quality criteria will need to be defined before making the decision to employ any open source software and the activity and possibility to obtain help quickly will have to be assured.

Conclusion This article gives an overview of the large amount of available FOSS that is usable in the medical domain. Although currently only rarely used in hospitals, open source has a lot of potential to help control the rising cost of our specialised health care and health system by sharing source code and knowledge, and by avoiding redevelopment and overprizing by companies. There are also several problems of open source including: – Difficulty to judge the quality and completeness of an open source project that is available on the Internet; – Lack of support by vendors and lack of a guaranteed quality of service and responsibility in case of errors; – Fear that third parties can include malicious codes into software subsequently being used.

On the other hand, there are a number of undeniable advantages including: – Vendor independence through the availability of source code; – Reduced risk for the user in case of bankruptcy or change in direction of the software producer; – Reduced total cost of ownership, including maintenance, software adaptation and user training; – Ease of adapting the software for special needs; – Reduction of the risk to loose data when migrating to a new software solution; – Help through a large user community.

In many Western European hospitals, FOSS will remain in small areas of the market for

13

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

a while, most likely as a server operating system and for specialised application for another couple of years. In several countries in Asia or Africa, there is actually no alternative to using open source operating systems and patient records on old hardware, as no money is available to buy and maintain expensive medical software. In this scenario, it is important to teach the use of FOSS in these countries so that it can be maintained in a sustainable way in the future, without creation of dependence.

For a brighter future of OS medical software, it is important to create quality criteria, so that a user can possibly judge the quality of available projects and exchange information with hospitals already running the software. It is equally important to motivate vendors to use and support FOSS in a similar way as RedHat and IBM do in the Linux field. Only

this can help convince large hospitals to adopt an open source strategy because responsibility for failures and guaranteed service quality are needed.

One of the important future developments of FOSS is the definition and development of small building blocks for a health information system that can subsequently be combined to a larger system through standard communication interfaces. This possibility to create a large system made of small components was one of the reasons for the success of FOSS (Linux, Apache, PHP, MySQL, etc.) in the Internet field, and it could also become a success factor in the medical domain.

The authors have no commercial relationships with any of the businesses cited in this paper.

References 1 IOM. To Err is Human: Building a Safer Health System: Institute of Medicine (IOM); 1999.

2 IOM. Key Capabilities of an Electronic Health Record System: Letter Report: Institute of Medicine; 2003.

3 Bates DW, Ebell M, Gotlieb E, Zapp J, Mullins HC. A proposal for electronic medical records in U.S. primary care. J Am Med Inform Assoc 2003;10(1):1–10.

4 Smith C. Open Source Software and the NHS: White Paper. In: NHS Information Authority; 2002.

5 Kantor GS, Wilson WD, Midgley A. Open-source software and the primary care EMR. J Am Med Inform Assoc 2003;10(6):616; author reply 617.

6 Rajani N. Free as in Education. Significance of the Free/Libre and Open Source Software for Developing Countries. In FLOSS Report; 2003.

7 President’s Emergency Plan for AIDS Relief – Software Inventory Report, WHO report, 2004.

8 Berlecon Research. FLOSS – Free/Libre and Open Source Software: Survey and Study; 2002.

9 Lettice J. One standard, one Microsoft – how the NHS sold its choice. In: The Register; 2004.

10 FSF. Free Software Definition. In: Free Software Foundation; 2004. (http://www.gnu.org/philosophy/free-sw.html) 11 OSI. Open Source Definition Definition. In OSI, 2004. (http://www.opensource.org/docs/definition_plain.html) 12 Raymond ES. The Cathedral and the Bazaar. Sebastopol, California: O’Reilly and Associates; 2001. (also at http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar) 13 Dibona C, Stone M, Ockman S. Open Sources – Voices from the Open Source Revolution.

Sebastopol, California: O’Reilly & Associates Inc.; 1999.

14 Barnett GO, Winickoff R, Dorsey JL, Morgan MM, Lurie RS. Quality assurance through automated monitoring and concurrent feedback using a computer-based medical information system.

Med Care 1978;16(11):962–70.

15 Carnall D. Medical software’s free future. BMJ 2000;321(7267):976.

16 Carnall D. Open Source Software in Healthcare. In: Informatics review; 2000.

17 Wright G, Myurray P. Open Source: Global Issues. In: MIST2002; 2002.

18 McDonald CJ, Schadow G, Barnes M, Dexter P, Overhage JM, Mamlin B, et al. Open Source software in medical informatics – why, how and what. Int J Med Inform 2003;69(2–3):175–84.

19 Pepper DR, Ellis NT. Academic and commercial development of open source applications in international health informatics – opposite sides of the same coin?, Medinfo 2001, IOS Press, Amsterdam 2001.

14

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

20 Yackel TR. How the open source development can improve medical software, Medinfo 2001, IOS Press, Amsterdam 2001.

21 ASF. Apache. In: Apache Software Foundation; 2004. (http://www.apache.org) 22 Brown Sh, Lincoln Mj, Groen Pj, Kolodner Rm. VistA – U.S. Department of Veterans Affairs national-scale HIS. Int J Med Inform 2003;69(2–3):135–56.

23 Griffith Sm, Kalra D, Lloyd Ds, Ingram D. A portable communicative architecture for electronic healthcare records: the Good European Healthcare Record project (Aim project A2014).

Medinfo 1995;8 Pt 1:223–6.

24 Barretto Sa, Warren J, Goodchild A, Bird L, Heard S, Stumptner M. Linking guidelines to Electronic Health Record design for improved chronic disease management. AMIA Annu Symp Proc 2003: 66–70.

25 Fraser Hs, Jazayeri D, Bannach L, Szolovits P, McGrath Sj. TeleMedMail: free software to facilitate telemedicine in developing countries. Medinfo 2001;10(Pt 1):815–9.

26 Rector Al, Rogers Je, Zanstra Pe, Van Der Haring E. OpenGALEN: open source medical terminology and tools. AMIA Annu Symp Proc 2003:982.

27 Noy NF, Crubezy M, Fergerson RW, Knublauch H, TU SW, Vendetti J, et al. Protege-2000: an open-source ontology-development and knowledge-acquisition environment.

AMIA Annu Symp Proc 2003:953.

28 Pryor Ta, Hripcsak G. The Arden syntax for medical logic modules. Int J Clin Monit Comput 1993; 10(4):215–24.

29 Peeling N, Satchell J. Analysis of the Impact of Open Source Software. In: Ltd. Q, editor: UK govtalk; 2001.

30 OGC. Open Source Software: Use within UK Government. In: Commerce OoG, editor: UK govtalk; 2004.

31 Nagaraj S. Open IT: Government to source code in Linux. The Economic Times 2002 8 October 2002.

32 Sharif R. It’s open source from now on. In: The star online: TechCentral; 2004.

33 Malakoff D. Petition seeks public sharing of code. Sci Magazine 2001;294(5540):27.

34 Brewin B. VA drives open-source health records initiative. In: http://www.FCW.com; 2004.

SMI 2005; No 55

15

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Open-Source-Systeme in der Mailumgebung am USZ Adrian Senn

Einleitung

Universitätsspital Zürich

Das Universitätsspital Zürich (nachfolgend als USZ abgekürzt) betreibt seit längerer Zeit in der Firewall-Umgebung einige auf dem Open-Source-Betriebssystem Linux basierende Systeme.

Die Vorgaben waren, mit einfachen Mitteln eine gut funktionierende Umgebung aufzubauen. Neben den eigentlichen FirewallKnoten, die mit einem RedHat Linux laufen, werden Mailgateways, http-Virenscanner, http-Proxyserver und Reverse-Proxyserver unter der Linux-Plattform betrieben.

Teilweise laufen darauf aber kommerzielle Programme, die Linux als Plattform verwenden.

Wie auch in anderen Betrieben wird das Spam- und Viren- (bzw. Wurm-)problem immer grösser, und von den Kunden wird diesem Umstand auch eine grössere Aufmerksamkeit zugemessen. Dies führte nun dazu, dass am USZ der Wunsch nach einem effektiveren Filter grösser wurde.

Im folgenden Artikel soll vor allem die Mail-Umgebung für die Kommunikation nach aussen beschrieben werden.

Beschrieb der Umgebung Im internen Netz wird seit einigen Jahren eine eigenständige Exchange-Umgebung betrieben. Damit die Kommunikation über die Firewall-Umgebung bewerkstelligt werden kann, sind diverse Mailgateways (sogenannte message transfer agents [MTA]) dazwischengeschaltet, die diverse Funktionen übernehmen.

Kontaktadresse: Adrian Senn UniversitätsSpital Zürich Zentrale Informatik Netzwerkgruppe E-Mail: adrian.senn@usz.ch

16

Mit dem Aufbau der Firewall-Umgebung wurde in dieser ein Virenscanner für das Mailscanning eingehängt. Dieser basiert momentan auf einem Windows-Server und als Virenscanner wird ein Produkt von TrendMicro (Viruswall) verwendet.

Gegenwärtig sind wir dabei, diesen Server durch eine Linux-basierte Plattform zu ersetzen.

Als externer Mailgateway diente lange Zeit ein Linux-Server, auf dem Sendmail als MTA im Einsatz war.

Überlegungen Der Funktionsumfang auf der TrendMicroViruswall lies immer mehr zu wünschen übrig. So konnte keine schnelle Analyse der Virenmeldungen durchgeführt werden.

Ebenso konnte nur mit simplen Mitteln eine Spam-Filterung vorgenommen werden.

Auf dem externen MTA wurden gewisse Verbindungen von potentiellen SpamSendern schon seit längerem durch DNSbasierte Blacklists blockiert.

All diese Mechanismen wurden aber immer ungenügender, so dass von diversen Seiten her der Wunsch kam, einen besseren Spamund Virenfilter zu implementieren.

Aufgrund privater Vorkenntnisse fiel die Wahl auf eine Open-Source-Scanengine mit dem Namen Mailscanner [1]. Bei dem Mailgateway (MTA) wurde ein Wechsel auf Postfix [2] in Erwägung gezogen. Sendmail bietet einen sehr grossen Funktionsumfang, ist aber aufgrund seines Aufbaus nicht immer trivial zu handhaben.

Postfix weist einen ähnlichen Funktionsumfang auf, bietet aber im Aufbau weniger Anlass zu Risiken als dies bei bestimmten Sendmailversionen der Fall ist.

Aufbau des externen Gateways Als Hardwareplattform werden zwei HP DL 380 G3 verwendet. Es handelt sich um ein System mit einem 3-Ghz-Intel-Prozessor.

Als Speicher wurden 1 GB Ram eingebaut.

Diese werden soweit identisch aufgebaut, und einer bildet das Test- und Ausfallsystem für den produktiven Server. Als Betriebssystem wird Suse Linux Enterprise 9 verwendet. Von HP gibt es Hardwaremonitoringtools, die aber nur kommerzielle LinuxVersionen unterstützen.

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Grundsätzlich läuft die weiter beschriebene Mail-Umgebung auch auf anderen LinuxDerivaten. Je nach dem sind gewisse Konfigurationen in gewissen Details anders.

Die Betriebssystem-Umgebung wurde mit den minimalst nötigen Software-Paketen installiert. So wurde auf eine Installation der X11-Umgebung verzichtet, da diese für den Betrieb als Mailserver nicht nötig ist.

Bei Postfix (MTA) wurde nicht die im Paket vorhandene Version verwendet, sondern selber kompiliert, da es so einfacher ist, auf eine neuere Version zu aktualisieren.

Für Mailscanner existieren fertige RPMPakete, die von der Mailscanner-Webseite runtergeladen werden können.

Die Umgebung von SpamAssassin [3] wurde wiederum selber kompiliert, damit auch hier die aktuellen Versionen verwendet werden können. SpamAssassin verwendet diverse weitere Werkzeuge zur Erkennung von Spam, die separat installiert werden müssen. Die Installation dieser Pakete ist im Readme von SpamAssassin gut beschrieben.

Zur Systemüberwachung wurde daneben noch HotSaNIC [4] für die Serverüberwachung und Mailscanner-mrtg [5] für das Monitoring des Mailverkehrs installiert.

Installation von Postfix Die Installation der Postfix-Binaries erfolgte gemäss den Angaben der Installationsanleitung. Für die Konfiguration wurden Beispiele aus dem Internet [6] verwendet und für die eigenen Mailing-Bedürfnisse angepasst.

Für die erste Spam-Abwehr werden einerseits DNS-basierte Blacklists (RBLs), eigene Blacklists und andererseits seit Ende 2004 auch Greylisting [7] eingesetzt.

Da die Mails ins interne Netz an die Exchange-Server weitergeleitet werden, auf denen sich dann die eigentlichen Postfächer befinden, kann Postfix keine lokale Kontrolle über die existierenden Benutzeraccounts durchführen.

Es gibt aber eine Funktion, in der eine Tabelle von Benutzern oder Domains ausgelesen werden kann, für die ein Relaying durchgeführt wird. Diese Tabelle wird durch ein LDAP-Script, das eine Abfrage auf dem

SMI 2005; No 55

Active Directory Service der WindowsServer macht, alle 6 Stunden durch einen Cron-Job aktualisiert. So ist sichergestellt, dass keine Mails an unbekannte Benutzeraccounts angenommen werden, die bei grossen Viren- oder Spam-Befall an nicht vorhandene Adressen die internen Systeme zusätzlich unnötig belasten.

Der Test der Mail-Umgebung mit Postfix sollte in erster Linie ohne die weiteren Spam-Filterfunktionen durchgeführt werden, damit die Analyse auf den eigentlichen Mailverkehr beschränkt werden kann.

Installation von Mailscanner Wie schon erwähnt, können von Mailscanner vordefinierte Pakete verwendet werden.

Neben dem in den SuSe- und RedHatUmgebungen bekannte RPM-Paketformat existiert auch ein Debian-Paketmanager.

Die Installation von Mailscanner benötigt gewisse Zusatzpakete. Die meisten werden mitgeliefert. Wenn ein benötigtes bereits installiert ist, werden diese Teile nicht mehr installiert.

Damit Mailscanner funktioniert, ist SpamAssassin nicht zwingend notwendig. Ebenso ist es nicht zwingend notwendig, einen Virenscanner zu installieren. Ohne diese beiden Module fehlen aber wichtige Funktionen, um einen Inhaltstest der Mails durchführen zu können.

Um die ersten Installationstests durchzuführen empfiehlt es sich aber, diese ohne diese beiden Dienste durchzuführen.

Installation von ClamAV Als Virenscanner wurde auf dem externen Gateway der Open-Source-Virenscanner installiert. Dieser hat sich recht gut bewährt und erkennt die meisten aktuellen Würmer.

Da die Mails intern (Viruswall und Exchange) von TrendMicro Virenscannern nochmals gescannt werden, ist die Erkennungsrate sehr gut.

Der Virenscanner wurde gemäss Dokumentation der ClamAV-Webseite [8] direkt kompiliert.

17

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Installation von SpamAssassin Der Spam-Filter SpamAssassin [3] wurde ebenfalls selber kompiliert. Damit möglichst viele Funktionen genutzt werden können, braucht es diverse Perl-Module, die noch installiert werden müssen. Diese sind aber gut in der Installationsdokumentation beschrieben. Ebenso müssen noch die Zusatzfunktionen wie DCC, Razor und Pyzor separat installiert werden. Letztere drei dienen vor allem der Erkennung von Bulkmails. Das können auch normale Massenmails von Mailing-Listen sein.

Damit der Bayes-Filter aktiviert werden kann, muss dieser mit einem gewissen Anteil an Spam- und Ham- (erwünschten) Mails gefüttert werden. So kann die entsprechende Gewichtung vorgenommen werden.

Für die normalen Filterregeln mit den regulären Ausdrücken gibt es als Erweitungsmöglichkeit die sogenannten «Rules du jour» [9]. Da die normalen SpamAssassin-Filterregeln nicht alle Spam-Varianten erkennen, ist es möglich, mit diesem Script laufend vom Internet aktualisierte Filterlisten runterzuladen.

In Anwendung der Filterregeln wie auch der anderen Filter werden entsprechende Positiv- oder Negativpunkte vergeben. Je mehr Punkte ein Mail erhält, desto eher handelt es sich dabei um ein Spam-Mail.

Abbildung 1. Monatsstatistik des Wurmaufkommens.

Zu den Filterregeln mit den regulären Ausdrücken kann man auch diverse DNSbasierte Blacklists verwenden, die ebenfalls entsprechend gewichtet werden können.

Falls für gewisse Filterregeln zu viele Punkte vergeben werden, kann man diese mit einem eigenen Config-File anpassen, so dass nur wenige oder keine Punkte vergeben werden.

Konfiguration der Umgebung Ein wesentlicher Punkt folgt nun in der Konfiguration der Umgebung, vor allem auch mit Mailscanner. Die Informatik des USZ verfolgt schon lange die Policy, dass ausführbare Inhalte (.exe, .bat, .com, .vbs, .pif, .lnk usw.) von Mails grundsätzlich nicht akzeptiert werden. Dies geschah schon länger auf den Exchange-Servern und wird neu auch auf dem externen Gateway so gehandhabt. Die Vergangenheit hat mehrfach gezeigt, dass eine gewisse Zeit nötig ist, bis die Antivirensoftware-Hersteller ihre Signaturmuster auf den aktuellen Stand gebracht haben und diese auch zur Verfügung stellen.

Bei grösseren Epidemien kann dies schon dazu führen, dass die Würmer ungehindert auf die Mailboxen der Benutzer gelangen.

Und es hat sich auch gezeigt, dass diese Mails häufig von den Benutzern geöffnet werden.

Leider werden Würmer auch als .zip verschickt. Wenn man Dateien mit dieser Endung verbieten will, braucht es auch eine entsprechende Benutzerschulung, damit solche verpackten Dateien verschickt werden können. Mailscanner bietet auch die Möglichkeit, Passwort-geschützte .zip-Dateien nicht durchzulassen.

Neben den normalen Tests auf die Dateiendungen bietet Mailscanner auch die Möglichkeit, Dateien, die nicht dem normalen Namensmuster entsprechen, zu entfernen.

Dies können zum Beispiel Dateien mit mehreren Endungen oder solche mit mehreren Leerschlägen (Whitespaces) sein.

Abbildung 2. Jahresstatistik des Wurmaufkommens. Gut sichtbar im November die

Reduktion durch das Greylisting. Die Statistik reicht nicht weiter zurück, da zu diesem Zeitpunkt ein Server-Wechsel stattfand.

18

Bei den Wurmmails ist es möglich, dass diese an die Benutzer weitergeleitet werden oder dass diese Mails gar nie beim Empfängerpostfach, sondern direkt auf dem Server in der Quarantäne landen. Es empfiehlt sich

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Zusätzlich bietet Mailscanner auch die Möglichkeit, Formulare, JavaScript, Phishing, IFrame und andere aktive Inhalte in HTML-Mails zu erkennen und je nach Konfiguration zu entfernen oder zu deaktivieren. HTML-Mails können auch gleich in Textnachrichten umgewandelt werden.

Aus Sicherheitsgründen empfiehlt es sich, alle aktiven Möglichkeiten in HTML-Mails zu deaktivieren. Über diese Wege wird verhindert, dass unkontrolliert Scripts auf dem PC ausgeführt werden, die zu einem Download von Trojaner führen können.

Die Meldung, die an die Benutzer geschickt wird, lässt sich nach den eigenen Bedürfnissen konfigurieren. So bestehen verschiedene Vorlagen für die verschiedenen Meldungen, die von Mailscanner erzeugt werden.

Abbildung 3. Übersicht über die Statistiken von Mailscanner-mrtg.

aber auf jeden Fall, dass man als Administrator eine Nachricht erhält, wenn ein verseuchtes Mail eingetroffen ist. Es lässt sich so auch eruieren, wer der eigentliche Urheber der Mail ist. Häufig haben die Benutzer das Problem, dass sie das Gefühl haben, dass jemand ihnen ein Mail geschickt hat, da sie die Absenderadresse kennen. Es ist aber in den meisten Fällen so, dass die Würmer ihre Absenderadresse aus dem Adressbuch des verseuchten PC entnehmen und sich so als verschiedene Absender ausgeben.

Bei uns werden die Mails an die Benutzer weitergeschickt, aber der Wurm durch eine Textnachricht ersetzt. Bei Makroviren (Word, Excel), bei denen sich der Dateianhang säubern lässt, werden die Anhänge an die Benutzer weitergeschickt.

Bei Spam wird die Möglichkeit geboten, Spam-Mails als Dateianhang weiterzuschicken. Hier kann man eine Unterscheidung machen zwischen Mails, die eine bestimmte Punktzahl erreichen. In der Konfiguration des USZ werden Mails über 10 Punkte als Dateianhang weitergeschickt.

Zwischen 5 und 10 Punkten wird ein Mail als Spam markiert. Die Wahrscheinlichkeit, dass hier Mails fälschlicherweise als Spam deklariert werden, ist noch grösser, als wenn diese eine hohe Punktzahl erreichen.

SMI 2005; No 55

Monitoring der Umgebung Wie schon erwähnt, existieren zum Monitoring der Umgebung verschiede Werkzeuge.

Um eine einfache Überwachung über die Auslastung der Hardware zu haben, hat sich HotSaNIC [4] bewährt. So sieht man auf einen Blick die wichtigsten Parameter wie CPU-Auslastung, Load des Servers, Anzahl der Prozesse, Auslastung der Netzwerkkarte, Auslastung der Harddisks und diverse andere Werte. So lässt sich im Dauerbetrieb abschätzen, ob die Hardware die Last, die für alle Funktionen nötig ist, überhaupt zu verarbeiten mag. Wichtig ist hier vor allem, dass genügend Arbeitsspeicher (Ram) vorhanden ist, da viele Funktionen für das Mailscanning speicherintensiv sind.

Für die Überwachung des Mail-Verkehrs wird am USZ Mailscanner-mrtg [5] eingesetzt. Damit sieht man auf einen Blick, wie sich die Maillast auf dem Server verhält. So werden auch Statistiken über die aktuell gefundenen Würmer, Anzahl Spam-Mails und natürlich auch die Menge der Mails inklusive des transportierten Datenvolumens angezeigt. Damit alle Funktionen genutzt werden können, muss das Logging in Mailscanner so konfiguriert werden, dass alle Informationen ins Logfile geschrieben werden. Wie die Statistiken bei Mailscanner-mrtg ausschauen, ist in den Bildern dargestellt.

19

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Erfahrungen im Betrieb Aus Sicht des Server-Betriebs haben sich die getroffenen Massnahmen vollends bewährt.

So konnte der Spam- und Wurmanteil massiv reduziert werden und die Erkennungsrate von Spam ist hoch. Als Beispiel sind Statistiken zu dem Spam- und Virenaufkommen dargestellt. Es muss jedoch berücksichtigt werden, dass bei der Kurve zu Spam sehr viel am Mailserver blockiert wird (dunkelblaue Kurve) und nur ein sehr kleiner Anteil effektiv noch durchkommt.

Davon wiederum ist ein gewisser Teil Würmer, da diese aufgrund bestimmter Merkmale auch als Spam deklariert werden.

Dies ist auch der Grund, dass in der Jahresstatistik die Kurve im Januar abfällt, da sich da einer der aktiven Würmer deaktiviert hat. Das Gesamtvolumen an Mail beträgt etwa 19 000 Mails, die täglich durch den Server gehen. Aus Resourcen-Gründen wurde das Scanning von ausgehenden Mails für den Spam- und Wurmfilter momentan nicht aktiviert. Wenn sich aber zeigen sollte, dass Würmer sich über den vorgesehenen Kanal verschicken sollten, ist das Scanning sicher zu aktivieren.

Von Benutzerseite gab es zur Spam-Filterung bislang sehr wenige negative Reaktionen. Für gewisse Mailing-Listen mussten Anpassungen vorgenommen werden, da

Abbildung 4. Monatsstatistik über das Spam-Aufkommen. Die Skala unter Message

bezieht sich auf die Anzahl Mails, die blockiert wurden (dunkelblaue Linie) oder das Total (Pink).

Abbildung 5. Jahresstatistik über das Spam-Aufkommen. Der Rückgang im Januar ist

diese teilweise Mails verschicken, die die gleichen Muster wie Spam-Mails aufweisen.

Häufig handelt es sich dabei um HTMLMails.

Mit dem Greylisting konnte der Anteil an Spam- und Wurmmails auch nochmals massiv reduziert werden. Greylisting kann auch gewisse Probleme bieten, wenn der Mailserver, der ein Mail schicken will, gewisse Standards nicht einhält oder kennt. Die Greylisting-Funktion schickt dem anderen Mailserver einen temporären Fehler. Ab diesem Zeitpunkt läuft ein Counter mit einem definierten Zeitwert (z. B. 300 Sek.).

Wenn dieser Counter abgelaufen ist, nimmt der Server die Mail an, wenn diese wiederum von der gleichen IP-Adresse, Absenderadresse und Empfängeradresse stammen.

Grundsätzlich können auch Würmer oder Spammer einen weiteren Zustellversuch mit diesen drei oben genannten Kriterien unternehmen und die Mail wird dann auch angenommen.

Allgemeine Überlegungen zu Spam- und Wurmfilterung Auch wenn die Spam- und Wurmfilterung auf dem gleichen System geschehen, sind es doch zwei verschiedene Mechanismen, die dahinter stehen.

Bei einem Wurm- oder Virenmail ist aufgrund von Mustern in der Regel klar erkennbar, ob das Mail verseucht ist oder sogar nur einen Wurm enthält. Es ist eine Frage der Policy oder der Benutzerinformation, ob man solche Mails an die Benutzer weiterleiten will oder nicht. Grundsätzlich sollte den Benutzern aber auch bewusst sein, dass es solche Mails gibt und sie lokal auf ihrem Client die Möglichkeit haben, diese Mails zu löschen bzw. entsprechende Filterregeln einzurichten. Erfahrungsgemäss gibt es aber einige Benutzer, die sich gestört fühlen, wenn sie Würmer oder Unzustellbarmeldungen (Bounces) von solchen Würmern erhalten. Gerade letzteres lässt sich leider nicht vermeiden, da der Absender ja gefälscht werden kann und dieser nicht verifiziert wird.

Adressfälschung wird häufig auch bei SpamMails angewendet, um die eigentliche Absenderadresse zu verstecken.

auf eine Selbstabschaltung eines Wurms zurückzuführen.

20

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Bei Spam-Mails ist es schwieriger festzulegen, ob diese auf dem Gateway gelöscht oder an die Benutzer weitergeleitet werden.

Wird dies gemacht, so sollte dies auch gegenüber den Benutzern so kommuniziert werden. Zusätzlich sollten nur Mails gelöscht werden oder in die Quarantäne gehen, wenn diese eine bestimmte Punktzahl übersteigen. Ansonsten ist die Gefahr zu gross, dass erwünschte Mails den Empfänger nicht erreichen. Neben der Greylisting-Funktion gibt es auch noch die Möglichkeit, DNSbasierte Blacklists zu verwenden, um Mails direkt auf dem MTA zu blockieren, so dass diese nicht zugestellt werden. Diese sind mit einer gewissen Vorsicht zu verwenden, da es sonst dazu führt, dass man eine entsprechende Whitelist von erwünschten Mailservern führen muss. Zusätzlich werden diese auch von SpamAssassin zur Punktebeurteilung verwendet.

Vergleich zu kommerziellen Produkten

Je nach dem empfiehlt es sich auch, gewisse dynamische Netze von Providern, die immer wieder Probleme verursachen, direkt zu blockieren. Es ist aber zu beachten, dass sich teilweise hinter ADSL- oder Cablemodem-Anschlüssen fixe IP-Adressen verstecken und immer mehr Firmen dahinter eine Mail-Umgebung betreiben.

Andere Spam-Filter-Lösungen basieren auf eigenständiger Hardware, sogenannten Appliances, die teilweise wiederum auf Open-Source-Lösungen, teilweise auch mit SpamAssassin basieren und eine fertig konfigurierbare Oberfläche bieten. Diese bieten aber nicht unbedingt die Flexibilität eines eigenständigen Mail-Servers. Für kleinere Umgebungen kann dies aber sicher eine Lösung darstellen.

Für viele Funktionen, die auf dem Mailscanner ausgeführt werden, lassen sich benutzerdefinierte Regeln erstellen. So ist es auch möglich, Benutzer, die ihre SpamMails selber aussortieren, diese ohne Scanning weiterzuleiten. Bei anderen Funktionen ist es nicht in jedem Fall sinnvoll, da sonst die Sicherheit gefährdet werden kann.

Es gibt auch Benutzer, die am liebsten keine Spam-Mails haben. Es bedarf eines gewissen Aufklärungsbedarfs, dass es je nach dem in ihrer Verantwortung liegt, mit der MailAdresse vorsichtig umzugehen. Eine MailAdresse, die im Internet auf Webseiten bekannt wird, ist vor Spam-Attacken eher gefährdet. So sollten diese auch nicht mehr einfach auf Firmenwebseiten präsentiert werden oder nur funktionelle Adressen verwendet werden. Auch empfiehlt es sich, nicht dem Wunsch nachzugeben und alle Mails, die als Spam erkannt werden, zu löschen. Früher oder später vermisst die gleiche Person ein wichtiges Mail.

Die aufgezeigte Lösung ist eine von mehreren Varianten. Es existieren einige kommerzielle Lösungen. Bei einer gewissen Menge von Benutzern kommen die Lizenzkosten bei gewissen Produkten in Bereiche, für die man eine Person anstellen kann, die sich fast nur um die Mail-Systeme bzw. um die Spam-Filter kümmert. Es gibt auch Lösungen, die an die Benutzer nur eine Meldung schicken, dass ein Spam-Mail oder ein Dateianhang in der Quarantäne liegt und dieses Mail abgerufen werden kann. Bislang kam es aber selten vor, dass dies effektiv ein Wunsch war bzw. in den seltenen Fällen kann der Dateianhang manuell nachgeliefert werden. Oftmals ist auch ein Hinweis an die Benutzer nötig, dass sie das nächste Mal die Datei richtig schicken.

Ebenso gibt es auch andere Open-SourceLösungen, die Mails bereits beim Einliefern kontrollieren. Es ist da aber teilweise schwieriger, separate Filterlisten für spezielle Benutzerbedürfnisse zu führen.

Glossar MTA = Message Transfer Agent: Mailgateway, das eine Mail an einen weiteren MTA weiterreicht oder lokal in die Postfächer überreicht.

Weiterführende Links 1 ttp://www.mailscanner.info 2 http://www.postfix.org 3 http://spamassassin.apache.org/ 4 http://hotsanic.sourceforge.net/ 5 http://mailscannermrtg.sourceforge.net/ 6 http://sbserv.stahl.bau. tu-bs.de/~hildeb/postfix/ 7 http://isg.ee.ethz.ch/tools/postgrey/ 8 http://www.clamav.net/ 9 http://www.exit0.us/ index.php?pagename=RulesDuJour

SMI 2005; No 55

21

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

Online radiological examination: open-source tool for federal certification Jerome Billeta, Tristan Zandb, Christian Lovisa a

Service of Medical Informatics, University Hospital of Geneva

b

Service of Radiology, University Hospital of Geneva

Introduction Following the introduction of new criteria for the Swiss federal certification of radiologists as part of the Swiss Medical Association (FMH), the Service of Medical Informatics (SIM) at the University Hospital of Geneva (HUG) was asked to develop a computerised examination.

The training of radiologists in Switzerland is supervised by the FMH. This training is evaluated by two examination stages in order to assess the future-radiologists’ level of knowledge. Passing the examination is the prerequisite for obtaining the official professional certification. The second-part of the examination contains questions related to radiological-pathology, based on image analysis and description. This examination uses case-based problems and open questions (the quiz) and multiple-choice questions (the super-quiz). The quiz is composed of 30 questions, and the super-quiz of 15 questions. Both contain important radiological images of each case, selected by a group of expert radiologists.

Before the introduction of a computerised examination, images had to be copied manually on films and displayed on wallmounted backlit screens located in the hospital’s corridor. Each candidate had then to walk from one case to another in order to respond to the different questions. Using digital imaging and standard computer technology simplifies the case building as well as the examination process [1].

Each expert should have access to a secure web page where one can build and manage the cases.

Correspondence: Jerome Billet Service of Medical Informatics University Hospital of Geneva CH-1211 Geneva E-mail: jerome.billet@sim.hcuge.ch

22

Each candidate had to have access to one workplace from which one could browse the cases instead of walking from and to the backlit displays that were used previously.

The quality of the final image display had to be good enough to contain pertinent radiological information, while using the standard computers, web browsers, internet connectivity and standard CRT displays

available. Questions and texts had to be presented in at least 3 languages: French, German and English.

Materials and methods As human and financial resources for the project were limited, the choice of using open source packages was made. This choice included the use of Web standards for display and interface design. The use of an open source software foundation seemed to be the best way to minimise costs, to have access to many useful multimedia functionalities, and to preserve a high level of system security and stability. At the same time, future free use of the open source package in our hospital and in other academic infrastructures was guaranteed. In order to ensure an active developer community and future portability, we chose to develop the system under the BolinOS [2, 3] web platform, which relies on worldwide standard open-source software packages: Apache [4], PHP [5] and MySQL [6]. Building the examination system as a BolinOS plug-in opened the door to many improvements.

For example, the complex management of users, groups and experts was an immediate benefit of using this existing platform. But many other functions were readily available, such as authoring history, user tracking, backups, graphical looks, image manipulation. Moreover, CD-ROM or USB key content creation were offered by libraries that were included in the BolinOS package. This existing foundation facilitated the development of the examination system; most of the work was limited to adaptation, parameterisation or fine-tuning of existing functionalities.

In addition, as BolinOS includes a widely used basis such as Apache Web server, PHP scripting language and the MySQL database, all tests, developments and production of both client and server side applications were run on Linux, MacOS X (BSD Unix), Windows, and Solaris machines. This allowed the examination system to rely on

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

minimal requirements for the future operating system independence.

The use of the standard BolinOS system facilitated the integration of basic libraries of functions as well as the other plug-ins that were already available in the system, such as anatomy atlas, image collections management or navigation. The image functions library is used for image generation, format conversion, and image catching. The quiz system extensively uses users and groups management capabilities and adds increased security and possibilities to manage specified examination session duration, result tracking (for online answering), and detailed interactive-browsing analysis.

The ability of the system to natively manage different languages, the “languages selector” plug-in, and a multi-language functions library were very helpful to implement the multi-lingual aspect of the plug-in.

We used the standard BolinOS data class to implement the data side of the plug-in.

Table generation and update, as well as basic forms, archiving and restoring are covered by this BolinOS object. For advanced html edition we used the multimedia editor.

Another major point for the general acceptance of the system was its close relationship with experts. All developments could be realised by the BolinOS team in charge of the Department’s intranet and internet websites and could therefore be done immediately after meetings with the radiological experts. These clinicians often proposed pragmatic and sometimes dramatic changes to the tool after using it. The fast response of the development team and the fulfilment of most requirements, both for functionalities or interface goodies, were key factors for the success of the project. Many developments were made after the first three examination sessions. Users and experts provided the development team many suggestions for improvement. In addition, the development team tried, through multiple brainstorming sessions, to foresee and develop other functionalities that might facilitate the tool’s usability and increase its efficiency.

SMI 2005; No 55

Results This tool has been used since 2001, and has enabled more than 20 radiologists to pass their second-part specialisation examinations yearly. Each year, about 17 experts are implied in the realisation of the 30 cases for the quiz and the 15 cases for the super-quiz.

This results in the upload of more than 150 images, for a final of about 100 images that are used.

The computerised examination environment is easy to use and is user-friendly.

Users must log in the system using their username and password through an encrypted connection. The login gives access to personalised levels of authority on the system and quiz plug-in. User’s profiles can be edited at all time according to the necessary conditions and any level of granularity can be created to encompass needs.

Four profiles were needed to fulfil the needs of the examination system: 1. Administrator: grants all accesses to the site functionalities and contents. A few functionalities will require extra rights in order to get access to the data. Administrators can edit pages, data and user’s profiles; 2. Managers: administrator rights on the cases but no other rights on pages, they can go through all cases, track who and when questions and cases have been added or modified, are notified automatically by email, can manage cases and related documents, check answers, download stand-alone result sheets, and manage authoring history of cases; 3. Authors: authoring rights on their own cases and browsing cases the same way examinees do. Authors can use the editmode to edit cases, but this right will only give them access to their own cases.

They can upload and delete image files as well as add, edit and destroy their own questions. At the same time they have access to other authors’ cases which illustrates the dynamics of the workgroup; 4. Examinees: have only the right to access and browse their assigned cases during the granted time of an exam session and from a defined place on the net (serves as identity and login during the examination session).

23

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

defining rights that were given to the user and page where the quiz plug-in is situated.

These are physically stored on the web page’s corresponding file system securedfolder. Each image is related to one or more cases according to what has been decided by the question’s author. The images that will be displayed on the client Web browser are distributed in minimal-loss JPEG format.

If the uploaded image is in another format, such as DICOM, PNG or bitmap among others, the BolinOS / ImageJ layer of the core system will automatically convert these to the appropriate format in order for the quiz plug-in, or any other image related plug-ins, to be able to manipulate them correctly (figure 1).

Figure 1. Author’s view. Data and images edition of case 3. Authors can upload new

images, edit multi-lingual legends and change image order. The diagnosis field is only accessible by authors and manager and helps them to manage their cases.

All questions in each language are stored in their respective database-specific plug-ins (figure 2 and figure 4), linked to the cases images, and to the answers of all examinees.

Answers are stored along with session information, including things such as time stamp, place of examination, corrections and retries, chronology and sequence of browsed cases, as well as technical information such as browser, operating system, hardware, etc.

Inherent to the development of the examination system are the additions of many functionalities to the core system of BolinOS. The main enhancements that are offered to the open source community were related to image manipulation functionalities and complex user rights organisation, tracking and result management. The integration of the National Institutes of Health open source project ImageJ (Java application) was improved in order to offer an alternate case browser with real-time brightness and contrast adjustments capabilities (figure 3).

Figure 2. Author’s view. Multi-lingual questions and answers edition form of case 2.

The image case collections are using the basic file manipulation of BolinOS. Source images are uploaded to the server, while

24

In addition, the very constraint and robust environment required for a federal examination imposed the development of three modes of execution: 1. Standard mode: uses full server connectivity. Images and texts are served by the web server, as well as answers registration; 2. Mixed mode: images are stored locally to minimise the need of a large bandwidth.

Questions and other texts are stored by the web server.

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

printed, and organise the examination dates.

A few photographers are involved, to scan the rare non-digitised films, usually historical cases, to be used when necessary. The experts receive an account on the BolinOS web server and create / manage their own cases, both for the quiz and super-quiz, entering questions in the language they are used to. The experts meet a few times during the year in order to decide which questions and images are best, to verify and/or translate questions and other texts displayed during the examination, and to review the whole examination before the real date.

Figure 3. Candidate view of case 2. Examinees can browse images using thumbnails

and use the BolinOS embedded viewer to display one image with advanced features like brightness and contrast adjustments capabilities.

Figure 4. Candidate view of case 2. Questions and related texts are displayed according

to the language selected by the examinee.

3. Local mode: a complete static version with JavaScript and Java code inclusion is dynamically generated and transferred to computers. The network connection is only used to register answers.

The team leading the examinations is formed by experts, professional radiologists, coming from all parts of Switzerland. They discuss the cases, choose images, and prepare the questions and multiple-choice answers. Several secretaries are also involved.

They coordinate mostly, type the questions, prepare translations, ensure that the question leaflets used during the exams are well

SMI 2005; No 55

The team of developers devoted to the project varied from one to three during the past three years, mostly working on a punctual basis for the project. Their task included development of the tool, user’s support, debugging and documentation creation.

The project benefited from two important up-scaling processes. The first one was at the occasion of first use in our hospital for examinees, while the second one was reached with the nation-wide extension of the system. By now, experts can use the system from their own workplace in Switzerland, managing their time as desired while having access to other experts’ current work.

Basic teaching of the tool by our development team, the self-registration of authors in the system, a few glitches on users and development sides finally resulted in a small web-savvy (?) radiological community with concrete expertise of simple online examination tools. More surprisingly, the system has even been used as a kind of general forum place, where experts and other radiologists exchanged ideas and experience.

Discussion We demonstrate that using a standard opensource based content management system to implement a completely new and rather complex set of functionalities devoted to a federal medical certification was feasible at reasonable costs and in a short time frame.

In addition to the core functionalities focused on examination (complex management of users, production and management of each case, organisation of the examination, scheduling, examination management, and result processing) we enhanced the core of the BolinOS CMS. One of the major

25

SGMI SSIM SSMI

Swiss Medical Informatics Open Source

improvements was the extension of a digital image browser that was adapted to the examination process and running on a heterogeneous infrastructure. During the first three years, the candidates were able to work on individual stations, thus definitely replacing the cumbersome old-fashioned backlit film viewing in a corridor. The development process, based on extreme programming techniques using fast cycles of develop-test-correct coupled with a strong user-oriented and focused approach led to intensive collaboration between developers and experts or users. The gain was immediate, with a strong acceptance and fine congruence between expectations and realisation. This led also to a good vision of the possibilities and limitations of Web-compatible tools for users, which helped keeping goals reachable. The development of the online examination answering system, while not yet used for the certification, has given rise to new sights for group-oriented authoring, results management and tracking of radiological quizzes.

References 1 Carrino JA. Digital imaging overview. Semin Roentgenol. 2003;38200–15.

2 Zand T, Billet J, Spadola L, Girard C, Geissbühler A, et al. BolinOS. Multimedia Authoring Platform and Web Operating System for Internet / Radiology. Swiss Radiological Society Congress 2003 (SGR – SSR), Luzerne.

3 Zand T, Billet J, Lovis C. BolinOS – Open Source Content Management System for Medicine. Geneva University Hospitals, Switzerland.

4 Apache www.apache.org 5 PHP www.php.net 6 MySQL www.mysql.com

The integration of other open source projects was also a unique opportunity to be involved in the creation of worldwide-academic internet-based tools for radiology, and to share efforts and experience to improve the development of online radiology tools, independently from economical or political needs, hoping to promote such approaches and research in this field.

This examination environment, along with other radiology-related developments at the University Hospital of Geneva, has become one of the first internet accessible examples of academic open source radiological tool developments. This project supports other academic groups worldwide to use and enhance open source applications as a sound alternative to software design, based on sharing knowledge, experience, and realisations. The complete source code is therefore available to any interested person in academic settings. We hope to contribute to the development of a new philosophy in informatics and, in general, in science and information technologies. We believe that knowledge belongs to human kind and that shared common efforts are needed to progress in our fields.

26

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

Was haben Open Standards mit eHealth, eGovernment und eGovernance zu tun?

Martin Denz Präsident der Schweizerischen Gesellschaft für Medizinische Informatik

Korrespondenz: Dr. med. Martin D. Denz Executive Master in eGovernance College of Management of Technology Swiss Federal Institute of Technology EPFL 1015 Lausanne E-Mail: martin.denz@epfl.ch

SMI 2005; No 55

Die nationalen Gesundheitswesen, deren Patienten, die Leistungserbringer, ja alle Interessengruppen im Zusammenhang mit Gesundheit oder Krankheit stehen in einer mehr oder weniger direkten Wechselwirkung zu öffentlichen Strukturen. Die Übersetzung der dabei stattfindenden administrativen Kundenprozesse in Internetbasierte Dienstleistungen für Bürgerinnen und Bürger kann als eGovernment-Aktivitäten definiert werden. Allerdings beschränken sich heutige eGovernment-Anwendungen auf öffentlichkeitswirksame Teilbereiche wie beispielsweise das «eVoting». Es handelt sich dabei um Tool-basierte Pilotaktivitäten, mit welchen neue Formen der «eDemocracy» ausgelotet werden.

Auf diesem Hintergrund wird der Begriff «eHealth» zunehmend als Etikettenschwindel eingesetzt: Es geht dabei nicht mehr darum, bedürfnisgerechte Problemlösungen anzubieten, das Gesundheitswesen wird auf einen wachstumsträchtigen Absatzmarkt reduziert. Ebenso wie seinerzeit das «eBusiness» verkommt dadurch eHealth zu einem modischen Schlagwort. eHealth bedeutet aber, die ICT als Organisations- und Kommunikationsmittel einzusetzen, primär, um damit zur Verbesserung und Fortentwicklung des Gesundheitswesens beizutragen.

Ein erfolgreiches Zusammenwirken von Staat und Privatwirtschaft ist Voraussetzung für eine nachhaltige wirtschaftliche Entwicklung – dies gilt auch für das Gesundheitswesen. Das Gesundheitswesen ist wie andere Industrien auf die sichere Abwicklung der Transaktionen und das reibungslose Funktionieren von Prozessen, Leistungs- und Zahlungsströmen zwischen den Beteiligten angewiesen. Analog der Begriffsentwicklung von «Business» zu «eBusiness» hat sich im Gesundheitswesen der Begriff «eHealth» entwickelt. Unter «eHealth» versteht man den integrierten Einsatz von Informations- und Kommunikationstechnologie (ICT) zur Gestaltung, Unterstützung und Vernetzung aller Prozesse und Teilnehmer im Gesundheitswesen.

Die Gemeinsamkeit zwischen eGovernment und eHealth besteht im Bestreben, die Informations- und Kommunikationstechnologie (ICT) zur Unterstützung spezifischer Leistungen zu verwenden: eGovernment nutzt die ICT in Regierungs- und Verwaltungsprozessen, im Verkehr unter den Behörden und mit dem Bürger; eHealth nutzt die ICT unter anderem bei Patientenmanagement, Ressourcenplanung, Diagnostik und Leistungserfassung. Die Betonung liegt dabei auf dem Begriff «Unterstützung». ICT ist nicht Selbstzweck, sondern soll die Leistungsprozesse in erster Linie vereinfachen, aber gegebenenfalls auch eine «Enabler»-Funktion ausüben und Leistungsprozesse verbessern oder sogar neu schaffen. Wenn aber Technologien ohne vorangehende Prozessanalyse und strategische Planung eingesetzt werden, kann sich dies kontraproduktiv auswirken: Sehr oft werden dadurch die alten Prozesse und Strukturen nicht optimiert, sondern erst recht «mit Hilfe» von ICT festzementiert!

Die ICT sind das Mittel der Wahl für Branchen mit hoher Informationsdichte und mit Bedarf für Koordination und Prozessoptimierung. Dieselben Kriterien treffen auf das Gesundheitswesen zu: Im Vordergrund stehen eine hohe Datendichte und eine schwer zu bewältigende Informationskomplexität; Medienbrüche, Redundanzen und ein massives Koordinationsdefizit tragen erheblich zum «Gesamtumsatz» von immerhin 50 Milliarden Schweizer Franken pro Jahr bei.

Gemeinsamkeiten von eHealth und eGovernment

Eine von allen Betroffenen mitgetragene Gesamtsicht und angemessene Entwicklungskapazitäten für die Planung und Umsetzung einer eHealth-Strategie sind die Voraussetzung für den Einsatz der ICT im Gesundheitswesen, aber auch für andere öffentliche Sektoren. Die ICT werden für

27

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

den Gesamtstaat zunehmend wichtig – zur Lösung komplexer Probleme; – um multiple Anspruchsgruppen anzusprechen; – um neue Dienstleistungsprozesse aufzubauen; – um neue Organisationsstrukturen zu entfalten; – für neue Strategien und Regulierungsaktivitäten.

strien von zentraler Bedeutung. Deshalb werden sowohl das Policy-Making als auch die Gesetzgebung im Standardisierungsbereich als vornehmliche Aufgabe der EU und ihrer Mitgliedstaaten anerkannt und gefördert [1].

Standardisierung als eGovernance-Aktivität

Diese permanente europäische Plattform soll dazu mandatiert werden (und dafür auch die notwendigen Ressourcen erhalten), die Interoperabilität von eHealth-Aktivitäten auf der Grundlage von Standards sowie die Koordination und Zusammenarbeit der europäischen Mitgliedstaaten zu fördern.

Dazu soll auch die Evaluation und Verbreitung von «good practice» samt Durchführung von Pilotprojekten gehören sowie die Förderung grenzüberschreitender Kommunikation zwischen beruflichen und Interessengruppen. Selbstverständlich gehören dazu auch die Schaffung der notwendigen rechtlichen und regulatorischen Rahmenbedingungen sowie die Entwicklung der notwendigen ICT-Architekturen. Diese übergeordnete, internationale Interoperabilitätsplattform soll die Koordinationsaktivitäten in Zusammenarbeit mit ebenfalls zu schaffenden nationalen Kompetenzzentren wahrnehmen.

Es reicht im Gesundheitswesen nicht aus, bestehende Prozesse auf der Ebene des elektronischen Datenaustausches technisch abzubilden. Am Beispiel der Standardisierung im Gesundheitswesen wird ersichtlich, dass es nicht um (vorhandene) technische Standards geht (siehe Artikel S. 32 in diesem Heft). Es geht um den Austausch verständlicher Information, um diese sinnvoll zu nutzen (semantische Interoperabilität), d.h. es geht darum, Konsensusprozesse zu ermöglichen.

Unter eGovernance verstehe ich den aktiven Einsatz von ICT zum Zwecke kollektiver Problemlösung für alle gesellschaftlichen Bereiche, in denen staatliche und nichtstaatliche Akteure zusammentreffen – zum gemeinsamen Nutzen aller Beteiligten. Zu den wichtigsten Funktionen der eGovernance gehören die «eRegulierung», das «ePolicy-making» und der Aufbau von «eService-delivery». eGovernance ist als übergeordnete Aufgabe zu verstehen, während eGovernment ein Teil davon ist.

Die ICT stellen letztlich Werkzeuge zur Verfügung, welche zum Transformationsprozess in verschiedenen gesellschaftlichen Bereichen beitragen – so auch im Gesundheitswesen. Deshalb könnte eine erweiterte Definition von eHealth lauten: «eHealth ist eGovernance im Gesundheitswesen».

eHealth und eGovernance in der EU Auch in der EU reicht das Verständnis für Fragen der eGovernance, Standardisierung und Interoperabilität über den Sektor Gesundheitswesen hinaus. Standards und Interoperabilität sind auch in anderen Indu-

28

Als vordringlichste eGovernance-Massnahme hat die eHealth Standardization Focus Group der Europäischen Kommission (siehe S. 32) die Schaffung einer europäischen Interoperabilitätsplattform empfohlen:

Und die Schweiz?

Die Schweiz braucht eine eGovernance für das Gesundheitswesen, welche eine eHealthStrategie, nationale und internationale Koordinationsaktivitäten sowie die Schaffung einer eHealth-Architektur beinhaltet.

Die Verfügbarkeit offener Standards ist eine essentielle Voraussetzung dafür. Ein erster Schritt in diese Richtung ist die in den zwei nachfolgenden Artikeln beschriebene Zusammenarbeit der SGMI mit der Fachgruppe eHealth des Vereins eCH und der europäischen CEN/ISSS eHealth Standardization Focus Group.

Referenz 1 http://europa.eu.int/comm/enterprise/ standards_policy/role_of_standardisation/ index.htm

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

Kooperation der SGMI mit der Fachgruppe eHealth des Vereins eCH und der europäischen CEN/ISS «eHealth Standardization Focus Group» Martin Denza, Marco Demarmelsb, Marc Colombc a

Leiter der Fachgruppe eHealth eCH und Präsident der SGMI

b

Mitglied der Fachgruppe eHealth eCH und der SGMI; Bereichsleiter Suva, Luzern

c

Mitglied der Fachgruppe eHealth eCH; Mitarbeiter der Firma Real-Time Center AG, Bern; Projektleiter für IT-Sicherheitsprojekte der Abteilung Sicherheit.

Die Schweizerische Gesellschaft für Medizinische Informatik und die Fachgruppe eHealth eCH fördern gemeinsam offene Standards und Interoperabilität zur erfolgreichen Integration der Informations- und Kommunikationstechnologien (IKT) ins Schweizer Gesundheitswesen, in engem Kontakt mit den führenden internationalen Standardisierungsexperten.

Was ist der Verein eCH? Der Verein eCH [1] fördert und verabschiedet eGovernment Standards in der Schweiz. eCH wurde 2003 als Initiative des Informatikstrategieorgans Bund (ISB) des eidgenössischen Finanzdepartements (EFD) gegründet. Vereinszweck ist die Erleichterung der elektronischen Zusammenarbeit zwischen Behörden und von Behörden mit Privaten, Unternehmen, Organisationen und Lehrund Forschungsanstalten, indem entsprechende Standards verabschiedet und koordiniert werden. Dies gilt für – einheitliche technologische Grundlagen; – die sichere Abwicklung von Transaktionen; – die reibungslose Abwicklung von Prozessen, Leistungs- und Zahlungsströmen zwischen allen Beteiligten.

Korrespondenz: Dr. med. Martin D. Denz Executive Master in eGovernance College of Management of Technology Swiss Federal Institute of Technology EPFL 1015 Lausanne E-Mail: martin.denz@epfl.ch

SMI 2005; No 55

eCH fördert die Umsetzung internationaler Standards und arbeitet mit anderen nationalen und internationalen Organisationen zusammen, welche sich um Standardisierungen im öffentlichen Sektor kümmern. Dazu gehört die Evaluation und im Ausnahmefall auch die Erarbeitung von Standards und Musterlösungen für eGovernment-Anwendungen. Die Ergebnisse haben den Charakter von Empfehlungen und werden auf der Webseite von eCH allen Interessenten kostenlos zur Verfügung gestellt.

In der eCH arbeiten Behördenvertreter mit Vertretern aus der Industrie, Lehre und Forschung und Verbänden nach dem Milizprinzip zusammen. Die Abläufe, die zur

Verabschiedung und Publikation von Dokumenten führen, sind den bewährten RFCProzessen der IETF [2] (Internet Engineering Task Force) nachempfunden und auf der Webseite von eCH dokumentiert. Die IETF mit ihrer freien Dokumentation aller Standards (RFCs) ist ein Vorbild für die eCH.

Ziele der Fachgruppe eHealth eCH Die Fachgruppe eHealth wurde im Sommer 2004 gegründet und wird von Martin Denz geleitet. Sie umfasst derzeit 20 aktive Mitglieder aus allen Berufs- und Fachbereichen.

Die Fachgruppe setzt damit die Standardisierungsaktivitäten im Schweizer Gesundheitswesen fort, welche in der Schweiz massgeblich von der SGMI aufgebaut wurden.

Viele Mitglieder der FG eHealth sind zugleich Mitglied der SGMI. Die Ziele der Fachgruppe eHealth sind 1. die Erfassung und Evaluation bestehender eHealth-Standards; 2. die Koordination mit den Standardisierungsaktivitäten im Ausland (EU und andere); 3. die Erfassung fehlender oder anzupassender Standards für die Schweiz; 4. falls nötig, die Anpassung bestehender Standards auf die Schweiz; 5. die Erarbeitung spezifischer CH-Standards im Rahmen der FG-Möglichkeiten; 6. als Plattform zum Informations- und Erfahrungsaustausch zu dienen.

Welche Standardisierungsaktivitäten kann eine im Milizsystem organisierte Fachgruppe mit beschränkten Ressourcen überhaupt wahrnehmen? Sie kann – selber Standards entwickeln (auf technischer Ebene); – aufgrund vorhandener Fachkompetenz Standards empfehlen und fördern; – sich auf übergeordneter, nationaler (und

29

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

internationaler) Ebene dafür einsetzen, dass Standards für das Gesundheitswesen frei verfügbar und somit genutzt werden können.

Die Fachgruppe konzentriert sich auf die beiden letztgenannten Punkte, technische Entwicklungsarbeit kann und soll nur in Ausnahmefällen angestrebt werden. Eine wichtige öffentliche Aufgabe bildet die Sicherstellung des freien Zugangs bzw. die Ermöglichung offener Standards (siehe Artikel S. 32 in diesem Heft). Allenfalls müssen Wege für die Regelung dieser ordnungspolitischen Frage gefunden werden; falls nötig durch ein staatliches finanzielles Engagement bzw. die Schaffung gesetzlicher Grundlagen zur öffentlichen Nutzung von Standards zu Gunsten des Gesundheitswesens.

eHealth-Standards als gemeinsames Thema mit Europa Gemäss den oben erwähnten Zielen steht die Fachgruppe eHealth eCH in direktem Kontakt mit der CEN/ISS «eHealth Standardization Focus Group» (siehe weiter unten). Auch wenn die Schweiz nicht Mitglied der EU ist, so ist es nicht möglich, sich gegenüber den Aktivitäten des uns umgebenden Auslands zu verschliessen: Auf der Grundlage der Lissabonner Strategie der EU vom März 2000 wurden die Aktionspläne «eEurope 2002» und «eEurope 2005» lanciert [3]. Ziel dieser Aktionspläne ist, jedem Bürger die Möglichkeit zu geben, sich an der globalen Informationsgesellschaft zu beteiligen. Dafür wurden Anreize geschaffen für privatwirtschaftliche Investitionen sowie günstige Rahmenbedingungen für die Modernisierung der öffentlichen Dienste. Auf dem Weg zu einer wissensbasierten Wirtschaft wird bis zum Jahr 2010 eine europäische «eHealth-Industrie» als Teil des Gesundheitswesens entstehen. Mindestens 5% aller im Gesundheitswesen getätigten Investitionen sollen für eHealth-Aktivitäten eingesetzt werden.

Damit will die europäische Gemeinschaft folgende langfristigen Ziele erreichen: – Aufrechterhaltung eines für alle tragbaren Gesundheitswesens;

30

– Abbau von Fehlern und Verbesserung der Sicherheit beim Erbringen von Gesundheitsdienstleistungen; – Förderung von gesichertem und autorisiertem Zugriff auf relevante Patienteninformationen und -Dokumentationen; jederzeit, überall!

– Unterstützung mobiler Bürger bei der Suche nach qualitativ hochwertigen Gesundheitsdienstleistungen in ganz Europa.

Obwohl eHealth als Teil einer Gesamtstrategie zum Aufbau der Informationsgesellschaft in der EU zu verstehen ist, hat eHealth im Vergleich zu den anderen gesellschaftlichen Schwerpunkten eine überdurchschnittliche Dynamik entwickelt, wurde wiederholt von allen Gesundheitsministern der EU zur «Chefsache» deklariert [4, 5]. Die Europäische Kommission hat eine eHealth-Roadmap verabschiedet, welche derzeit implementiert wird (e-Health – making healthcare better for European citizens: An action plan for a European e-Health Area [6]).

Auf diesem Hintergrund haben die Förderung und der Einsatz von elektronischen Standards im Gesundheitswesen für die europäischen Gesundheitsminister allerhöchste Priorität. Insbesondere der Interoperabilität wird eine zentrale Bedeutung eingeräumt. Auf Wunsch der Europäischen Kommission wurden das International Swedish Standards Institute [7] (ISSS) und das Europäische Komitee für Standardisierung [8] (CEN) bzw. deren Spezialisten für Gesundheitsinformatik [9] damit beauftragt, die EU zu unterstützen.

CEN/ISSS eHealth Standardization Focus Group Ende 2003 wurde die «eHealth Standardization Focus Group» gegründet, welche unter der Leitung von Professor Bernd Blobel, Fraunhofer Institut Erlangen, für die Europäische Kommission einen Report und Empfehlungen erarbeitete. Dieser offenen Arbeitsgruppe gehören die weltbesten Spezialisten in Sachen Standards und Interoperabilität im Gesundheitswesen an. Im Februar 2005 wurde der «Final Report» verabschiedet, zu dessen Entstehung auch die Fachgruppe eHealth eCH und die Schwei-

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

zerische Gesellschaft für Medizinische Informatik SGMI beigetragen haben: «Current and future standardization issues in the eHealth domain: Achieving interoperability» [10]. Die darin enthaltenen Elemente können auch als Grundlage einer eHealthRahmenarchitektur dargestellt werden (Abb. 1):

Referenz 1 http://www.ech.ch/ 2 http://www.ietf.org/ 3 http://europa.eu.int/information_society/ eeurope/2005/index_en.htm 4 http://europa.eu.int/information_society/ eeurope/2005/all_about/ehealth/ index_en.htm 5 http://www.ehealth2005.no/ cparticle249437-.html 6 Communication of the Commission of the EU: COM (2004) 356, 30.04.2004 7 http://www.sis.se 8 http://www.cenorm.be/ 9 http://www.centc251.org/ 10 http://www.centc251.org/ ehealthfocusgroup.htm

Abbildung 1. CEN/ISSS-Standard-Rahmenwerk.

Schlussfolgerungen Standardisierungsaktivitäten müssen über technische Ansätze hinausgehen: Technische Standards sind für das Gesundheitswesen vorhanden, was jedoch fehlt, ist deren Interoperabilität. Standards können nur dann erfolgreich genutzt werden, wenn ein Wille zur Kooperation vorhanden ist. Dazu gehören auch Kontakte zur EU, denn das Schweizer Gesundheitswesen wird künftige Herausforderungen nicht vom Ausland losgelöst bewältigen können.

Die Autoren danken Herrn Prof. Bernd Blobel vom Fraunhofer Institut Erlangen und Herrn Johan Beun von NICTIZ für ihre freundliche Unterstützung!

SMI 2005; No 55

31

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

Die Schweizer Versichertenkarte im Spannungsfeld internationaler Standards Marc Colomba, Beat Arnetb, Martin Denzc a

Mitglied der Fachgruppe eHealth eCH, Mitarbeiter der Firma Real-Time Center AG, Bern, Projektleiter für IT-Sicherheitsprojekte der Abteilung Sicherheit

b

Mitglied der Fachgruppe eHealth eCH und der SGMI, Bereichsleiter Suva, Luzern

c

Leiter der Fachgruppe eHealth eCH und Präsident der SGMI

Probleme des Gesundheitswesens Am Beispiel der Schweizer Versichertenkarte werden die Bedeutung internationaler Koordinationsaktivitäten und offene Standards als unerlässliche Voraussetzung erkennbar.

Das Gesundheitswesen ist aufgrund seiner inhaltlichen Komplexität eine der schwierigsten und in bezug auf die versammelten Akteure eine der heterogensten «Industrien» überhaupt. Dies gilt natürlich nicht nur für das schweizerische Gesundheitswesen, sondern auch für alle Gesundheitswesen innerhalb und ausserhalb der EU. Ein Hauptproblem im föderalistischen Schweizer Gesundheitswesen ist das Fehlen einer allseits verbindlichen Koordination und einer problemgerechten Kompetenzregelung: – uneinheitliche Gesetzes-, Verordnungs-, Vertrags- und Normensituation; – inkonsistente Informationsketten, redundante Datenerfassung und -Haltung; – heterogener Informatisierungsstand bei fehlenden finanziellen Anreizen; – unkoordinierte Aktivitäten aller Akteure und Interessenvertreter; – fehlen von Gesamtkonzepten und integrativen Querschnittsfunktionen.

Korrespondenz: Dr. med. Martin D. Denz Executive Master in eGovernance College of Management of Technology Swiss Federal Institute of Technology EPFL 1015 Lausanne E-Mail: martin.denz@epfl.ch

32

Thematik, welche jetzt aufgrund jüngster gesetzlicher Regelungen (KVG Art. 42a) Gestalt annimmt. Unter dem Begriff der «Versichertenkarte» versteht man – ohne dabei den gesetzlich vorgegebenen Rahmen zu verlassen – unterschiedliche (evolutionäre) Ausprägungen.

Das Bundesamt für Gesundheit definiert in seinem aktuellen Bericht folgende Kartentypen: – Versichertenkarte mit administrativen Daten; – Versichertenkarte mit zusätzlichen Notfalldaten; – Gesundheitskarte als Sicherheitsschlüssel zum elektronischen Patientendossier.

Auf der Grundlage dieser Kartentypen wurden verschiedene Modellvarianten ausgearbeitet: Modell A entspricht der europäischen Krankenversicherungskarte ab 2006 und trägt eine Sozialversicherungsnummer.

Sie ist eine reine Trägerkarte für die fünf europäischen Versicherungsformulare (E111 bis E128).

Modell B ist eine Erweiterung von Modell A mit zusätzlichen Notfalldaten. Sie ist ebenfalls eine reine Speicherkarte und verfügt über einen PIN-geschützten Datenbereich.

Es fehlt eine von allen Akteuren des Gesundheitswesens anerkannte und fachlich qualifizierte Organisation mit regulatorischen Kompetenzen. Dies ist eine wesentliche Voraussetzung, um den Aufbau durchgängiger, nationaler und internationaler Informations- und Kommunikationsprozesse rasch und zielgerichtet zu realisieren.

Erst dadurch werden der notwendige branchenweite Ansatz und die dazugehörigen normativen Gefässe möglich.

Modell C umfasst die Modelle A und B sowie zusätzliche administrative und persönliche Daten, welche nur durch Fachpersonal bewirtschaftet werden. Der Zugriff ist via PIN-Eingabe durch den Versicherten plus Authentisierung via Health Professional Card (HPC) der Fachperson möglich. Der Versicherte besitzt eine Speicherkarte. Die HPC ist eine Cryptokarte und muss die Vorgaben des Bundesgesetzes über die digitale Signatur erfüllen.

Von der Versichertenzur Gesundheitskarte

Modell C+ entspricht Modell C, wobei hier beide, sowohl der Versicherte als auch die Fachperson, über Cryptokarten verfügen.

Diese Variante würde die Position des Versicherten wesentlich stärken. Als Basisbau-

Die Schweizerische Versichertenkarte ist eine bereits über längere Zeit diskutierte

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

stein einer gesundheitstelematischen Gesamtarchitektur würde eine derartige «Access Card» im wörtlichen und im übertragenen Sinne zum Schlüssel für die sichere Nutzung des elektronischen Patientendossiers.

Es ist allen beteiligten Experten und Interessengruppen klar, dass sämtliche technischen Aspekte des elektronischen Datentransfers, der Verarbeitung und der Speicherung von Personen- bzw. Patientendaten, den Vorgaben der Datenschutz- und Datensicherheitsregeln entsprechen müssen. Es geht hier letztlich um das Identity- und Trust-Management aller Bürgerinnen und Bürger – ob gesund oder krank. Angesprochen werden das Recht auf informationelle Selbstbestimmung («Empowerment»), die Transparenz bei der Einführung und Anwendung von Karten, sowie der Einsatz adäquater, modernster Technologien im Bereich des Datenschutzes, unter Verwendung modernster Chiffrierverfahren.

Ziele der Kartenlösungen Die Möglichkeiten einer Kartenlösung, auch diejenigen der für die Zukunft angestrebten Gesundheitskarte, dürfen nicht überschätzt werden. Eine Karte ist lediglich als Träger bestimmter Funktionen zu verstehen. In Zukunft wird es auch andere Trägervarianten geben.

Um die einleitend aufgezeigten Probleme im Gesundheitswesen angehen und lösen zu können, strebt man mit der Versichertenkarte gemäss KVG Art. 42a u.a. folgende Ziele an: – administrative Vereinfachungen; – schnellere Rechnungsstellung; – Kostensteuerung inkl. Redundanzabbau; – Sicherheit von Behandlung und Pflege; – nationale und internationale Kompatibilität.

Zur Erfüllung dieser Ziele ist die Versichertenkarte eine wichtige Voraussetzung. Sie ist sicher kein Allheilmittel, aber der Eckstein zum übergeordneten Zusammenspiel von technischen Bausteinen und dem Willen aller Beteiligten, miteinander zu kommunizieren und zu kooperieren. Einzig eine Gesundheitskarte gewährleistet den Versicherten, Patienten oder Health Professionals einen sicheren Zugang zu den verschie-

SMI 2005; No 55

densten Informationen innerhalb der vernetzen Welt von Organisationen und Strukturen im Gesundheitswesen. Sie ist im konkreten und übertragenen Sinne der Schlüssel zum Gebäude «Informations- und Servicewelt Gesundheitswesen». Dieses Gebäude besteht aus einer Vielzahl zum Teil noch zu erstellender Räumlichkeiten samt abzubauenden Inkonsistenzen, wobei in der Schweiz derzeit noch keine Vorstellung über dessen Gesamtarchitektur besteht. Das Zusammenspiel der Gesundheitskarte mit einer Health Professional Card ist zu vergleichen mit dem bekannten Konzept von zwei Schlüsseln, die zum Sichern und Öffnen eines Banksafes nötig sind.

Der Schweiz eröffnet sich die Chance, die Synergien dank internationaler Kompatibilität und Interoperabilität auf der Karten-, Informations- und Serviceebene zu nutzen. Dies hängt mit dem Bedarf nach grenzüberschreitenden Lösungen zusammen, welche sich aus der zunehmenden Mobilität aller Bürgerinnen und Bürger ergibt. Die Versicherten und Health Professionals begeben sich öfter denn je in die EU und von der EU in die Schweiz. Dies führt zu neuen rechtlichen, organisatorischen und praktischen Anforderungen. Die Informations- und Kommunikationstechnologien stellen viele Lösungsvarianten bereit. Die Berücksichtigung und Harmonisierung international anerkannter technischer Standards ist deshalb eine unabdingbare Voraussetzung für die Zukunftstauglichkeit aller Gesundheitssysteme, aber auch für den Wirtschaftsstandort Schweiz.

Von Europa lernen Das Hauptziel der «eEurope-Aktionspläne»1 und der daraus abgeleiteten eHealth-Roadmap (siehe Artikel S. 29 in diesem Heft), ist die Entwicklung einer benutzerfreundlichen, validierten und vor allem interoperablen Infrastruktur im Dienste des Gesundheitswesens. Als erste praktische Lösungsansätze im Bereich des Gesundheitswesens, also für «eHealth», sind vorgesehen: – die elektronische Gesundheitskarte; – Gesundheitsversorgungsnetze; – Online-Gesundheitsdienste.

Wie in der Schweiz, so sind auch im europäischen Raum zwar viele dafür not-

33

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

wendige infrastrukturelle Bausteine bereits vorhanden. Allerdings reicht das blosse Vorhandensein von Technologie nicht aus, um die bereits genannten Problempunkte wie Inkonsistenz und Heterogenität zu lösen – es braucht den Einbezug in eine Gesamtarchitektur und den politischen Willen der beteiligten Akteure, zusammenarbeiten zu wollen. Die verantwortlichen Entscheidungsträger der EU haben erkannt, dass eine erhöhte Kohärenz der beteiligten Systeme und Akteure im Gesundheitswesen nur durch die Förderung von Standards und insbesondere deren Interoperabilität zu erreichen sein wird.

Die Empfehlungen der CEN/ISSS eHealth Standardization Focus Group zu Handen der EU umfassen Standards für die Unterstützung klinischer und administrativer Prozesse mittels standardisierter Informationsstrukturen, technische Methodologien zur Unterstützung interoperabler Systeme sowie Sicherheits- und Qualitätsstandards (siehe Abb. 1 «Standard Rahmenwerk» auf der Seite 31 in diesem Heft).

Die Empfehlungen der eHealth Standardization Focus Group beinhalten unter anderem: – besseren und sicheren Zugang zum elektronischen Patientendossier;

ENV 1387:1996

Machine readable cards – Health care applications – Cards: General characteristics

ENV 1867:1997

Machine readable cards – Health care applications – Numbering system and registration procedure for issuer identifiers

ENV 12018:1997

Health Informatics – Identification, administrative and common clinical data structure for Intermittently Connected Devices used in health care (including machine readable cards)

ENV 13735:2000

Health Informatics – Interoperability of patient connected medical device

ISO WD 20301:2001

Health Informatics – Health cards – general characteristics

ISO WD 20302:2001

Health Informatics – Health cards – numbering system and registration procedure for issuer identifiers

ISO 21549–1:2004

Health Informatics – Patient health card data – Part 1: General structure

ISO 21549–2:2004

Health Informatics – Patient health card data – Part 2: Common objects

ISO 21549–3:2004

Health Informatics – Patient health card data – Part 3: Limited clinical data

ISO WD 21549–7

Health Informatics – Patient health card data – Part 7: Electronic prescription

ISO PWI 21549–8

Health Informatics – Patient health card data – Part 8: Links

Tabelle 1: Karten-Standards nach CEN/ISSS.

34

– offene Verfügbarkeit von für das Gesundheitswesen relevanten Standards; – höchste politische Unterstützung von Standardisierung und Interoperabilität; – generelle Einführung von EU-weit interoperablen Gesundheitskarten.

Beispiel Karten-Standards In Zukunft werden medizinische Daten in einem elektronischen Patientendossier (zentral, dezentral oder virtuell) abgelegt sein.

Der Zugriff auf diese Daten wird mittels digitaler Verschlüsselungstechnologien gesichert sein. Der Zugriff durch den Dateneigentümer bzw. die Datenbearbeitung durch die von ihm bevollmächtigten Health Professionals wird mittels elektronischer «Access Cards» gesichert sein. Vor dem entscheidenden Schritt in Richtung Gesundheitskarte sieht die Schweiz als Versicherungsnachweis einen auf vorhandene Karten aufklebbaren Sticker vor, der später durch eine elektronische Lösung abgelöst werden kann.

Die bisherigen Erfahrungen mit den Gesundheitskartenprojekten im europäischen Raum haben gezeigt, dass das Konzept einer Europäischen Versichertenkarte als «Enabler» für die Einführung weiter entwickelter Karten (eigentliche «Gesundheitskarten») nur dann erfolgreich sein kann, wenn jegliche Karteneinführung auf dem Hintergrund einer nationalen eHealth-Strategie erfolgt, in deren Rahmen eine eHealth-Rahmenarchitektur definiert sein muss. Es besteht Einigkeit darüber, dass diese Architekturen jeweils von einem nationalen Kompetenzzentrum entworfen und koordiniert werden müssen, das auch für den Themenbereich Standards und Interoperabilität zuständig ist.

Es wird bereits jetzt deutlich, dass die nationalen elektronischen Kartensysteme in der EU die Funktion einer «European Health Insurance Card» (EHIC) nicht erfüllen werden, weil sie aufgrund proprietärer Standards untereinander inkompatibel sind.

Dies wiederum bestätigt, dass die von der EU mit Nachdruck vorangetriebenen Aktivitäten im Bereiche Standardisierung und Interoperabilität von essentieller strategischer Bedeutung sind. Der Schweiz bietet sich somit die Chance, aus den Erfahrungen ihrer Nachbarstaaten zu lernen: statt diesel-

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

ben Fehler zu wiederholen, können und müssen wir unsere Aktivitäten an den bereits vorhandenen Standards ausrichten.

Wir müssen uns aber auch bewusst sein, dass Standards allein nicht ausreichen, wenn nicht auch deren Interoperabilität gewährleistet ist.

In Tabelle 1 sind die Standards, welche von der CEN/ISSS eHealth Standardization Focus Group für Kartenlösungen im Gesundheitswesen (Patients’ and Professionals’ Cards) identifiziert wurden, aufgeführt.

Zugang zu Standards Es empfiehlt sich aus Gründen der medizinischen Qualität, der ökonomischen Effizienz und für die Sicherheit aller Bürger und Patienten, den Vorschlägen der CEN/ISSS eHealth Standardization Focus Group zu folgen. Dadurch kann ein Maximum an Interoperabiliät und Kompatibilität auf allen Ebenen im Gesundheitswesen erreicht werden.

Der Zugang zu Standardisierungswerken ist heute erschwert und bedarf einer grundlegenden Erneuerung, kommerzielle Schranken und Zugangsregelungen bedürfen einer dringenden Revision. Nicht nur die Vielzahl unterschiedlichster Standardisierungsgremien schreckt viele potentielle Nutzer ab, Standardisierungswerke zu konsultieren.

Betrachtet man den Umfang der durch die eHealth Standardization Focus Group zusammengetragenen Standards, kommt man auf mehr als 300 Einzelwerke aus unterschiedlichsten Quellen.

Der Zugang zu diesen Standards, ja schon nur die Einsichtnahme ohne kommerzielle Weiterverwendung, ist grösstenteils kostenpflichtig! Die Beschaffung eines kompletten Satzes der für eHealth relevanten Standards entspricht (abgesehen vom Zeitaufwand für die umfangreichen Recherchen) einem Kostenaufwand von CHF 30 000 bis 40 000. Es ist unverständlich, ökonomisch kontraproduktiv und ethisch fragwürdig, wenn potentiellen Nutzern ausgerechnet in einem lebenswichtigen Infrastrukturbereich wie dem Gesundheitswesens derartige Barrieren in den Weg gestellt werden. Es geht hier um weit mehr als um Lizenzfragen – es geht um eine Rechtsgüterabwägung

SMI 2005; No 55

zwischen öffentlichem Interesse und kommerziellen Geschäftsmodellen: erschwerter Zugang zu Standards oder die Vorenthaltung von gesundheitsrelevantem Wissen und Lösungen behindert nicht nur Qualitäts- und Effizienzsteigerungsmassnahmen, ungünstigstenfalls kann dies Menschenleben kosten.

Als Alternativbeispiel kann hierzu die vorbildliche Haltung der Begründer des Internets (IETF) mit ihren «Requests for Comments» (RFC) aufgeführt werden: Die RFC können kostenlos, mittels Eingabe der RFC-Nummer von der entsprechenden Website, heruntergeladen werden. Die rasante Verbreitung des Internets begründet sich nicht zuletzt dadurch, dass die beteiligten Kreise offen im Umgang mit «Technologiewissen» sind, das interdisziplinär zur Anwendung kommt. Weshalb soll sich eine Werthaltung, die sich günstig auf die Entwicklung von Bildung, Forschung und Industrie ausgewirkt hat, im Sinne des gesamtgesellschaftlichen Nutzens nicht auch auf das Gesundheitswesen anwenden lassen?

Schlussfolgerungen Das Schweizerische Gesundheitswesen ist für die Umsetzung künftiger Kartenlösungen auf international anerkannte Standards angewiesen. Die dafür notwendigen Standards müssen nicht neu erfunden werden – es gibt sie bereits. Der durch die CEN/ISSS e-Health Standardization Focus Group vorgelegte Report ist ein wichtiger Wegweiser hierzu. Protektionismus oder ökonomische Hindernisse erschweren unnötigerweise den Zugang zu Standards und behindern die Entwicklung eines modernen Gesundheitswesens. Es besteht ein dringender Klärungsund Handlungsbedarf zur Förderung offener eHealth-Standards.

Referenz 1 http://europa.eu.int/information_society/ eeurope/2005/index_en.htm

35

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

HL7 – Arbeiten am offenen Standard Bericht vom HL7-Working-Group-Meeting im Januar 2005

Beat Heggli Präsident HL7 Schweiz, ISOFT Switzerland GmbH

Das erste Arbeitsgruppen-Meeting von HL7 in diesem Jahr fand vom 23.–28. Januar 2005 in Orlando, Florida statt. Die Rekordbeteiligung von über 400 Teilnehmern war sicher auch auf den attraktiven Tagungsort nahe Disney Downtown zurückzuführen, obwohl das nasskalte Wetter eher zum Verbleib im Hotel und den Tagungsräumen als in den Vergnügungsparks verlockte.

Die aktive Mitarbeit in den Arbeitsgruppen ist, wie alle Arbeit bei HL7, freiwillig, und die Diskussionen und Gespräche über Neuerungen und Implementierungen dauern meistens über die normalen Tagungszeiten hinaus und werden in der Hotellobby oder beim Nachtessen fortgesetzt.

Dreimal jährlich, im Januar, Mai und September, finden diese Tagungen statt. Hier werden die Vorschläge für die Erweiterung des Standards diskutiert und die Resultate der Abstimmungen (Ballots) konsolidiert.

Zwischen den Meetings kommunizieren die Arbeitsgruppen-Mitglieder über List-Servers und Telefonkonferenzen.

Der Sonntag

Beat Heggli ISOFT Switzerland GmbH Manager system integration Sonnenbergstrasse 72 CH-8603 Schwerzenbach E-Mail: beat.heggli@isoft.ch

36

Das «Working Group Meeting» (WGM) dauert 6 Tage, der Sonntag ist jeweils für das International Affiliates Meeting reserviert, hier treffen sich die Delegierten aller Länder. 27 nationale HL7-Organisationen ausserhalb der USA repräsentieren den Standard im jeweiligen Land und dokumentieren klar, dass weltweites Interesse vorhanden ist und dieser Standard ein internationaler Standard ist. 70 Teilnehmer aus 15 Mitgliedsstaaten waren diesmal vertreten und berichteten über nationale und internationale Arbeiten. Neben den nationalen HL7-Organisationen in Europa, wie England, Irland, Deutschland, Frankreich, Schweiz, sind Länder aus allen anderen Kontinenten Mitglieder. Dass die politischen Grenzen dabei übersprungen werden, ist fast selbstverständlich. So führen China und Taiwan gemeinsame Tagungen durch, und HL7-Argentinien bereitet eine Schu-

lung in Kuba vor. Der Antrag für die Aufnahme von Bulgarien als internationales HL7-Mitglied wurde im Rahmen des Internationalen Meetings gutgeheissen und ans HL7-Board weitergeleitet.

Von Montag bis Freitag HL7 ist eine ANSI akkreditierte «Standard Development Organization» (SDO) und folgt deren Regeln für die Definition des Standards. Unter anderem wird darin auch verlangt, dass die WGM’s und Sitzungen der Komitees für alle offen sind, «ANSIStandard openness». Es ist für Interessengruppen also durchaus möglich, ihre Wünsche und Anforderungen auch als nicht HL7-Mitglied in den Standard einzubringen.

Die Komitees und Special Interest Groups (SIG) sind die Kernzellen der HL7-Arbeit. Über 30 Arbeitsgruppen sind es unterdessen und das Spektrum umfasst: – Clinical Genomics – Electronic Health Record – Financial Management – Imaging Integration – Laboratory – Laboratory, Automated and Point of Care Testing – Medical Records – Orders/Observation – Patient Administration – Patient Care / Patient Safety – Personnel Management – Pharmacy – Scheduling and Logistics Daneben gibt es noch eine Reihe von Arbeitsgruppen, die sich mit technischen Grundlagen beschäftigen wie XML, Java, Conformance, Control/Query.

Für die Organisation von Schulungen und Schulungsunterlagen ist das Educating/Implementation Komitee zuständig. Die Arbeiten von ORC und PIC, zwei Komitees, die sich mit der internen Organisation von HL7 beschäftigen, bilden die Grundlagen für verbesserte Prozesse und eine schlankere Struktur des Gremiums. Lag

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

in den 90er Jahren noch das Hauptinteresse in den «klassischen» Arbeitsbereichen Patient Adminstration, Financial Management usw., so ist seit 2000 ein Trend zu den «medizinischen» Bereichen festzustellen. Das Komitee für «EHR» führte an diesem WGM Sitzungen mit über 80 Teilnehmern durch.

Zwei Versionen von HL7 werden aktuell bearbeitet und bildeten die Schwerpunkte der Arbeit in den Komitees und SIG’s am WGM: Version 2 1988 wurde Version 2.1 publiziert, mit der bekannten «Vertical-Bar-Syntax». In der Folge wurde ca. alle zwei Jahre eine neue Version veröffentlicht. Version 2 basiert auf folgenden Komponenten: Ereignis (Event), Meldungstyp, Segment, Feld, wobei der Meldungstyp durch das Ereignis definiert wird. Der Inhalt eines Feldes wird durch seine Position innerhalb des Segmentes definiert. Da eine Rückwärtskompatibilität innerhalb der Version 2 gewährleistet werden muss, somit Segmente in der Meldung nicht einfach weggelassen und neue Felder immer nur am Schluss eines Segmentes angefügt werden können, nimmt die Zahl der Ereignisse/Meldungstypen von Version zu Version zu. Auch beim kleinsten Baustein einer Meldung, dem Feld und dem zugeordneten Datentyp ist durch die Jahre eine Zunahme von Typen, wieder unter Berücksichtigung der Rückwärtskompatibilität, zu beobachten.

Im Dezember 2004 wurde der Entwurf für Version 2.6 publiziert und darüber abgestimmt. Die Resultate dieser Abstimmung standen dann nun im Meeting in Orlando zur Diskussion, die Entwürfe wurden überarbeitet und stehen im April zu einer weiteren Abstimmungsrunde bereit. Dass die Version 2 auch weiterhin ihre Daseinsberechtigung hat, zeigt die Tatsache, dass in dieser Version zwei neue Kapitel eingefügt wurden. Kapitel 16, Claims and Reimbursement, definiert den Austausch von Rechnungs- und Kostengutsprache-Information, Kapitel 17, Material Management, beinhaltet den Austausch von Stammdaten im Bereich Materialwirtschaft und Medikamente. Und gemäss Entscheid des Technical Steering Komitees wird auch noch eine Version 2.7 vorbereitet.

SMI 2005; No 55

Version 3 Bereits 1996 wurde das Konzept für Version 3 vorgestellt, im folgenden Jahr dann der Entwurf des RIM (Reference Integration Model) und die Methodologie. Das Vocabulary Technical Committee definierte die Basisklassen im RIM: – act – entity – role – participation – Act_Relationship – Role_Link Eine verfeinerte Version des RIM für die jeweilige Domäne, das D-MIM, beinhaltet alle Klassen, die zur Erstellung von Meldungen der jeweiligen Domäne nötig sind.

Die Publikation von RIM Version 1.0 erfolgte 2001 und 2003 wurde das RIM als Standard anerkannt, ebenso die «principles of extensibility and localization».

Das RIM und das Message Developement Framework (MDF) von HL7 finden auch Eingang in die ISO/TC215-Aktivitäten.

Die Meldungen gemäss Version 3 Standard werden in Form von XML-Files übermittelt.

Die Unterschiede von Version 2 und 3 sind markant und die Erfahrungen zeigen, dass praktisch keine bestehenden Installationen von Version 2 durch Version-3-Implementationen ersetzt werden. Version 3 wird dann eingesetzt, wenn neue Anforderungen vorhanden sind und ein Re-Design notwendig machen.

HL7, ein internationaler Standard Während die Version 2 des Standards klar von den USA aus forciert wurde, so stehen hinter Version 3 die internationalen Mitglieder als treibende Kraft.

– Kanada führte als erstes Land eine V3Implementation als Standard ein. In der NeCST-Inititative werden Kostengutsprache, Kostenübernahme für Hilfsmittel, Rechnung sowie Rechnungs- und Zahlungsstatus als V3-Meldungen übermittelt.

– In England ist HL7-Version 3 als Kommunikationsstandard im NHS Pflicht.

– Mexiko führt gemeinsam mit den grös-

37

SGMI SSIM SSMI

Swiss Medical Informatics Open Standards

sten Vorsorge-Einrichtungen und Labors Meldungen für Laborauftrag und Resultat in HL7-Version 3 ein.

Weitere Treffen Im Mai hat das erste WGM ausserhalb von Nordamerika seit der Gründung von HL7 stattgefunden. Im niederländischen Noordwijkerhout trafen sich die Arbeitsgruppen vom 1.–6. Mai 2005. Nähere Informationen unter www.wgm2005.nl oder www. hl7.org/events/netherlands052005. Neben den Arbeitsgruppen-Meetings wurden auch eine Reihe von Tutorials über Version 2 und 3 sowie XML und den HL7-Tools angeboten.

Die Benutzergruppe HL7-Schweiz www.hl7.ch wird ihre Jahresversammlung am 19.10.2005 durchführen. In der selben Woche werden auch Schulungen von HL7-CH gemeinsam mit Kollegen von HL7-Deutschland stattfinden.

38

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Access

Freier Zugang zu wissenschaftlicher Information Ein Überblick über die Open Archives Initiative und die Open Access Initiative

Ingeborg Zimmermann

Beide Initiativen repräsentieren zwei Seiten ein- und derselben Forderung: offener Zugang zu wissenschaftlicher Information.

Die zentralen Ideen beider Initiativen sind bestimmt von drei Entwicklungen aus den frühen 90er Jahren: 1. Die Wurzeln der Open Archives Initiative liegen in den E-Print-Archiven oder Repositories wie ArXiv oder CogPrint.

E-Print Repositories dienten dem Zugang zu neuesten Forschungsergebnissen, bevor diese den Peer-review-Prozess durchlaufen haben und/oder in einer wissenschaftlichen Zeitschrift veröffentlicht worden sind. Sie sichern den Zugang zu Ergebnissen schnell und ohne Beschränkungen. Problematisch war einzig die Tatsache, dass jedes Archiv eine eigene Suchoberfläche hatte, verschiedene Protokolle benutzte und die Daten nicht ohne weiteres austauschbar waren.

2. Mit der Öffnung des Internets entstanden staatlich geförderte Forschungsinitiativen, die einerseits Förderprogramme zur Entwicklung von digitalisierten Bibliotheken erarbeiteten, und andererseits innovative Ideen für die schnelle Verbreitung von Inhalten und neuen Informationsformen.

Die Bedeutung der Interoperabilität im technischen, formalen und organisatorischen Sinn und die Bedeutung von Standardisierungen bei Formaten, Metadaten und Datenaustausch- und Transportprotokollen wurde schnell offensichtlich.

Kontaktadresse: Ingeborg Zimmermann Hauptbibliothek Universität Zürich Forschungsbibliothek Irchel Winterthurerstrasse 190 CH-8057 Zürich E-mail: ingeborg.zimmermann@hbz.unizh.ch

SMI 2005; No 55

3. Autoren wissenschaftlicher Veröffentlichungen äusserten zunehmend ihre Unzufriedenheit mit der zeitlichen Verzögerung zwischen Abgabe eines eingereichten Artikels und dessen Veröffentlichung. Bislang übertrugen darüber hinaus die meisten Wissenschaftler die Autoren- und Verwertungsrechte an ihren Arbeiten unbefristet und exklusiv an einen kommerziellen Verlag.

Angesichts kontinuierlich enorm steigender Zeitschriftenpreise sahen sich viele Bibliotheken gezwungen, in grossem Umfang

Abonnements abzustellen. Die Publikations- und Preispolitik der Verlage führte also in doppelter Hinsicht zu einer Einschränkung in der Verbreitung von Forschungsergebnissen.

Open Archives – die technische Seite Paul Ginsparg (Physiker am Los Alamos National Laboratory und 1991 Gründer das Los Alamos National Laboratory Preprint Servers), Rick Luce (Bibliotheksdirektor der Forschungsbibliothek Los Alamos) und Herbert van de Sompel traten im Juli 1999 an die Öffentlichkeit mit einem Call for participation in the UPS (Universal Preprint Service) initiative aimed at the further promotion of author self-archived solutions.

26 Wissenschaftler, Informatiker und Bibliothekare folgten diesem Aufruf, kamen am 21. und 22. Oktober 1999 in Santa Fe, New Mexico, zusammen und verabschiedeten die Santa Fe Convention.

Zum Zweck der allgemeinen Kommunikation zwischen Pre-Print und E-Print-Servern sollte – ein gemeinsamer Satz von Metadaten erstellt werden; – ein Navigationsprotokoll entwickelt werden auf der Basis eines Dienstprotokolls, das mittels des Metadatensatzes die wichtigsten Informationen aus den Servern einsammelt und für eine Recherche in einem Harvesterindex zusammenstellt.

Im Verlauf der Arbeiten an diesen beiden Zielen entwickelte sich der Name

Open Archives Initiative (OAI) Die Organisation OAI Das Steering Committee besteht aus 12 Vertretern wissenschaftlicher Einrichtungen, wissenschaftlicher Bibliotheken, Fachgesellschaften, Forschungseinrichtungen und wis-

39

SGMI SSIM SSMI

Swiss Medical Informatics Open Access

senschaftlicher E-Print-Server und ist zuständig für die richtungsweisende Diskussion und Promotion. Das OAI Technical Committee ist zuständig für Evaluierung und Weiterentwicklung der OAI-Architektur, und das OAI Executive Committee koordiniert die weltweiten Aktivitäten. Die Finanzierung erfolgt durch die Digital Library Federation (DLF), Coalition for Networked Information (CNI) und die National Science Foundation (NSF) Strukturen und Begriffe Open bezieht sich auf die technische Architektur; die Protokollspezifikation ist für jeden zugänglich; OAI-kompatible Server sind offen in dem Sinn, dass sie die wichtigsten Informationen über die Inhalte der darin gespeicherten Dokumente durch standardisierte Metadatenformate für den Harvester zur Verfügung stellen.

Archives – auch Repositories genannt, steht für einen Webserver, der für die Speicherung und dauerhafte Verfügbarkeit von elektronischen Ressourcen benutzt wird.

Das Kernstück der Open Archives Initiative bildet das Open Archives Initiative Protocol for Metadata Harvesting, kurz OAI-PMH. Metadaten sind strukturierte Informationen über Ressourcen.

Das OAI-Protokoll Das OAI-PMH ermöglicht einen effizienten Austausch von Metadaten und impliziert eine funktionale Aufteilung in Anbieter von Dokumenten und Metadaten, so genannte Data Provider, und darauf aufbauende Dienste, die Service Provider.

Das OAI-PMH basiert auf dem Prinzip des so genannten Harvesting, bei dem im Gegensatz zum Ansatz des Cross Searching oder Federated Searching, der unmittelbaren Suche in allen verwendeten Datenquellen und Metasuchmaschinen, eine asynchrone Suche durchgeführt wird.

Der Service Provider fragt in regelmässigen Abständen die Metadaten der Data Provider ab und speichert diese in seiner lokalen Datenbank. Suchanfragen von Endnutzern werden im Falle des Harvesting-Ansatzes ausschliesslich mit Hilfe der Datenbank beantwortet.

40

Das OAI-PMH basiert auf weithin bekannten und verbreiteten Standards. Es setzt auf das Hypertext Transfer Protocol (http) auf und verwendet zur Kodierung der Metadaten und der sonstigen in den Antworten enthaltenen Informationen die eXtensible Markup Language (XML). Das OAI-Protokoll eignet sich zur Übertragung von Metadaten in beliebigen durch ein XML-Schema definierten Formaten, dennoch ist aus Gründen der Interoperabilität Unqualified Dublin Core als Minimalstandard in das OAI-PMH aufgenommen worden. OAIkompatible Data Provider müssen in der Lage sein, für ihre Metadaten zumindest Dublin Core auszuliefern. Damit sind die Kommunikation und der tatsächliche Austausch von Metadaten zwischen beliebigen OAI-kompatiblen Daten- und Service-Providern ohne weitere zusätzliche Vereinbarungen sofort möglich.

Die im OAI-PMH definierte prinzipielle Trennung zwischen Data Provider und Service Provider schliesst die Entwicklung von Diensten nicht aus, die beide Funktionalitäten beinhalten. Diese Möglichkeit wird von den aggregierenden Data Providern ausgenutzt. Sie fragen über das OAI-Protokoll die verfügbaren Daten einer bestimmten Menge von Data Providern ab und halten diese Menge für Anfragen anderer Service Provider ebenfalls über eine OAI-Schnittstelle vor.

Das OAI-PMH liegt in einer stabilen Version 2.0 vor. Es wird angewendet auf Resources = anything that has identity.

Frühere Protokoll-Versionen fanden Anwendung auf E-Prints bzw. document like objects.

Data Provider Als Data Provider wird eine OAI-kompatible Schnittstelle zu einer Datenbank verstanden, in der sich Metadaten über Dokumente oder andere digitale Objekte (Resources) befinden und die über eine http-Verbindung erreichbar ist. Sie muss dazu in der Lage sein, OAI-Abfragen entsprechend der Protokolldefinition korrekt zu beantworten.

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Access

Service Provider Der Service Provider bietet mit Hilfe von Daten, die er unter Nutzung des OAI-PMH gesammelt hat, einen innerhalb der Protokollspezifikation nicht näher definierten Dienst an. Der aus Sicht des Protokolls relevante Teil des Service Providers, der Harvester, versendet OAI-konforme Anfragen an den Data Provider und wertet die entsprechenden Antworten aus.

Open Access – die politische Seite Parallel zur allgemeinen Verfügbarkeit der technischen Voraussetzungen haben sich auch die Wissenschaftler organisiert mit ihrer Forderung nach Open Access. Das Open Society Institute (OSI) veranstaltete am 1. und 2. Dezember 2001 ein Treffen, aus dem die Budapest Open Access Initiative hervorging.

Budapest Open Access Initiative Frei zugänglich im Internet sollte all jene Literatur sein, die Wissenschaftlerinnen und Wissenschaftler ohne Erwartung, hierfür bezahlt zu werden, veröffentlichen.

Zu dieser Kategorie gehören zunächst Beiträge in Fachzeitschriften, die ein reguläres Peer-Review durchlaufen haben, aber auch z.B. Preprints, die (noch) nicht begutachtet wurden und die online zur Verfügung gestellt werden sollen, um Kollegen und Kolleginnen über wichtige Forschungsergebnisse zu informieren bzw. deren Kommentare einzuholen.

Open Access meint, dass diese Literatur kostenfrei und öffentlich im Internet zugänglich sein sollte, so dass Interessierte die Volltexte lesen, herunterladen, kopieren, verteilen, drucken, in ihnen suchen, auf sie verweisen und sie auch sonst auf jede denkbare legale Weise benutzen können, ohne finanzielle, gesetzliche oder technische Barrieren jenseits von denen, die mit dem Internet-Zugang selbst verbunden sind.

In allen Fragen des Wiederabdrucks und der Verteilung und in allen Fragen des Copyright überhaupt sollte die einzige Einschränkung darin bestehen, den jeweiligen Auto-

SMI 2005; No 55

rinnen und Autoren Kontrolle über ihre Arbeit zu belassen und deren Recht zu sichern, dass ihre Arbeit angemessen anerkannt und zitiert wird.

Das Publikationsmodell Open Access Selbstverständlich bedeutet das kostenfreie Zugänglichmachen von Beiträgen in wissenschaftlichen Fachzeitschriften nicht, dass diese ohne Kosten hergestellt und verteilt werden können.

Bisher vorliegende Erfahrungen haben gezeigt, dass die Gesamtkosten des Open Access weitaus geringer sind als die Kosten, die traditionellerweise für diese Art des Produzierens und Verteilens wissenschaftlicher Literatur entstehen. Gerade heute bedeutet die Aussicht auf einen sehr viel grösseren Verbreitungsgrad bei deutlich geringeren Kosten einen wichtigen Anreiz für Fachverbände, Universitäten, Bibliotheken, Stiftungen und Fördereinrichtungen sowie für andere Institutionen oder Personen, Open Access als wesentliches Mittel für ihre jeweiligen Belange zu erkennen und zu nutzen.

Insoweit ist mit der Etablierung des Open Access die Notwendigkeit zur Entwicklung neuer Kostendeckungsmodelle und Finanzierungsmechanismen verbunden.

Um Open Access zu wissenschaftlichen Fachbeiträgen zu ermöglichen, empfiehlt die BOAI zwei komplementäre Strategien: – Self Archiving; – alternative Fachzeitschriften, die sich den Ideen des Open Access verpflichten.

Diese neuen Zeitschriften sollten keine Subskriptions- oder Zugangsgebühren erheben, sondern sich um andere Mittel zur Abdeckung ihrer Kosten bemühen.

Self-Archiving Stevan Harnad hat die Idee des Self-Archiving bereits 1990 öffentlich vertreten und seither in zahlreichen Veröffentlichungen und Vorträgen vehement verfochten.

Das Registry of Institutional Self-Archiving Policies listet einige der Institutionen, die bereits eine eigene Policy formuliert haben.

41

SGMI SSIM SSMI

Swiss Medical Informatics Open Access

Open-Access-Zeitschriften und -Verlage Verlage, die der Open-Access-Bewegung verpflichtet sind, folgen einem neuen Finanzierungsmodell, von «subscription funded» zu «author funded». Autoren oder ihre Institutionen zahlen je nach Verlag zwischen 500 und 1500 Dollar für die Möglichkeit, einen Artikel in einer der Zeitschriften zu veröffentlichen. Dieser Artikel ist dann weltweit für alle kostenfrei im Internet zugänglich. BioMed Central – ein durchaus kommerzielles Unternehmen – und Public Library of Science – eine Initiative von Wissenschaftlern unter massgeblicher Beteiligung des Nobelpreisträgers Harold Varmus, – sind die wohl bekanntesten Vertreter dieses neuen Modells.

Hat die Institution, an der der Wissenschaftler arbeitet, die Mitgliedschaft bei BioMed Central erworben, so entfällt der Beitrag des einzelnen für die Veröffentlichung. Das Recht am geistigen Eigentum verbleibt beim Autoren. Selbstverständlich gelten dieselben Voraussetzungen für die Veröffentlichung wie bei einem herkömmlichen Verlag: Der Artikel muss den Peerreview-Prozess durchlaufen und überstehen.

Ein alternatives Modell zur Erhebung der Zitierhäufigkeit wird z.B. in der Faculty of 1000 angeboten. Impact factors werden durch Download-Zahlen ersetzt.

Mittlerweile verzeichnet das Directory of Open Access Journals fast 1500 Zeitschriften.

Creative Commons, das internationale OpenContent-Lizenzierungssystem, schafft, angepasst an die rechtliche Situation des jeweiligen Landes, neue Lizenzen, die den KreativSchaffenden die Rechte an ihren Werken sichern.

Kommerzielle Verlage sehen sich mehr und mehr zum Reagieren veranlasst. Das Verzeichnis Publisher copyright policies & self archiving gibt Auskunft, ob es legal ist, was viele Wissenschaftler als gegeben annehmen, nämlich dass es ihnen gestattet ist, eine Kopie ihres Artikels auf der eigenen Homesite zu deponieren. Die American Medical Association z.B. gestattet weder die Archivierung eines Pre-Prints noch die Archivierung eines Post-Prints!

42

Berlin Declaration on Open Access to Knowledge in the Sciences and Humanities Repräsentanten grosser Wissenschafts- und Forschungsorganisationen verabschiedeten am 22. Oktober 2003 die Berlin Declaration on Open Access to Knowledge in the Sciences and Humanities, die seither den wohl nachhaltigsten Einfluss auf die Open-AccessBewegung nimmt.

Sie benennt in Übereinstimmung mit der Budapest-Initiative, der ECHO-Charta und der Bethesda-Erklärung die Massnahmen, welche die vertretenen Organisationen beschlossen haben: – Unsere Organisationen unterstützen die weitere Förderung des neuen Prinzips des offenen Zugangs zum besten Nutzen von Wissenschaft und Gesellschaft.

Wir beabsichtigen deshalb: – Unsere Forscher und Stipendiaten dazu anzuhalten, ihre Arbeiten nach dem Prinzip des offenen Zugangs zu veröffentlichen – Die Kulturinstitutionen zu ermutigen, ihre Ressourcen ebenfalls nach dem Prinzip ... im Internet verfügbar zu machen – Mittel und Wege zu finden, um für die Open-Access-Beiträge und Online-Zeitschriften die wissenschaftliche Qualitätssicherung zu gewährleisten und die Regeln der Guten Wissenschaftlichen Praxis einzuhalten – Dafür einzutreten, dass Open-AccessVeröffentlichungen bei der Begutachtung von Forschungsleistungen und wissenschaftlicher Karriere anerkannt werden – Dafür einzutreten, dass der den Beiträgen zur Entwicklung einer Infrastruktur für den offenen Zugang innewohnende Wert – etwa in Form der Entwicklung von Software-Instrumenten, Inhaltsaufbereitung, Metadatenerstellung oder der Veröffentlichung einzelner Artikel – anerkannt wird.

Berlin 3 Open Access Die zweite Folgekonferenz zur Umsetzung der Berlin Declaration in Southampton beschrieb am 1. März 2005 einen konkreten Weg:

SMI 2005; No 55

SGMI SSIM SSMI

Swiss Medical Informatics Open Access

Institutionen sollten eine Policy formulieren und – von ihren Forschenden verlangen, dass sie eine Kopie aller publizierten Artikel in einem Open Repository hinterlegen – genannt Green Road to Open Access und – ihre Forschenden ermuntern, dass sie ihre wissenschaftlichen Arbeiten in einem Open-Access-Journal publizieren, wo immer ein geeignetes vorhanden ist – genannt Golden Road to Open Access – und sie sollten die Unterstützung bereitstellen, um dies zu ermöglichen.

Open Access in der Schweiz In der Schweiz sind Beiträge zur Unterstützung des Prinzips des Offenen Zugangs geleistet worden u.a. mit der Unterzeichnung der OECD Declaration on Access to Research Data from Public Funding, dem Offenen Brief der Konferenz der Universitätsbibliotheken der Schweiz (KUB) an den Präsidenten der Rektorenkonferenz der Schweizer Universitäten (CRUS), den Empfehlungen zu Elektronischen Dissertationen in der Schweiz.

Das CERN veranstaltet seit 2001 regelmässig den CERN Workshop on Innovations on Scholarly Communication. Der vierte Workshop in dieser Reihe wird vom 20.–22. Oktober 2005 in Genf stattfinden.

Das CERN gehört zu den frühen Unterzeichnern der Berlin Declaration und steht kurz vor der Verabschiedung einer Open Access Policy für die gesamte Organisation.

Die Universitäten Zürich, Genf, Lausanne, Bern und Basel sowie die Novartis Group und Serono haben die Mitgliedschaft bei Biomed Central erworben. Die Universität Zürich hat als eine von zehn Institutionen weltweit das Erscheinen der ersten Nummer der Zeitschrift PLoS Biology mit einer Launch Party gefeiert, die Université de Lausanne hat am 28. April 2005 den zehnten Geburtstag der Bibliothèque de Biologie mit einem Mini-Symposium zu Open Access und der Zukunft der Bibliotheken begangen. Im Auftrag der Universität St. Gallen (HSG) evaluiert das Medien- und Kommunikationsmanagement-Institut der HSG derzeit die Situation der Planung und Unterstützung der Open-Access-Bewegung in der Schweizer Forschungslandschaft.

SMI 2005; No 55

Die Universität Zürich und die Schweizerische Akademie der Medizinischen Wissenschaften haben gemeinsam das Symposium on Open Access to Knowledge and Scholarly Communication organisiert. Mit dieser Veranstaltung wurde am 15. Oktober 2004 eine breite wissenschaftliche Öffentlichkeit in der Schweiz mit den Zielen der OpenAccess-Bewegung vertraut gemacht und eine informierte Diskussion angeregt.

Als erste und bisher einzige Universität in der Schweiz hat die Universität Zürich, vertreten durch den Prorektor Forschung Professor Alexander Borbély, am 15. Dezember 2004 die Berlin Declaration unterzeichnet.

Es wird betriebsam auf der Road to Open Access!

1 Open Archives Initiative: http://www.openarchives.org/ 2 The Open Archives Initiative Protocol for Metadata Harvesting: http://www.openarchives.org/OAI/openarchivesprotocol.html 3 Dublin Core Metadata Iniziative: http://dublincore.org/ 4 Registered Data Providers: http://www. openarchives.org/Register/BrowseSites.pl 5 OAister Service Provider: http://oaister.umdl.umich.edu/o/oaister/ 6 Directory of Open Access Journals (DOAJ): http://www.doaj.org/ 7 Publisher Copyright Policies & Self-Archiving: http://www.sherpa.ac.uk/romeo.php 8 Budapest Open Access Initiative: http://oaister.umdl.umich.edu/o/oaister/ 9 Berlin Declaration on Open Access to Knowledge in the Sciences and Humanities: http://www.zim.mpg.de/openaccessberlin/berlindeclaration.html 10 CERN Workshop on Innovation on Scholarly Communication (OAI4) 20.–22. Oktober 2005: http://indico.cern.ch/conference Display.py?confId=0514

43

SGMI SSIM SSMI

Swiss Medical Informatics News / Impressum

nächste Ausgabe: September 2005 prochaine édition: septembre 2005 • Schwerpunkt/Thème principal: E-Learning

Events Switzerland MIE 2005 – European Federation of Medical Informatics Date: 28.–31.8.2005; Location: Geneva Contact: http://www.mie2005.net Wissenschaftliche Jahrestagung der SGMI / Journées annuelles scientifiques de la SSIM Date: 28.8.–1.9.2005; Location: Geneva Contact: http://www.sgmi-ssim.ch Impressum Publikationsorgan der Schweizerischen Gesellschaft für Medizinische Informatik Organe de publication de la Société suisse d’informatique médicale Herausgeber / Editeur SGMI, Schweizerische Gesellschaft für Medizinische Informatik Dählhölzliweg 3 Postfach 229 CH-3000 Bern 6 Tel. 031 350 44 99 Fax 031 350 44 98 e-mail: admin@sgmi-ssim.ch Internet: http://www.sgmi-ssim.ch Vorstand der SGMI / Comité de la SSIM Martin Denz, Antoine Geissbühler, Felix Heer, Christian Lovis, Eusebio Passaretti, Benno Sauter, Judith Wagner, Ulrich Woermann Chefredaktor / Rédacteur en chef Ulrich Woermann Redaktion / Rédaction Rolf Grütter, Christian Lovis, Ulrich Woermann

44

In eigener Sache Neuanfang beim Swiss Medical Informatics Unsere Zeitschrift «Swiss Medical Informatics» ist in letzter Zeit etwas unregelmässig erschienen. Hierfür möchten wir uns entschuldigen. Dies lag unter anderem daran, dass bei allen Beteiligten die Abläufe nicht ganz klar definiert und aufeinander abgestimmt waren.

ENI 2005 – European Nursing Informatics Date: 4.–5.11.2005 Location: Zürich Contact: http://www.printernet.info/eni.asp Europe

Dies wollen wir nun ändern. Die bisherige mündliche Abmachung mit dem Schwabe-Verlag wird durch einen Vertrag ersetzt. In diesem werden die Zuständigkeiten und Abläufe festlegt.

Als Ausdruck des Neuanfangs wird ab der nächsten Nummer das SMI auch mit einem neuen Layout erscheinen.

Dr. med. U. Woermann, Chefredaktor des «Swiss Medical Informatics»

World AMIA 2005 – American Medical Informatics Association Date: 22.–26.10.2005 Location: Washington DC Contact: http://www.amia.org/ meetings/annual/current/

50. GMDS-Jahrestagung Date: 11.–15. September 2005 Location: Freiburg i.Br. Contact: http://www.gmdsdae2005.de Redaktionsadresse / Adresse de rédaction Ulrich Woermann Abteilung für Unterrichtsmedien AUM Universität Bern Inselspital 38 CH-3010 Bern E-Mail: woermann@aum.unibe.ch

Inserate / Régie des annonces Schwabe AG Chantal Schneeberger Frankfurtstrasse 14, Postfach 340, CH-4008 Basel Tel. 061 333 11 07 Fax 061 333 11 06 E-Mail: c.schneeberger@schwabe.ch

Autorenrichtlinien / Directives pour les auteurs http://www.sgmi-ssim.ch/smi/index.htm

Abonnemente / Abonnements Schwabe AG, Verlagsauslieferung Farnsburgerstrasse 8 CH-4132 Muttenz Tel. 061 467 85 75 Fax 061 467 85 76 E-Mail: auslieferung@schwabe.ch

Verlag / Editions Schwabe AG Steinentorstrasse 13 CH-4010 Basel Betreuung im Verlag: Natalie Marty Tel. 061 467 85 55 Fax 061 467 85 56 e-mail: nmarty@emh.ch Druck und Versand / Impression et distribution Druckerei Schwabe AG Farnsburgerstrasse 8 CH-4132 Muttenz Tel. 061 467 85 85 Fax 061 467 85 86 E-Mail: druckerei@schwabe.ch

Abonnementspreis / Prix d’abonnement CHF 40.– (zuzüglich Porto / port en plus) Einzelnummer / Exemplaire unique CHF 15.– (zuzüglich Porto / port en plus) ISSN 1660-0436 erscheint 3mal jährlich paraît 3 fois par an

SMI 2005; No 55