Swiss Medical Informatics - SMI 71

38
Swiss Medical Informatics SMI 71 SGMI Schweizerische Gesellschaft für Medizinische Informatik SSIM Société suisse d'informatique médicale Società svizzera d'informatica medicale SSMI Swiss Society for Medical Informatics DRG Inhalt/Content/Contenu Système d’information et chaine de codage – Exemple aux Hôpitaux Universitaires de Genève Diagnosis related group: fondamentaux, enjeux et perspectives dans la chaine de traitement de l’information Wikicode, un outil rationnel pour permettre et améliorer le codage SwissDRG DRG und klinisches Informations- system: primum nihil nocere! Détection automatique d’infections urinaires dans le cadre du codage APDRG et SwissDRG Spitalfinanzierung 2012 – Datenschutz Ade? A semantic clinical data repository – how the work on DRGs can serve clinical medicine, too

description

DRG - Diagnosis Related Groups

Transcript of Swiss Medical Informatics - SMI 71

Page 1: Swiss Medical Informatics - SMI 71

Swiss Medical InformaticsSMI 71SGMISchweizerische Gesellschaftfür Medizinische Informatik

SSIMSociété suisse d'informatique médicaleSocietà svizzera d'informatica medicale

SSMISwiss Society for Medical Informatics

DRG

Inhalt/Content/Contenu

Système d’information et chaine

de codage – Exemple aux Hôpitaux

Universitaires de Genève

Diagnosis related group:

fondamentaux, enjeux et perspectives

dans la chaine de traitement de

l’information

Wikicode, un outil rationnel pour

permettre et améliorer le codage

SwissDRG

DRG und klinisches Informations-

system: primum nihil nocere!

Détection automatique d’infections

urinaires dans le cadre du codage

APDRG et SwissDRG

Spitalfinanzierung 2012 – Datenschutz

Ade?

A semantic clinical data repository –

how the work on DRGs can serve

clinical medicine, too

Page 2: Swiss Medical Informatics - SMI 71

TABLE OF CONTENTS

1

Editorial

Rodolphe Meyer 2

Système d’information et chaine de codage – Exemple aux HôpitauxUniversitaires de Genève

Eric Burgel, Rodolphe Meyer 3

Diagnosis related group: fondamentaux, enjeux et perspectives dansla chaine de traitement de l’information

Pierre Conne, Frédéric Perez, Rodolphe Meyer 7

Wikicode, un outil rationnel pour permettre et améliorer le codage SwissDRG

Rodolphe Meyer 12

DRG und klinisches Informationssystem: primum nihil nocere!

Marc Oertle 19

Détection automatique d’infections urinaires dans le cadre du codageAPDRG et SwissDRG

Philippe Rossier, Gilles Cohen, Rodolphe Meyer 23

Spitalfinanzierung 2012 – Datenschutz Ade?

Wolfram Strüwe 27

A semantic clinical data repository – how the work on DRGscan serve clinical medicine, too

Hans Rudolf Straub, Michael Lehmann 34

Swiss Medical Informatics 2011; no 71

Page 3: Swiss Medical Informatics - SMI 71

EDITORIAL

2

Le premier janvier 2012 les établissements de soins, enSuisse, basculeront dans le système SwissDRG. Nouveautétotale pour certains, ou évolution pour d’autres, il n’enreste pas moins que cette manière de grouper un séjourpour le facturer au plus juste n’est pas anodine. Depuis jan-vier 2009 des établissements pilotes jouent la carte desSwissDRG. Dans ce numéro «spécial SwissDRG» nousavons souhaité réunir des articles relatant leurs expé-riences et la manière dont ils ont adapté leurs processuspour accommoder et dominer les difficultés émergentes.L’article de Pierre Conne, que nous présentons ici, montrecomment l’abandon progressif des forfaits moyens parjournées d’hospitalisation représente une mutation radi-cale. L’article explore l’utilité de lier les différentes pers-pectives de la réforme pour comprendre les nouvellescontraintes organisationnelles qui en découlent, les va-leurs en jeu et l’importance de l’intégration de tous ces élé-ments dans les systèmes d’information hospitaliers. Cesdifficultés d’intégration aussi sont évoquées dans l’articled’Eric Burgel, qui explique comment proposer aux codeursdes hôpitaux un outil agile leur permettant de travaillerdans le contexte SwissDRG. Par ailleurs l’auteur expliquecomment, dans le cadre d’un système d’information dé-matérialisé, il est possible de savoir à quel moment, aprèsla sortie du patient, les documents nécessaires sont dispo-nibles pour coder. Ce codage requiert la mise à dispositionde dictionnaires à jour et expliqués, au besoin grammati-calement, aux utilisateurs. C’est ce type d’outil qui est dé-crit dans l’article parlant du wikicode des HUG. Le codagerequiert aussi la présence de documents «SwissDRG com-patibles» mais qui doivent rester orientés médecine fac-tuelle. Marc Oertle nous explique comment il a su mettreen œuvre un système d’information factuel pour en tirerles informations propices à la facturation. Une vision com-plétée par le travail de Philippe Rossier qui montre com-ment on peut créer des alertes «evidence based medicine»pouvant servir l’«economic based medicine» améliorant lecodage, le dossier clinique et également la facturation. Éco-nomie et financement sont aussi évoqués par WolframStrüwe dans son article donnant le point de vue de l’assu-reur sur les mutations engendrées par les SwissDRG surla circulation et la mise à disposition d’information sensi-bles par les réseaux de communication vers les bases dedonnées de tiers extérieurs aux structures de soins. EnfinHans Rudolf Straub nous montre comment des informa-tions structurées dans l’objectif de facturer sur le mode desSwissDRG peuvent devenir un moteur d’amélioration dela supervision de l’activité médicale d’un point de vuequantitatif, mais aussi, et surtout qualitatif.Bonne lecture à toutes et à tous.

On January 2012, health facilities in Switzerland willswitch for the SwissDRG system. Total novelty for some,or improvement for other, the fact remains that thistransformation will not be trivial. Since January 2009,pilots’ hospitals work with the SwissDRG system. In thisSwissDRG special issue we wanted to collect articlesabout their experiences and how they have adaptedtheir processes to accommodate and overcome theemerging difficulties. These papers explore the useful-ness of linking the different perspectives of the reformto understand the new organizational constraints aris-ing from the values at stake and the importance of inte-grating all these elements into hospital information sys-tems. These integration challenges are discussed andillustrate how structured information regarding Swiss-DRG billing can become an instrument for improving thequantitative and especially qualitative supervision ofthe medical activity.

EditorialRodolphe Meyer

Swiss Medical Informatics 2011; no 71

Correspondance:Dr Rodolphe Meyer, MD, PhDMédecin Adjoint responsable du service DéveloppementsTechno-logiques et Systèmes DécisionnelsHôpitaux Universitaires de Genève – D.A.M.E.Rue Gabrielle-Perret-Gentil 4CH-1211 Genève [email protected]

Page 4: Swiss Medical Informatics - SMI 71

DRG

3Swiss Medical Informatics 2010; no 71

Summary

Diagnosis Related Group (DRG) is one of the patient clas-sification schemes widely used as a basis for hospital pay-ment. It groups similar clinical conditions together and theprocedure implemented by the hospital during the pa-tient’s hospital stay. Information in each patient’s medicalrecords constitutes the source for these classificationgroups. The purpose of this article is to describe the DRGassignment process at Geneva University Hospital (HUG),focusing principally on two difficult problems. The first ishow to define thorough and complete documentation al-lowing coding of staff to select the DRG for a case. The sec-ond concern is the choice of the principal diagnosis i.e. theprincipal reason for the patient’s admission. Our conclu-sions are that the manner in which we implemented thisprocess in the HUG is quite satisfactory and easily evolv-able to the new DRG regulation.Key words: Diagnosis Related Group; information system;major diagnostic categories, user interfaceACM: H.5.2 user interfaces, user-centred design; J.1 ad-ministrative data processing, financial

Introduction

Depuis le 1er janvier 2007 aux Hôpitaux Universitaires deGenève (HUG), tous les séjours en soins somatiques aigusdoivent être facturés par forfait APDRG (All Patient Diag-nosis Related Groups). Ceci impose un codage complet etprécis de ces cas. Le codage consiste à attribuer au séjourdu patient dans l’hôpital, appelé aussi épisode de soin(EDS), des codes de diagnostics et les codes des interven-tions, si elles existent. Cette attribution se fait aux HUGgrâce à l’intervention d’une équipe de 15 codeuses et co-deurs professionnels qui traitent chaque année, environ46000 EDS. Leur travail consiste essentiellement à consul-ter les documents de sortie des patients (RSS: principale-ment des lettres de sortie et des comptes rendus opéra-toires) afin de déterminer les codes correspondants auxmaladies ou symptômes décrits, et/ou aux gestes médicauxet interventions effectués. Ces codes sont saisis par le co-deur dans un logiciel spécialisé (PDP). Ce logiciel permetle contrôle des codes saisis, puis effectue le groupage ducas afin de déterminer le DRG. Ce DRG est ensuite mis àdisposition du logiciel de facturation (OPALE), qui vientchercher les nouveaux cas journalièrement. Les codes dediagnostics proviennent de la classification des maladies

version 10-German (CIM10-GM). Les codes d’interventionsont quant à eux issus de la classification suisse des inter-ventions chirurgicales (CHOP).

Problématiques

Aux HUG toute la chaine de traitement est dématérialisée.Les codeurs travaillent sur un site extérieur au bâtimentprincipal et aucun dossier papier ne transite par le servicede codage. Toute l’activité se déroule via le système d’in-formation clinique (DPI) et chaque document nécessaire aucodage est dématérialisé. Cela pose deux problématiquesspécifiques à résoudre qui ne sont pas adressées par lesoutils fournis par les partenaires intérieurs ou extérieursà l’hôpital (service informatique, assureurs, organismesfédéraux, etc.). Il faut, d’une part, connaître l’état de la do-cumentation clinique. D’autre part, une fois le codage réa-lisé, il faut déterminer quel diagnostic principal choisir(DP), parmi ceux listés par le codeur. Enfin il faut prendreen compte les différentes versions des outils afin de pou-voir à tout moment recoder et regrouper un cas du passé,avec les outils en vigueur lors de la sortie du patient de l’hô-pital. Ce problème est augmenté du fait que depuis le 1er

janvier 2009, le codage est réalisé avec les dictionnaires etles règles du système SwissDRG alors que le groupage pourla facturation continu de se baser sur le système APDRGvalide jusqu’au 31 décembre 2011.

Solutions mises en place

La documentation est-elle prête pour le codage?ContexteLe codage d’un cas exige que la documentation le concer-nant soit prête, c.-à-d. que les documents nécessaires etindispensables au codage soient saisis et validés (signés

Système d’information et chaine de codageExemple aux Hôpitaux Universitaires de Genève

Eric Burgel, Rodolphe MeyerHôpitaux Universitaires de Genève, Direction de l’Analyse Médico-Economique

Correspondance:M. Eric Burgel, Ing.Analyste programmeurService DéveloppementsTechnologiques et Systèmes Décision-nels (DTSD)Direction de l’Analyse Médico-Economique (DAME)Hôpitaux Universitaires de Genève (HUG)Rue Gabrielle-Perret-Gentil 4CH-1211 Genève [email protected]

Page 5: Swiss Medical Informatics - SMI 71

DRG

4

par un responsable le plus souvent un clinicien). La listede ces documents est maintenue par le service informa-tique en partenariat avec les experts du codage. Tout nou-veau document mis à la disposition des services médicaux(SERMED) dans DPI est donc qualifié comme étant néces-saire ou non au codage.Au cours d’un même séjour, le patient peut être déplacésuccessivement dans plusieurs services médicaux. Les co-deurs ne peuvent donc coder un cas que lorsque l’ensembledes passages dans les différents services médicaux sontcorrectement documentés. Dès lors pour éviter que le co-deur ne perde du temps à chercher quels dossiers des pa-tients sortis peuvent être codés en ouvrant ces dossiers eten inspectant l’état de la documentation, il est créé une listed’EDS «prêts au codage». Cette liste est crée par un outil:la «maitre liste du codage» (MLC) dont les différentesétapes de travail sont décrite ci-après.

«Passages à documenter» (PAD)La trajectoire du patient dans l’hôpital est regroupée par«passage(s) à documenter» (PAD). Un PAD rassemble tousles éléments de la trajectoire hospitalière d’un patient quipeuvent être documentés ensemble. Le PAD est l’entité surlaquelle se base le codage professionnel pour identifier lesdocuments utilisés pour le codage des diagnostiques et desinterventions en vue de la génération du DRG. Un EDS peutêtre constitué de plusieurs PAD, mais un PAD ne peut cou-vrir qu’un seul EDS. En général, le PAD correspond à unséjour dans un service médical, mais il existe des cas pluscomplexes. Par exemple, un patient séjournant aux ur-gences, puis en médecine interne, puis aux soins intensifs,puis en médecine interne aura un PAD regroupant son pas-sage aux urgences et en médecine interne, un autre PADpour son séjour aux soins intensifs, et un troisième pourson deuxième séjour en médecine interne. Il existe actuel-lement une dizaine de règles de regroupement. Pourchaque PAD les règles désignent également un service mé-dical principal. Ce service sert de base de calcul pour la do-cumentation du PAD. Ce service est donc responsable de

la bonne documentation de l’ensemble du PAD auquel ilest rattaché.

Etat de la documentation d’un PADPour chaque service médical, il existe plusieurs façons dedocumenter correctement (pour le codage) le passage dupatient dans celui-ci. Ces différentes possibilités sont mo-délisées dans des patterns. Ceux-ci prennent en comptecertaines variables du séjour (nombre de passages en blocopératoire, nombre de passages en soins intensif). Par ex.,un passage dans un PAD de chirurgie cardiaque est suffi-samment codé s’il existe une lettre de sortie du service etque le nombre de passages au bloc ou aux soins intensifsau court de ce PAD est nul. Dans le cas où il y a, par exem-ple, deux passages au bloc opératoire, il faut qu’il y ait éga-lement deux «compte rendus opératoires» rattachés à cePAD afin que celui-ci soit considéré codable.

Etat de la documentation du séjour complet.Quand l’ensemble des PAD est documenté complètement,le séjour est déclaré prêt pour le codage. Celui-ci est trans-féré dans une liste des EDS prêts au codage. Cette liste ap-parait directement dans l’outil de consultation des dossiersà partir duquel les codeurs visualisent les cas (PDP). Ilspeuvent donc y réserver directement des EDS et leur travailde codage peut alors commencer.

Vue globale de la documentationLa MLC réalise les calculs de l’état du codage pour chacundes EDS de la zone APDRG chaque jour. Elle peut donc don-ner des résultats globaux sur l’année en cours ou sur lesannées précédentes. Ces résultats sont disponibles via despages HTML statiques publiées sur un serveur http dispo-nible pour les services. Ceux-ci peuvent donc suivre l’étatde la documentation pour le codage des patients dont ilssont responsables. La MLC collecte aussi des éléments destatistique de performance concernant la rapidité mise àdisposition des documents pour le codage au niveau desservices cliniques. La MLC permet également de descendredans le détail de l’état de la documentation mois par moispour un service donné; puis d’afficher l’état précis de ladocumentation de chaque EDS sans DRG.

Quel diagnostic choisir en tant que DP, parmi les DP despassages dans les différents services?Dans l’hôpital, chaque service est sous la responsabilitéd’un chef de service qui en assume la responsabilité mé-dicale. La documentation concernant un EDS est donc pro-duite par service médical, avec pour chaque passage dansun service médical, la production des documents néces-saires au codage de celui-ci (RSS et autres). Ces documentspermettent de déterminer pour chaque passage dans unservice médical:– un diagnostic principal (DP);– des diagnostics secondaires;– des codes d’interventions principales et secondaires.Pour les EDS concernant plusieurs services médicaux, onse retrouve donc avec plusieurs DP (un par PAD) parmi les-quels il faut en choisir un, qui sera le vrai DP de l’EDS. Ce

Swiss Medical Informatics 2010; no 71

Figure 1Flux des informations nécessaire à la détermination de l’état de la documentation.

Page 6: Swiss Medical Informatics - SMI 71

DRG

5

choix est très important car il déter-mine en grande partie le DRG résul-tant du groupage et donc la valeur dela facture qui sera émise. Par ailleursce choix doit être stable dans le tempset cohérent entre les cas:– une reprise du dossier par un autre

codeur (ou un expert contrôleur)doit aboutir dans les même condi-tions au même choix de DP;

– des cas similaires doivent aboutir àdes choix similaires.

Pour s’assurer de cette stabilité et decette reproductibilité, le choix du DPa été automatisé, il ne dépend que derègles qui sont implémentées dans lesystème du codage. Il n’y a donc pasde choix manuel du DP par le codeur.Ces règles s’appuient sur deux tables.La première fait le lien entre un codediagnostic et un ou plusieurs «major

diagnostic catégories» (MDC) potentiels, c.-à-d. la MDC duDRG dans lequel ce code est susceptible de faire tomber lecas. La deuxième table établie le lien pour les codes d’in-tervention et contient en plus, un indicateur spécifiant sile code est un code de type «procédure» (P), «Maladie» (M)ou Neutre (N).En pratique, les codes de tous les passages dans les ser-vices médicaux pour un même EDS sont rassemblés. Pourchaque DP on recherche toutes les interventions classéesdans la même MDC et on crée une ligne par combinaisonavec pour chaque ligne, plusieurs scores.Les lignes sont triées selon les scores, le DP apparaissantsur la première ligne est choisi en tant que DP de l’ensem-ble du séjour.Dans l’exemple décrit, seul le DP H25.8 peut être relié àdes interventions, par l’intermédiaire du MDC 2 commun.Les codes d’interventions 38.91 et 93.96 ne sont pas «clas-sant» (ils n’ont pas de MDC spécifiques).Toutes les combinaisons possibles de diagnostics et d’inter-ventions sont rassemblées dans un tableau, puis classéesselon des critères d’importance décroissants (SCORES).Dans ce cas, le diagnostic S81.0 est choisi en tant que DPcar son SCORE_MDC est meilleur que celui du P22.0.

Swiss Medical Informatics 2010; no 71

Figure 2Exemple de trajectoire simplifiée d’un patient lors d’un séjour à l’hôpital, avec codage associé.

Figure 3MDC associés aux codes diagnostic et intervention de l’exemple de la figure 2.

Tableau 1Détermination des scores.

Score Calcul Ordre de tri

SCORE_CLASS Selon le type de code intervention

Si ‘P’ : 1,

Si ‘M’ : 0,

Si ‘N’ : -1 descendant

SCORE_MDC Si MDC = 25 : 1

Si MDC = 19 ou 23 : -1

Sinon : 0 descendant

SCORE_DUREE Durée du PAD associé au code descendant

SCORE_SORTIE Date de sortie du PAD associé au code ascendant

Tableau 2Exemple de combinaison de DP et d’interventions, classés par ordre de score.

Diagnostic Intervention SCORE_CLASS SCORE_MDC SCORE_DUREE SCORE_SORTIE

S81.0 81.18 1 1 6 22.01.2010 17:32:00

P22.0 43.42 1 0 7 14.01.2010 16:50:00

Q31.8 33.22 0 0 9 07.01.2010 11:05:00

Comment coder en SwissDRG alorsque la facturation se base sur lesAPDRG?Les outils fournis par APDRG Suissenous permettent de résoudre le pro-blème. Depuis le 1er janvier 2009, lecodage est effectué en SwissDRG. Ce-lui-ci est envoyé au casemix office deSwissDRG-SA pour construire lesDRG de 2012. Le groupage de ces casn’est pas soumis directement au

Page 7: Swiss Medical Informatics - SMI 71

DRG

6

groupeur 3M (APDRG), mais est envoyé à un outil intermé-diaire (MedGroup). Celui «rétro-transcode» les codes del’EDS en version compatible APDRG, appelle le groupeur,puis applique les règles «Swiss Payment Group» spéci-fiques à la Suisse. Ces règles reclassent certains cas dansun autre DRG plus précis. C’est ce dernier DRG qui seraenvoyé à la facturation.

Limites du système

Etat de la documentationPour bien connaitre l’état de la documentation médicalepour un EDS donné, il faut:– que tous les documents nécessaires au codage soient sai-

sis;– que ces documents soient correctement marqués comme

«document nécessaires au codage»;– que les documents soient rattachés au bon séjour.Il arrive parfois que le document saisi par les secrétaires,et rattaché au bon patient, soit affecté au mauvais EDS(c’est en général une erreur de manipulation). Dans ce cas,le système «ne voit» jamais que la documentation est prêtepour le codage de cet EDS, et ne le propose donc pas dansles listes des EDS à coder. L’accumulation de ces cas obligeune reprise analytique manuelle régulière de tous les casqui restent à coder pour finaliser le codage, ou réclamerles documents nécessaire à la finalisation aux différentsservices.

DRG calculéDans certains cas, le DRG calculé par la chaine de groupageest incohérent. Si cela provient d’une erreur de codage, ilsuffit de corriger le codage puis de regrouper le cas. Il restecependant des cas où l’erreur provient du groupeur lui-même. Dans ce cas, le codeur doit déterminer lui-même leDRG à facturer. Il dispose pour cela d’un outil de simulationqui lui permet de vérifier le résultat du groupage avec descodes en plus ou en moins. Une fois ce DRG déterminé, ilpeut le forcer dans l’EDS. Dans ce cas, c’est ce dernier DRGqui est envoyé à la facturation. Tous ces cas obligent les co-deurs à connaitre parfaitement les cas de forçage autoriséspar l’OFS.

Limites généralesLe passage aux SwissDRG va imposer un regroupementpotentiel de plusieurs séjours dans un même EDS. Un pa-tient sorti des HUG et étant réhospitalisé moins de 18 joursaprès la fin de son séjour précédant verra son EDS fusionnéavec le précédent si son problème concerne la même MDC.Les EDS ainsi fusionnés devront être repassés par unephase de groupage pour prendre en compte la nouvelle du-rée de séjour mais aussi d’autres variables contextuelles àl’EDS (heures de ventilation, heures en soins intensifs,etc.). On voit que cela complexifie la gestion des EDS maissurtout que cela génère potentiellement deux consé-quences, soit un retard à la facturation pour s’assurer dudélai de 18 jours révolus, soit des refacturations.

Perspectives et conclusion

Le passage dès le 1er janvier 2012 au Swiss-DRG ne va pasimposer de refonte de la chaine de codage aux HUG carcette démarche a déjà été effectuée depuis 2009. Certainsprojets de construction des données nécessaires au codagen’aboutissent qu’en janvier 2011. On voit donc que le faitde posséder un système d’information très intégré peutêtre un avantage lors de la bascule d’un système vers unautre, car les processus sont déjà en place, mais que cettebascule à un coût humain et technique non négligeable etsurtout que ce coût génère une inertie proportionnelle à sacomplexité. Attention, qui dit inertie ne dit pas immobilité.On voit que chaque maillon de la chaine de codage, peutfragiliser la qualité et la productivité de la chaine de trai-tement. La documentation des cas et ses délais de produc-tion sont au cœur des processus de groupage au même titreque les outils de création des DRG dans le système d’infor-mation. La bonne implémentation des dictionnaires et no-menclature ainsi que la généralisation de leur usage estaussi un point clé. Des boucles de régulations, des forma-tions et des incitatifs à la rigueur sont les corollaires dusuccès de tous ces changements.

Swiss Medical Informatics 2010; no 71

Figure 4MDC et réhospitalisations.

Page 8: Swiss Medical Informatics - SMI 71

DRG

7

Summary

The recent revisions of Swiss federal law on health insur-ance create the framework for a competitive public marketembracing all hospitals, in particular with the introductionof the SwissDRG system taking effect in January 2012. Weanalyse the risks and emergent opportunities in order tohighlight the clinicians’ central role. We show the impor-tance of medical, administrative and financial documen-tation in guaranteeing quality of care, equity of access toservices and control of costs. The interrelationships andlevels of complexity of our health care system will be suchthat only by sophisticated and integrated informationsystems will it be possible to collect, analyse and restoreall the data necessary to successfully carry through thechanges to come.Key words: DRG, SwissDRG, information systemsACM: J.1 Administrative data processing, financial

Introduction

Ce texte a pour but de développer une meilleure compré-hension des processus de transformation du système desoins helvétique, induits par les récentes révisions de la loifédérale sur l’assurance maladie et plus particulièrementla partie concernant le financement hospitalier. L’adoptionpar les chambres fédérales d’une structure tarifaireunique, pour tous les hôpitaux, basée sur différents forfaitsglobaux par séjour dont les montants sont fixés en fonctionde l’importance des problématiques médicales en jeu, etl’abandon des forfaits moyens par journées d’hospitalisa-tion, est une mutation radicale. Elle prendra effet le 1er jan-vier 2012. Le point de départ de ce papier repose sur cetteobservation. L’article explore l’utilité de lier les différentesperspectives de la réforme pour comprendre et influencerles processus de changement: les nouvelles contraintes or-ganisationnelles, les valeurs en jeu et l’importance de l’in-tégration de tous ces éléments dans les systèmes d’infor-mation hospitaliers.

Comprendre les DRG

Origine, objectifs et fonctionnement des DRGAux Etats Unis, dans le courant des années 70, les hôpitauxétaient en concurrence pour obtenir les budgets publics

nécessaires à couvrir les frais de traitement des personnessans assurance personnelle et prises en charge par un fi-nancement social: Medicare. Face aux demandes crois-santes des hôpitaux d’augmenter ces subventions, les pou-voirs publics ont exigé de ces derniers qu’ils formulentleurs requêtes de manière à pouvoir relier les coûts des sé-jours aux diagnostics posés et aux interventions effectuées.Pour cela, il fallut imaginer un système regroupant les pa-tients dans des grandes catégories valorisées, constituéesà la fois autour des diagnostics et des interventions. RobertFetter et son équipe de l’Université de Yale ont développéun modèle de classification des hospitalisations par re-groupement répondant à cette exigence de double homo-généité médicale et financière. Ces forfaits par groupescliniquement identifiables et iso-consommateurs de res-sources sont les DRG (Diagnosis Related Groups) [1, 2]. En1983, les Etats Unis les introduisent, pour la facturationdes séjours, sous la forme d’APDRG (All Patient DiagnosisRelated Groups), étendus à toutes les catégories socio-éco-nomiques de personnes et non plus uniquement aux casMedicare. Ce système s’est ensuite progressivement ré-pandu en Europe et en Australie. Ce mode de rémunéra-tion forfaitaire, englobe la totalité des actes médicaux, lessoins de base, les services hôteliers et fixe un nombre dejours d’hospitalisation minimum et maximum par groupeDRG. Le montant facturé pour une hospitalisation donnéen’est pas la somme du nombre d’actes effectués, ni celledu nombre de journées d’hospitalisations mais il s’agitd’un prix moyen par séjour, «all inclusive».

Construction des DRGLes DRG sont fondés sur les informations médicales descas hospitalisés et sur leurs coûts respectifs. La construc-tion des groupes DRG débute par une observation du sys-tème de soins hospitalier en libre cours permettant de col-lecter les données nécessaires. Les DRG reflètent l’activitéhospitalière, médicale et financière, observée dans le

Swiss Medical Informatics 2011; no 71

Diagnosis related group: fondamentaux, enjeuxet perspectives dans la chaine de traitementde l’informationPierre Connea, Frédéric Perezb, Rodolphe Meyera

Hôpitaux Universitaires de Genève (HUG)a Direction de l’analyse médico-économique (DAME)b Direction des affaires financières (DAF)

Correspondance:Dr Pierre Conne, M. Sc.Hôpitaux Universitaires de Genève (DAME/CICLA)Rue Gabrielle-Perret-Gentil 4CH-1211 Genève [email protected]

Page 9: Swiss Medical Informatics - SMI 71

DRG

8

temps. Les informations médicales sont obtenues en tra-duisant les données contenues dans le dossier cliniquesous forme de codes. En Suisse, ils sont issus de la CIM(classification internationale des maladies) et de la CHOP(classification suisse des interventions chirurgicales). Lescoûts des hospitalisations sont obtenus dans le cadre d’unecomptabilité analytique classique.Ensuite, les données médicales, sous forme codée, et lesdonnées financières sont regroupées pour former les DRGen respectant des règles statistiques précises. Ces der-nières confèrent à chaque groupe la meilleure homogé-néité médicale et financière possible: le diagnostic princi-pal ou une combinaison de diagnostics et d’interventionsdoivent expliquer statistiquement la durée de séjour et lecoût. Chaque groupe DRG, se voit ainsi attribuer un inter-valle de durée de séjour qui lui est propre et un poids relatifaux autres DRG, le cost weight (CW). Il s’agit de la propor-tion de ressources utilisées dans un DRG par rapport à lamoyenne des ressources utilisées de tous les DRG1. Ainsi,un cas avec complications abouti dans un groupe diagnos-tique avec une valeur relative plus élevée qu’un cas sanscomplication. Certaines combinaisons de codes diagnos-tiques sont parfois déterminantes; à l’inverse, et dans derares cas, l’intervention est la seule à classer un cas dansun DRG. Des données personnelles ou administratives sontégalement prises en compte pour le regroupement: l’âge,le poids de naissance, le mode de sortie.

Les règles de regroupement en DRG sont constituées d’al-gorithmes, informatisés et traités par un logiciel «grou-peur». C’est ce groupeur qui permet ensuite d’attribuer lescas hospitalisés au groupe DRG correspondant en vued’une facturation. Chaque DRG possède des bornes infé-rieure et supérieure de durée de séjour au cours de laquellele CW ne varie pas. Le prix facturé ne sera donc pas in-fluencé par la durée de séjour comprise entre ces deuxbornes. Si elle n’est pas dans ces bornes (outliers), des rè-gles de calcul prendront en compte la charge différentielleau prorata de l’écart.

Introduction des DRG en SuisseAu début des années 2000, à l’initiative du Centre Hospi-talier Universitaire Vaudois (CHUV), un groupe d’hôpitauxa progressivement développé l’utilisation des APDRG. LesHôpitaux Universitaires de Genève (HUG) facturent les sé-jours des soins aigus somatiques sur cette base depuis le1er janvier 2007. À ce jour, une centaine d’hôpitaux desoins aigus somatiques en Suisse sur 300 facturent leursséjours en APDRG. L’art. 49 de la loi fédérale sur l’assu-rance maladie, instaure, à partir du 1er janvier 2012, l’obli-gation pour tous les hôpitaux de soins aigus somatiques defacturer les séjours hospitaliers en forfaits par séjour. Dansce but, les SwissDRG, une émanation du système allemand,les German DRG (G-DRG), ont dû être développés. Cettebase de facturation sera utilisée pour comparer les hôpi-taux entre eux et leur allouer les ressources.Le 18 janvier 2008, H+ (hôpitaux de Suisse), la FMH (fédé-ration des médecins suisses), santésuisse (assureurs-ma-ladie suisses) et la CDS (conférence suisse des directriceset directeurs cantonaux de la santé) ont fondé, en tantqu’actionnaires, la société SwissDRG SA siègeant à Berne.Cette société anonyme d’utilité publique et son organe opé-rationnel, le bureau Casemix, ont été chargés d’introduire,sur le plan national, le système unifié de forfaits pour lefinancement des prestations stationnaires des hôpitauxde soins aigus somatiques, les SwissDRG. Elle devra aussigarantir la maintenance de cette structure tarifaire. LaFMH a obtenu un siège au Conseil d’administration deSwissDRG SA pour que le processus d’adaptation du sys-tème allemand, G-DRG, aux réalités suisses ait lieu en col-laboration avec les sociétés de discipline médicale.

Facturer en DRGLe processus de facturation consiste, dans un premiertemps, à coder les informations cliniques d’un séjour puisà grouper les codes obtenus pour attribuer à ce séjour ungroupe DRG. Cette attribution est réalisée par le groupeursur la base des codes CIM et CHOP.Ensuite, la valeur relative du DRG obtenu, le CW, doit êtremultipliée par la valeur du point DRG pour obtenir le mon-tant facturé. Le prix du point DRG est la valeur de base enFrancs Suisses pour un patient en traitement hospitalieravec un cost-weight – ou poids relatif – de 1,0.

Swiss Medical Informatics 2011; no 71

Figure 1Processus de facturation en DRG.

1 La définition du CW au niveau national correspond au coût moyend’un DRG en Suisse/coût moyen de toutes les hospitalisations enSuisse. Exemple: si le coût moyen des hospitalisations classéesdans le DRG x est de 12500 CHF et si le coût moyen de toutes leshospitalisations est de 10000 CHF, alors le CW du DRG x est de1.250

Page 10: Swiss Medical Informatics - SMI 71

DRG

9

Perspectives et limites

Sur la construction et la mise en place des DRGSi l’on observe le processus de mise en œuvre des DRG envue du 1er janvier 2012, nous constatons que les associa-tions infirmières et les associations de patients ne sont pasmembres de SwissDRG SA, ce qui est regrettable. En effet,les activités infirmières mais aussi paramédicales dansleur ensemble, participent au contenu des activités hospi-talières de manière significative, tant du point de vue de laqualité des soins que du point de vue des coûts. D’autrepart, les patients étant les principaux concernés par lessoins qu’ils reçoivent, il eût été utile que leurs représen-tants aient également voix au chapitre.Il restera encore beaucoup à faire pour que le systèmeSwissDRG reflète aussi correctement que possible les ser-vices fournis, corresponde aux réalités suisses et pour quela qualité des soins soit garantie dans ce nouveau système.

Sur l’évolutivité des DRGLorsque le système de facturation en DRG fonctionne envitesse de croisière, les données médicales et financièresde tous les hôpitaux sont recueillies et analysées annéesaprès années de manière à faire évoluer les groupes diag-nostiques et leurs poids relatifs.Cette évolution devrait tenir compte de l’introduction, dansla pratique, des innovations médicales. Des règles précisessont en voie de finalisation par SwissDRG SA. La questiondes rémunérations supplémentaires de certaines procé-dures rares et très chères n’est pas entièrement close àl’heure actuelle.

Sur la comparabilité et la concurrence entre hôpitauxPour que les DRG permettent de comparer les hôpitaux en-tre eux, notamment au niveau des coûts, il faudrait que ceshôpitaux soient vraiment comparables, ce qui n’est pas lecas aujourd’hui. De plus, la croyance selon laquelle «oneDRG = one price» est fausse. Les raisons en sont les sui-vantes.Premièrement les salaires, qui représentent près de 80%des coûts hors investissements, ne sont pas les mêmes auniveau national. Ces différences de coûts sont sans rapportavec l’efficience organisationnelle de l’hôpital mais contin-gente au niveau de vie local, niveau de vie qui varie d’uncanton à l’autre.Deuxièmement, au sein d’un même DRG, la distributiondes patients selon leur coût n’est pas identique dans tousles hôpitaux. En effet, les hôpitaux qui sélectionnent les pa-tients, implicitement en raison de leurs ressources hu-maines et matérielles limitées ou explicitement pour maxi-miser leur profit, ont une patientèle homogène et un coûtmoyen par point CW inférieur aux autres hôpitaux. De parleurs missions et la nature de leurs activités, les grands hô-pitaux cantonaux prennent en charge des patients très di-vers, tant en intensité de soins qu’en complexité. Lesétudes médico-économiques ont montré que ce facteur dediversité entraînait des coûts moyens par point CW supé-rieurs à ceux des hôpitaux qui ont une patientèle plus ho-

mogène [3, 4]. Cela s’explique par le fait que les ressourceshumaines et matérielles sont généralement adaptées à laprise en charge des cas les plus complexes, alors que la pa-tientèle soignée est de complexité variable.Troisièmement, les données de coûts par patients ne sontpas identiques d’un hôpital à l’autre. La comptabilité ana-lytique n’est pas normée au niveau national de sorte quel’écart du coût par cas observé aujourd’hui entre deux hô-pitaux (par ex., la différence de coût de la mise en placed’une prothèse totale de hanche) s’explique probablementdavantage par des différences de règles de comptabilitéanalytique que par des différences de processus de priseen charge des patients. Notons qu’en Allemagne, pays quiinspire la mise en place du système suisse de DRG, la comp-tabilité analytique des hôpitaux est strictement norméejusque dans ses granularités les plus fines.

Sur la rémunération hospitalièreÀ l’avenir, les hôpitaux accueilleront de plus en plus de pa-tients avec des pathologies chroniques, souvent associéesà une baisse d’autonomie. Ces problèmes complexes, évo-lutifs et continus ne sont pas correctement décrits par lastatistique médicale hospitalière. Les DRG avaient tout leursens dans le modèle américain des années 70, où la priseen charge, sur la durée, de patients chroniques n’était pasreconnue comme une réalité de santé publique. Nous pou-vons nous demander si ce mode de rémunération est en-core bien adapté à la population hospitalière actuelle.À la différence du domaine des soins somatiques aigus, au-cun modèle tarifaire existant et déjà utilisé avec succèsn’est disponible pour la psychiatrie et la réadaptation. Lessystèmes de rétribution actuellement appliqués devrontdonc être maintenus entre le 1er janvier 2012 et le momentauquel une structure tarifaire liée aux prestations sera dis-ponible pour le remboursement des hospitalisations enpsychiatrie et en réadaptation. Des efforts doivent être faitspour que la rémunération des séjours de réadaptation, depsychiatrie et, par analogie, de gériatrie et de soins pallia-tifs puissent l’être sur la base de forfaits qui reconnaîtrontet valoriseront ce type de séjours hospitaliers appelés àaugmenter. À cet égard, il faut saluer les récentes décisionsde SwissDRG SA: le Conseil d’administration de SwissDRGSA fera office d’organe suprême pour la gestion des projetsconcernant la mise au point des structures tarifaires depsychiatrie (tapsy) et de réadaptation (STM Réha MTK).

Sur la qualité des soinsContrairement à certaines idées reçues, il faut réaliser que«le patient entre à l’hôpital mais n’entre pas dans ungroupe DRG». Le groupe DRG ne peut être attribué qu’à lasortie, afin de prendre en compte de ce qui s’est passé pen-dant le séjour. Il n’est donc pas possible de connaître, àl’admission, quels seront les problèmes rencontrés,quelles seront les ressources nécessaires pour y faire faceni combien de jours durera l’hospitalisation. De plus, lesrègles de facturation des SwissDRG prévoient que si un pa-tient est réhospitalisé moins de 18 jours après sa sortie,pour un problème du même type que celui de l’hospitali-

Swiss Medical Informatics 2011; no 71

Page 11: Swiss Medical Informatics - SMI 71

DRG

10

sation précédente, les deux séjours doivent être fusionnéset facturés en un seul. Cette règle possède un double inci-tatif: assurer le meilleur état clinique possible à la sortie etéviter de fractionner les séjours.Cependant, l’introduction des DRG est bien plus qu’unesimple mesure administrative. Elle prête à s’interroger surle rôle que joue l’hôpital au sein de notre société, sur lesrisques d’un appauvrissement de la qualité des soins et surles questions d’équité quant à l’accès aux services [5, 6].Ce mode de rémunération forfaitaire qui englobe à la foisles actes médicaux d’investigations et de traitements, lesmédicaments, les soins et les journées d’hospitalisationpeut faire courir le risque aux patients de se voir priverd’un certain nombre de prestations médicalement justi-fiées. Ce mode de rémunération conduit à l’attrition du sys-tème et, livré à lui-même, il incite à rentabiliser les hospi-talisations. Une étude de 2010 en Suisse [2], montre que lenombre d’hospitalisations a tendance à diminuer avec lesystème DRG et que les ressources sont réallouées vers lessoins ambulatoires.Le risque d’une économicisation de la médecine qui se ré-duise à un ensemble de prestations tarifées existe. Il n’yaurait plus de patients mais des clients, plus de médecinsou de soignants mais des fournisseurs de prestations. Lesoin deviendrait un produit soumis aux règles de compé-titions et de quantification du marketing. Les anglicismesou néologismes tels que disease management ou itinéraireclinique viendraient remplacer les notions fondamentalesd’anamnèse, d’examen clinique, de diagnostics différen-tiels et d’alternatives thérapeutiques.Le «management» pourrait prétendre être seul à même depiloter le système de santé et conduire à ce que tous les pa-tients soient soignés au moindre coût, dans un temps mi-nimum. Les DRG pourraient inciter les hôpitaux à sélec-tionner les patients rentables, la rentabilité d’un patientdépendant des possibilités de codage qu’offre sa conditionparticulière de santé. A l’inverse, les DRG pourraient créerune nouvelle catégorie de malades, celle des patients nonlucratifs. Dans ces groupes de patients non lucratifs, noustrouverons des personnes que leur état rend déjà sociale-ment vulnérables [6]: malades chroniques, touchés par demultiples morbidités mais sans diagnostic spécifique,âgés, handicapés ou en fin de vie. Les forfaits par séjourpourraient devenir un incitatif à ne pas les soigner selonleurs besoins. Le temps consacré à la relation entre les soi-gnants, infirmiers ou médecins, et les malades, pourraientne pas être rémunéré: dialogue, explication, participationaux décisions et compassion. En plus de laisser pourcompte les patients vulnérables, ce mode de rémunérationpourrait être une atteinte à la partie vulnérable de chaquepatient. Alors, paraphrasant Hannah Arendt [7], nouspourrions écrire: «Le totalitarisme économique ne tendpas vers un système de soins qui règne en despote sur lesmalades mais vers un système de soins où certains ma-lades sont de trop …»

Sur la confidentialité des données médicalesLa LAMal, à son article 42, dispose que le prestataire doitfournir à l’assureur, en tiers payant, toutes les informa-

tions nécessaires lui permettent de contrôler le bien-fondéde la facture. A cette fin, d’entente avec santésuisse, lesHUG pratiquent de la manière suivante. Chaque facturementionne le numéro du DRG mais aucun code diagnosticni d’intervention n’est transmis systématiquement aux as-surances. De plus, le patient peut s’opposer à cette men-tion. Dans ce cas le médecin en charge documente ce pointdans le système d’information clinique. Ainsi, le numérodu DRG n’apparaît pas sur la facture et il n’est transmisqu’au médecin-conseil, confidentiellement. D’autre part,de cas en cas et sur demande des assureurs, les HUG adres-sent aux médecins-conseils, les documents cliniques quiont servi au codage. Sur ces éléments, les assureurs peu-vent demander de vérifier le codage et, le cas échéant dele corriger afin de refacturer correctement le séjour des sé-jours. Ce fonctionnement en vigueur depuis quatre ans,respecte les droits de la personnalité des assurés, notam-ment le principe de proportionnalité qui doit exister entrela nature d’une information et la finalité de son utilisation,et donne satisfaction aux assureurs et aux HUG.

Sur la documentation médicaleNous ne disposons pas de données sanitaires, médicaleset financières, recueillies partout avec les mêmes nomen-clatures, le même niveau de détail et une accessibilité na-tionale qui nous permettraient d’avancer, sans hésiter, sa-chant que nous pourrons maîtriser les différents risques etfaiblesses déjà identifiés. Observer et documenter est plusnécessaire que jamais, les conditions de l’exercice médicalsont devenues telles qu’il n’est plus imaginable de se pas-ser de systèmes d’informations intégrés capables de saisiret de traiter des informations surabondantes et de naturesdiverses.Le travail d’un médecin, par extension d’un hôpital, estévalué sur la base des documents retraçant la manièredont un problème médical a été pris en charge. À la foissur le plan clinique, financier et, le cas échéant, juridique.En d’autres termes, le clinicien aura terminé son travailquand le dossier du patient sera complété. La documenta-tion clinique et la documentation des activités font partieintégrante du travail clinique. Aux HUG c’est une obliga-tion contractuelle des cliniciens [8].Documenter et tracer les activités cliniques doit permettred’être toujours en contact étroit avec les réalités cliniqueset d’utiliser les informations générées, en premier lieupour mieux traiter et partager le suivi des patients et, ensecond lieu, pour constituer des tableaux de bord de pilo-tage. Cette documentation, souvent perçue comme admi-nistrative par les soignants, doit être reliées à des enjeuxde qualité ou de sécurité des soins. La documentation cli-nique ne doit pas être une tâche séparée des soins afin quelesprofessionnelsde santépuissentbénéficier directementde ce travail plus tard (what you give is what you get). Deplus, les projets de systèmes d’informations hospitaliersdoivent être pensés et pilotés avec une double vision, cli-nique et financière. Cela implique une coopération trans-versale forte entre les équipes cliniques et informatiqueset la prise en compte de la position centrale des diction-naires et des nomenclatures nécessaires au codage cli-

Swiss Medical Informatics 2011; no 71

Page 12: Swiss Medical Informatics - SMI 71

DRG

11

nique et au traitement des informations. Ces conditions ga-rantiront que les informations présentes pourront êtretransposées selon différents axes d’analyse: clinique, ad-ministrative, financière, politique.

Les limites de la documentation DRGLa documentation nécessaire au bon fonctionnement dusystème DRG n’ayant qu’un seul objectif, constituer desgroupes de cas facturables en forfaits par séjour, les infor-mations recueillies sont lacunaires et ne produisent pastoutes les données sanitaires, médicales et financières né-cessaires à la conduite de grands ensembles hospitaliersou de réseaux.La documentation DRG:– ne couvre qu’une partie de l’activité: l’activité station-

naire destinée aux soins aigus somatiques; les activitésde réadaptation, de psychiatrie et ambulatoires ne sontpas incluses. Or, les activités ambulatoires réalisées parles hôpitaux sont importantes et vont continuer à croître:offre de service 24h/24, spécialités médicales de réfé-rence;

– ne s’effectue qu’à partir des documents de synthèse etnon sur l’entier des données contenues dans les dossierscliniques, à cause de l’étendue des informations et de lalimitation des capacités humaines à les rechercher demanière systématique et exhaustive;

– ne retient que les données dites classantes, c-à-d. cellesqui sont les marqueurs d’une différenciation statistiquede consommation de ressources et qui jouent un rôlequant à l’affectation du séjour dans le DRG adéquat aumoment du groupage;

– ne relève ni les médicaments – nature et quantité desubstances pharmaceutiques – ni les implants médi-caux, ni ne donne d’informations sur les activités mé-dico-soignantes en rapport avec un patient donné.

Conclusion

Les récentes révisions de la loi fédérale sur l’assurance ma-ladie portant notamment sur le financement hospitaliercréent les conditions d’un changement en profondeur dusystème de soins helvétique. Les risques que l’économisa-tion de la médecine conduise à un appauvrissement de laqualité des soins et remette en questions l’équité quant àl’accès aux services existent. La meilleure façon de contri-buer à une évolution souhaitable de notre système de soinsest de rappeler, aussi souvent que nécessaire, les fonde-ments de la clinique et de l’éthique médicale. Il appartientaux soignants, qu’ils soient médecins, infirmiers ou théra-peutes, de contribuer activement à ces changements pouren dessiner les contours et en moduler le devenir. Il s’agitd’exiger le respect des règles de bonnes pratiques médico-

soignantes avec son corollaire: une documentation cli-nique précise et complète. Pour répondre aux exigencesmédicales scientifiques, juridiques et éthiques, un systèmed’information médico-économique doit intégrer les infor-mations cliniques et administratives, identifier et quanti-fier les actes médico-soignants et tracer les produits thé-rapeutiques et les implants. Ces informations doivent être«orientées patients», sans séparer l’hospitalier de l’ambu-latoire. De même, il est indispensable d’utiliser partout,dans tous les domaines médicaux et économiques de l’ac-tivité sanitaire et à l’échelon national, les mêmes langages(dictionnaires, nomenclatures, classifications, normes decomptabilité, etc.). Le déploiement de systèmes d’informa-tions répondant à ces exigences constituera un avantagestratégique pour les établissements qui auront su s’en do-ter. En effet, les interrelations et les niveaux d’intricationde notre système de santé sont tels que la concurrence quiva s’exercer entre les hôpitaux ne se limitera pas à une listede prix établie sur un catalogue de prestations et destinéeà convoiter le chaland. Cette concurrence sera fondée surdes paysages de données complexes, destinées aux parte-naires tarifaires et aux offices fédéraux, que seuls des sys-tèmes d’informations sophistiqués et intégrés pourront gé-nérer et livrer à l’analyse et à la connaissance du public.L’avenir de notre système de soins et la réussite des chan-gements voulus par notre majorité démocratique sont au-jourd’hui entre les mains de ceux qui, avec le leadershipdes cliniciens et l’appui des gestionnaires, sauront déve-lopper et faire vivre les systèmes d’informations.

RemerciementsNous tenons à remercier pour son aide dans la rédactionde cet article le Dr Peter Rohner PD (HUG/DAME).

Références

1 Fetter RB, Freeman JL, Mullin RL. DRGs: how they evolved and are chan-ging the way hospitals are managed. Pathologist. 1985;39(6):17–21.

2 Busato A, von Below G. The implementation of DRG-based hospital reim-bursement in Switzerland: A population based perspective. Health Re-search Policy and Systems 2010;8:31.

3 Farsi M, Filippini M. Effects of ownership, subsidization and teaching ac-tivities on hospital costs in Switzerland. Health Econ. 2008;17(3):335–50.

4 Saleh SS, Callan M. Trends in Medicare disproportionate share (DSH) dis-tribution in US hospitals: 1996–2003. J Health Care Finance.2006;33(2):70–83.

5 Symposium de la Commission Nationale d’Ethique et de l’AcadémieSuisse des Sciences Médicales, 10 juin 2009, Inselspital, Berne, Econo-micisation de la médecine? L’introduction des DRG dans les hôpitauxsuisses – un défi éthique.

6 Brauer S. Introduction de forfaits par cas liés au diagnostic dans les hô-pitaux suisses. Bulletin des médecins suisses. 2008;89:36.

7 Arendt H. Le totalitarisme et le monde contemporain, Presses UniversitéLaval, 2003, P. 410.

8 HUG, règlement des services médicaux. Article 95 sur la tenue du dossierdu patient. Version 3.0 publiée le 12/05/2004.

Swiss Medical Informatics 2011; no 71

Page 13: Swiss Medical Informatics - SMI 71

DRG

12

Summary

In this paper we present the solution we devised to remedythe absence of the complete dictionaries in French neededto code our clinical discharge documents using the newSwissDRG system. We reconstructed the missing alphabet-ic index from a French ICD10 OMS version associated withtranslations of the German ICD10 changes made since theschism that occurred in 2000. We then integrated the dic-tionaries needed to code into a wiki-like system. This newsystem delivered the level of information and agility need-ed to work with the new SwissDRG coding system. It hasalso provided a useful tool to boost quality and productivitywithin our coding team. In the near future we hope to shareour work with other hospitals.Key words: CIM10-GM; CHOP; Wiki; SwissDRG; dictionar-ies.ACM: H.3.6 library automation, large text archives; I.7.2document preparation, hypertext/hypermedia.

Introduction

Rappelons que les APDRG (All Patients Diagnoses RelatedGroups) sont un mode de remboursement des hôpitauxbasé sur leurs activités. Les systèmes DRG ont été intro-duits aux Etats-Unis en 1983 pour le financement dessoins. Utilisés dans la plupart des pays occidentaux, cessystèmes doivent fournir un outil pour la gestion de l’hô-pital censé favoriser la rationalisation des investissementset une meilleure maîtrise des coûts. Ils doivent aussi per-mettre la comparaison inter-établissements (benchmar-king). L’intérêt supplémentaire de ce mode de rembourse-ment est d’être basé sur les données médicales du patientet donc de tenir compte du coût du traitement, contraire-ment au forfait journalier [1].Introduits et testés en Suisse en 1998, le succès du projetAPDRG a incité les autorités et partenaires sanitaires à lan-cer un nouveau projet de recherche et de développement,SwissDRG 2004–2007. Ce projet avait pour ambition depoursuivre la réflexion sur le financement des hôpitaux etd’identifier les solutions les plus judicieuses pour la Suissedans le futur. Il aboutit à la fondation de la SwissDRG-SAle 18 janvier 2008 qui propose un nouveau mode de calculdes DRG basé sur le modèle des Allemands. L’introductiondes SwissDRG dans toute la Suisse aura lieu au premierjanvier 2012.

Le critère principal pour la classification d’un patient dansun groupe de pathologie est le diagnostic principal. Les au-tres caractéristiques de classification sont les diagnosticssupplémentaires, les procédures, l’âge, le type de sortie del’hôpital, le degré de sévérité, le poids à la naissance (chezles nouveau-nés) et d’autres facteurs. La classificationd’une hospitalisation dans un DRG est effectuée par un lo-giciel de regroupement (ou «groupeur»). Le montant dechaque forfait par cas SwissDRG est ensuite calculé sur labase des coûts effectifs des hôpitaux suisses. [2]

Problématique

Le système SwissDRG est une instanciation du systèmeGerman DRG (G-DRG) piloté en Allemagne par l’InstitutAllemand pour le Système de Tarification HospitalierProspectif (InEK). Afin de pouvoir calculer la valorisationexacte des DRG construits spécifiquement pour la Suisse,les Hôpitaux Universitaires de Genève (HUG) ont acceptéavec le Centre Hospitalier Universitaire Vaudois (CHUV)de servir de sites pilotes en Romandie pour la constructiondes SwissDRG. En pratique il s’agit, depuis le premier jan-vier 2009, de coder les séjours en utilisant les diction-naires et les règles qui seront imposées à l’ensemble deshôpitaux au premier janvier 2012. Le système d’informa-tion se chargeant de collecter les informations nécessairesà SwissDRG-SA et de les retransformer ensuite en codeAPDRG afin de pouvoir continuer à facturer selon les rè-gles de ce système, en vigueur jusqu’au trente et un dé-cembre 2011.Les dictionnaires nécessaires au codage sont au nombrede deux. Il s’agit de la classification internationale des ma-ladies (CIM) pour les pathologies (ou diagnostics) et de laclassification Suisse des opérations (CH-OP. ou CHOP) pourles interventions. Ces dictionnaires s’accompagnent d’unegrammaire sous la forme d’un manuel de codage édité parl’OFS [3] qui donne les règles de bonne pratique de l’emploi

Swiss Medical Informatics 2011; no 71

Wikicode, un outil rationnel pour permettre etaméliorer le codage SwissDRGRodolphe MeyerHôpitaux Universitaires de Genève, Direction de l’Analyse Médico-Economique

Correspondance:Rodolphe Meyer, MD, PhDMédecin Adjoint responsable du service DéveloppementsTechno-logiques et Systèmes DécisionnelsHôpitaux Universitaires de Genève – D.A.M.E.Rue Gabrielle-Perret-Gentil 4CH-1211 Genève [email protected]

Page 14: Swiss Medical Informatics - SMI 71

DRG

13

des dictionnaires et notamment des associations possiblesdes différents élémentsde ces dictionnaires. Comme l’avaitsouligné Anatole France: un dictionnaire, c’est tout l’uni-vers par ordre alphabétique. Dans le cas présent il s’agitde l’univers médical et à l’image de son homologue cos-mique c’est un univers en expansion. Les dictionnaires sevolumisent donc régulièrement et sont mis à jour, précisantici un point nouveau ou faisant disparaitre là un conceptobsolescent.En ce qui concerne le passage aux SwissDRG, noussommes dans une démarche de bascule vers un universparallèle. Le système APDRG utilisait la CIM dans sa ver-sion 10 sous responsabilité OMS. Nos amis allemands ontsouhaité quitter le système international en janvier 2000et ont publié leur version de la CIM10-OMS rebaptiséed’abord CIM10-SGBV puis CIM10-GM (German modifica-tion) en 2004. Cette version, adaptée au système de santéallemand est de plus en plus éloignée de celle de l’OMS et

Swiss Medical Informatics 2011; no 71 13

est placée sous la responsabilité de l’Institut Allemand deDocumentation et d’Information Médicale (DIMDI) [4].Leur argument est pragmatique: se focaliser surtout surles pathologies rencontrées en Allemagne. En adoptant lesystème allemand, la Suisse a aussi adopté les diction-naires allemands. Rien de grave à priori, sauf que le fran-çais, contrairement à la démarche l’OMS, n’est pas unelangue officielle du DIMDI et qu’il fallait donc traduire laCIM10-GM en français et en italien pour pouvoir généra-liser le système SwissDRG à toute l’Helvétie. Le tableau 1donne une synthèse des dictionnaires nécessaires au co-dage avec une vision calendaire.Comment fonctionne un codeur professionnel? Il lit une let-tre de sortie ou un compte-rendu opératoire et le traduiten code CIM ou CHOP. Il applique les règles de grammairedu manuel de codage et voilà le RSS (résumé standard desortie) transformé en code interprétable par le groupeuret donc facturable. Il rencontre donc des termes médicauxqu’il ne connait pas toujours par cœur et cherche dans l’in-dex alphabétique le code de ce mot qu’il reporte dans lapartie systématique afin de vérifier que le contexte est bonet que ce code ne possède pas de règles d’exclusions oud’associations obligatoires; informations n’existant pasdans l’index alphabétique.Par ex., si on cherche à coder le RSS d’un patient atteintd’une abaresthésie, il est impossible de retrouver ce diag-nostic dans la GM2008 systématique car l’entrée n’est pré-sente que dans la GM2008 alphabétique et renvoi au codeR44.8 «Symptômes et signes relatifs aux sensations et auxperceptions générales, autres et non précisés». La situa-tion est d’ailleurs la même en allemand et, à moins desavoir que l’on parle de «Sinnesfunktion Verlust» ou de«Störung Wahrnehmung» dans l’alpha allemande pourpouvoir faire le lien avec la systématique en français, cediagnostic sera incodable.L’index alphabétique est donc indissociable de la partiesystématique. On perçoit que le dictionnaire, machine à rê-ver selon Roland Barthes, peut se muter en cauchemarlorsqu’il est incomplet. C’est la situation dans laquelle leshôpitaux romands se sont retrouvés en 2009 lorsque, sou-haitant participer à la construction des SwissDRG en 2009,ils ont constaté que le dictionnaire CIM10-GM 2008 ne pos-sédait pas son index alphabétique traduit en français … LaSwissDRG-SA a été saisie du problème en fin d’année2008, mais il restait important pour les HUG de débuterl’année 2009 avec le nouveau système afin de ne pas êtreexclus des analyses de case mix permettant les calculs desfuturs des DRG. Négligée tout d’abord, ou mal comprise,cette demande a été ensuite prise en compte après une ren-contre animée avec les membres du conseil d’administra-tion de SwissDRG-SA. Toutefois, en attendant la livraisonde l’index, une solution d’attente efficiente était indispen-sable pour démarrer le codage 2009.Le tableau 2 donne une idée de la disponibilité des diffé-rents dictionnaires à un temps t.

Figure 1Chaine de codage aux HUG.

Tableau 1Version des dictionnaires nécessaires au codage SwissDRG.

Dictionnaire 2009 2010 2011 2012

CIM10-GM 2008 2008 2010 2010 ?

CHOP 11 11 2011 2011 ?

Manuel de codage V2 V3 V3 V3 ?

? = les versions des dictionnaires prévus pour 2012 sont sujettes à modifica-tions

Tableau 2Disponibilité des dictionnaires en français.

Dictionnaire 2009 2010 2011

CIM10-GM 2008 – Alpha NON NON* OUI

CIM10-GM 2008 – Systématique OUI OUI OUI

CIM10-GM 2010 – Alpha NON NON NON**

CIM10-GM 2010 – Systématique NON OUI OUI

CHOP 11 – Alpha OUI OUI OUI

CHOP 11 – Systématique OUI OUI OUI

CHOP 2011 – Alpha NON NON OUI

CHOP 2011 – Systématique NON OUI OUI

Manuel de codage v2 OUI OUI OUI

Manuel de codage v3 NON OUI OUI

(*) l’index alpha 2008 n’a vu le jour qu’en novembre 2010(**) l’index disponible en ligne est celui de 2008 avec un addendum pour 2010

Page 15: Swiss Medical Informatics - SMI 71

DRG

14Swiss Medical Informatics 2011; no 71

Figure 3Exemple de delta avec ajout de vocabulaire et d’association obligatoire.

Figure 2Exemple de delta avec ajout de vocabulaire et changement de numéro.

Page 16: Swiss Medical Informatics - SMI 71

DRG

15

Matériel et méthodes

Identifier les changementsPour pouvoir coder en 2009 selon les normes SwissDRGnous avions donc (voir tab. 2) à notre disposition tous leséléments nécessaires à l’exception de l’index alphabétiquede la CIM10-GM 2008 en français. Cette partie du diction-naire était toutefois disponible en allemand. Malheureuse-ment les codeuses et codeurs des HUG ne maitrisent passuffisamment les deux langues pour pouvoir jongler sansinquiétude de RSS en français vers un index en allemandpuis retour vers une liste systématique en français. La qua-lité et la quantité du travail risquaient d’en souffrir et parconséquence la facturation aussi.Nous n’avons pas non plus souhaité continuer à utiliserl’index de la CIM10-OMS avec la partie systématique de laGM2008 pour des raisons de cohérence. La GM s’étantéloignée depuis dix ans de l’OMS il nous apparaissait ris-qué de choisir un index démodé au vu la nouvelle structurede la GM2008 et ainsi de s’exposer à des erreurs de codageou de groupage.Nous avons donc choisi de mesurer le delta entre la CIM10-OMS et la GM2008, selon le postulat que ce delta ajouté àl’alpha de l’OMS nous donnerait l’index alpha de laGM2008 ( CIM10-OMS + = GM2008) sans être obligés dese lancer dans un fastidieux travail de traduction intégralepour lequel nous n’étions ni mandatés ni financés. D’au-tant que nous aurions retraduit au passage les 85% de l’al-pha qui n’avaient pas changés entre les deux versions lin-guistiques.Gardons à l’esprit que ce delta devait prendre en comptenon seulement le vocabulaire nouveau ou modifié maisaussi les codes numériques. Car en changeant de versionle DIMDI a modifié la structure du dictionnaire et ajouté ousupprimé des codes pour leur usage spécifique.Nous avons ensuite recensé sur le site du DIMDI [4] tousles deltas historiques depuis le schisme de 2000 et lesavons traduits et intégré à notre version de l’alphabétiqueen français basée sur la CIM10-OMS. Pour confirmer cesdeltas et vérifier notre méthode, nous avons reconstruit pa-rallèlement les deltas à partir des documents téléchargea-bles en utilisant un logiciel de comparaison textuelle im-

plémenté par nos soins en interne. Ceci afin d’être certainde ne rien oublier. Ces différents travaux ont pu bénéficierd’un certain niveau d’automatisation par programmationmais ont été fortement soumis à des vérifications et saisiesmanuelles.

Rendre l’information disponibleUne fois le dictionnaire reconstruit dans la bonne langueil a été nécessaire de le mettre à disposition des codeurs.Là encore, plusieurs options étaient possibles dont l’im-pression papier et/ou le document dématérialisé dans unformat classique (txt, rtf, doc, docx, pdf, etc.) comme pro-posé par le DIMDI ou l’OFS. Toutefois, les différents dic-tionnaires officiels ne sont pas exempts d’imperfections. Ilpersiste des entrées en allemand, des traductions impar-faites, des erreurs de codes, des erreurs de hiérarchie etdes oublis. Il est donc souvent nécessaire de les corriger,après un avis référent OFS, ou de les mettre à jour et decommuniquer autour des changements ou des précisionsreçues.Afin d’être certains que l’information, la plus actualiséepossible, soit uniformément partagée par les équipes decodage nous nous sommes tourné vers la dématérialisa-tion des dictionnaires (CIM et CHOP) et leur mise en lignesous un format simple et convivial: le «wiki» (rapide enhawaiien). Ce wiki, baptisé Wikicode aux HUG, permet(tab. 3) de réaliser les mises à jour et de partager les cor-rections immédiatement (synchronicité). Il possède une in-terface connue de tous les internautes et simple à appré-hender pour les novices (ergonomie). Il est possible que lesutilisateurs ajoutent des commentaires (interactivité) ouqu’ils bloguent par thèmes. Les experts peuvent enrichir lesdictionnaires et signer leurs ajouts (enrichissement et tra-çabilité datée). L’ajout de tout type de documents complé-mentaires est prévue (multimédia). La recherche des mots,des expressions ou des codes est optimisée (efficience).Techniquement nous avons choisi MediaWiki [5] qui estun logiciel libre écrit en PHP et développé à l’origine (2002)par Magnus Manske pour Wikipédia [6]. Il est utilisé au-jourd’hui par de nombreux autres projets de l’associationà but non lucratif Wikimedia Foundation ainsi que par

d’autres sites reposant sur la techno-logie wiki, sous License GNU GeneralPublic License (GPL) [7]. C’est doncun environnement de travail libre dedroits et dont le code source est publicet modifiable. Il est hébergé sur lesserveurs Unix des HUG gérés par laDirection des Services Informatiques(DSI) en charge de la maintenancetechnique et des sauvegardes. L’en-semble des bases occupe un espaced’environ 0,5 Go par wiki. Chaquepage est enregistrée au format XMLet stockée dans une base de donnéesrelationnelle indexée. Les serveurssont doublés et répliqués pour s’assu-rer une qualité de service optimale.Afin d’améliorer les recherches nous

Swiss Medical Informatics 2011; no 71

Tableau 3Particularités de chaque format.

Domaine Papier Document électronique Wiki

Mise à jour A chaque édition A chaque édition Immédiate

Ergonomie Naturelle Simple Simple

Interactivité Nulle Nulle Importante

Enrichissement Nul Nul Possible

Multimédia Non Non Oui

Recherche Manuelle Séquentielle Optimisée & booléenne

Licences software Oui Oui Non

Cout RH expert MAJ. et veille MAJ. et veille MAJ. et veille

Cout RH technique Imprimeur Edition Edition

Cout technique Imprimerie + papier Licences + PC PC

RH: ressource humaine; MAJ.: mise à jour

Page 17: Swiss Medical Informatics - SMI 71

DRG

16

avons substitué le moteur de recherche initial par lesearch engine Sphinx qui est lui aussi en open source [8].

Résultats

Le projet a été initialisé au 2e semestre 2008 et après deuxannées de mise en production/construction (2009–2010)nous pouvons constater une adhésion complète de l’équipede codage au système. Le système a aidé à opérer trois vi-rages-étapes importants:– en 2009 la bascule vers le codage intégral en SwissDRG;– en 2009 la généralisation du codage (chaque codeur est

devenu compétant dans toutes les spécialités cliniquesen gardant un domaine d’expertise);

– en 2010 l’entrainement et le passage au manuel de co-dage version 3.

Au niveau des SwissDRG, l’analyse des DRG que nousavons atteints en 2009 nous permet de dire que nousn’avons pas souffert d’erreurs de groupage liées à une fai-blesse de notre documentation des cas, en termes de dic-tionnaires de codage.Concernant le contenu du wiki, les mises à jour (pilotéespar les experts) sont immédiates et permettent de limiterles réunions de briefing sur les changements. Les utilisa-teurs peuvent signaler des erreurs et demander des ajoutsselon une procédure simple suivant un rythme hebdoma-daire. Il est possible de s’abonner à certaines pages (ou àtout le wiki) et de recevoir ainsi un mail d’avertissement àchaque nouveauté ou seulement sur les domaines connuspar cœur et qui ne nécessitent pas toujours de consulterles dictionnaires. Ainsi un changement ne passe pas ina-perçu.En termes d’ergonomie nous avons souhaité conserver lelook-and-feel des dictionnaires d’origine afin que les utili-sateurs restent dans un environnement visuel familier(fig. 4), les exclusions sont signalées en rouge et les inclu-sions en bleu. Par ailleurs le fait que la CIM et la CHOPsoient réunies dans un même environnement augmente laproductivité.Un autre facteur de gain de productivité réside dans la pos-sibilité d’enrichir le dictionnaire initial de commentaires.Ils précisent certains points et permettent à l’utilisateur desavoir que ce n’est pas une information contenue dans laversion originale (encadré de la fig. 4) mais aussi de savoirqui l’a ajoutée et quand, facilitant les analyses qualité. En-fin les exclusions et les codes dague-étoile sont construitsavec un hyperlien qui renvoi automatiquement vers le bonchapitre en un clic. Le wiki est enrichi par des fiches tech-niques possédant des croquis et des photos ainsi que desnotes de services et des notes officielles pour compléter leniveau de connaissance rationalisé des équipes. Ces fichessont réalisées par le codeur référent d’une spécialité sousla supervision des experts et en lien avec les cliniciens dudomaine.La fusion des index alphabétiques et des dictionnaires sys-tématiques permet des recherches plus rapides et plusriches d’informations. Le wiki permet des recherches boo-léennes avec des opérateurs simples (AND, OR, NOT, EXACT,MINUS, etc.). Le moteur tronque les pluriels, ne prend en

compte ni la casse ni les accents, facilitant d’autant les re-cherches.Une possibilité, non négligeable, offerte par le système estde pouvoir aussi effectuer des recherches directement surles codes ce qui rend les opérations de contrôle et d’exper-tise (qualité, retour assurantiel, etc.) plus rapides.

Limites et perspectives

Une des limites de ce type d’environnement réside dans lemoteur de recherche. Ce n’est pas celui de Google et il n’estdonc pas aussi tolérant et puissant. Les mots trop mal or-thographiés sont ignorés et il n’y a pas de base sémantiqueni d’outil d’auto-complétion. On pourrait y ajouter du vo-cabulaire SKOS (simple knowledge organization system)qui a pour but la modélisation et la mise à disposition selonle principe de RDF (resource description framework) desthésaurus, taxonomies, glossaires et autres vocabulairescontrôlés [9–11]. Ces améliorations sont souhaités et sou-haitables et constituent nos futurs objectifs de travail as-socié à une réflexion sur la création d’une ontologie du do-maine.Par ailleurs les codeurs et codeuses qui ont travaillé pen-dant plus de six ans aux HUG uniquement sur des docu-ments papier ont du mal à s’en passer totalement. Le pa-perless total est toujours difficile à mettre en place. Ilsimpriment encore les RSS pour les annoter et certainsconservent des dictionnaires imprimés comme autant«d’objets transitionnels» au sens psychologique.Une autre limite concerne les changements majeurs destructure. Le passage de la version 11 à la version 2011 dela CHOP voit arriver environ 8000 nouveaux codes et laCIM10-GM 2010 renferme environ 5600 modificationsplus ou moins majeures. Il sera donc nécessaire de main-tenir un wiki (historique) pour le codage 2009–2010 et unwiki pour le codage à partir de 2011. La fusion des deuxest possible mais engendrerait beaucoup de confusion à lalecture et à la recherche.Concernant le manuel de codage v3, il est intégré dans lewiki sous la forme d’un document indexé mais n’est pasfusionné. C’est une grammaire et non un dictionnaire,nous avons choisi de le laisser hors texte.Il est tout à fait possible d’installer le wiki sur des ordina-teurs non reliés à un réseau. Des versions locales (typeclient lourd) sont déployées mais elles ne bénéficient pasautomatiquement des mises à jour du serveur. Il faut réa-liser les mises à jour manuellement à échéance régulière.Il est tout à fait possible de déployer aussi le wiki sur d’au-tres plateformes du type Mac, iPhone, iPad et Android.Nous travaillons enfin sur la mise à disposition du wiki versdeshôpitaux partenaires en Romandie, soit depuis nos pla-teformes soit en le déployant sur des plateformes locales.

Conclusions

Dans ce travail nous avons montré une méthode de travailqui nous a donné la possibilité de basculer vers le systèmeSwissDRG dès le premier janvier 2009 dans de bonnes

Swiss Medical Informatics 2011; no 71

Page 18: Swiss Medical Informatics - SMI 71

DRG

17Swiss Medical Informatics 2011; no 71

Figure 4Aspect, commentaires et hyperliens.

Figure 5Exemple de recherche sur texte exact.

Page 19: Swiss Medical Informatics - SMI 71

DRG

18

conditions. Notre démarche nous a fourni les dictionnairesnécessaires au codage et au groupage de façon la plus op-timale possible en fonction du contexte et des incertitudesde l’époque. Cela ne nous a pas empêché de défendre laposition des hôpitaux romands sur la nécessité d’obtenirdes organismes officiels les dictionnaires nécessaires aucodage, car notre projet restait expérimental et difficile àconstruire en dehors d’une structure comme un hôpitaluniversitaire à fort niveau d’intégration informatique. Par-tant du principe héraclitien qu’il n’y a de chose perma-nente que le changement, nous avons mis en place un en-vironnement peu couteux, partagé et extrêmement agilequi a fédéré un effort collectif de construction. Cet inves-tissement surtout humain étant maintenant réalisé, nouspensons en récolter les fruits dans les années qui viennentet souhaitons en faire profiter nos partenaire Romands quien feraient la demande.

Remerciements

Nous tenons à remercier pour leur travail lors de laconstruction de ce projet: Julien Aigle, Jérome Billet(HUG/DSI), Jean Dupraz (HUG), Mayane Levy, GregorySchopfer, Nina Taillard et Charlotte Verolet (HUG/CMU).

Pour leur aide à l’amélioration des dictionnaires: HélèneCailbeaux (HUG/DAME), Jean-Jacques Chale (HUG/DAME), Phedon Tahintzi (CHUV/HUG), Anne-marie Zogg(HUG/DAME) et toute l’équipe des codeurs des HUG. Pourleur soutien financier et leur confiance le Pr Antoine Geiss-buhler (HUG/DIMIM) et Mme Brigitte Rorive-Feytmans(HUG/DAME).

Références

1 ApDRG SUISSE, Institut de santé et d’économie (ISE): http://www.ap-drgsuisse.ch/ en ligne janvier 2011.

2 SwissDRG-SA, http://www.swissdrg.org/fr/ en ligne janvier 2011.3 Office Fédéral de la Statistique, http://www.bfs.admin.ch/ en ligne jan-

vier 2011.4 DIMDI, http://www.dimdi.de/ en ligne janvier 2011.5 Mediawiki, http://www.mediawiki.org/wiki/MediaWiki en ligne janvier

2011.6 Wikimedia Foundation, http://wikimediafoundation.org/wiki/Home en

ligne janvier 2011.7 GNU, http://www.gnu.org/home.fr.html en ligne janvier 2011 en ligne

janvier 2011.8 SPHYNX search server, http://sphinxsearch.com/ en ligne janvier 2011.9 Semantic Mediawiki, http://semantic-mediawiki.org/wiki/Semantic_

MediaWiki en ligne janvier 2011.10 Simple Knowledge Organisation System, http://www.w3.org/2004/02/

skos/ en ligne janvier 2011.11 Resource Description Framework http://www.w3.org/RDF/ en ligne

janvier 2011.

Swiss Medical Informatics 2011; no 71

Page 20: Swiss Medical Informatics - SMI 71

DRG

19

Summary

Depending on one’s point of view, the introduction of DRGmerely involves another payment system or a dangerouschange in the care of our patients. Besides this somewhatpolitical view, information management will need to definethe influence of the new payment approach on document-ing processes in healthcare institutions. There is no doubtthat documentation needs and the need for quality im-provements, both in terms of documentation and in med-ical terms, will increase in the near future. However, weshould not lose sight of the mainstay of documentation in,for example, hospitals: the primary process of caring forpatients. It is this primary process that needs to be sup-ported in the most appropriate manner, and thus the maingoal should not be documentation for DRG’s sake. Thus,information with impact on DRG calculation should ideally,whenever possible, be seamlessly generated during docu-mentation processes. As applied in Thun Hospital, meth-ods including semantic interpretation, process adaptationand functional integration are presented to calculate, forexample, real time DRG without the primary focus beingon DRG but – as is far more important – on documentationdealing with medical treatment.Key words: Diagnosis Related Group; information system;electronic patient record

Einleitung

Obwohl nur wenig Literatur zum Thema der notwendigenAnpassung von klinischen Informationssystemen im Hin-blick auf die DRG(diagnosis-related-groups)-Einführungpubliziert ist, gehen die meisten Fachleute davon aus, dasselektronische Patientenakten eine conditio sine qua nonsind, um verlässlich und effizient zu den kodier-relevantenInformationen zu gelangen [1–3]. Es ist keine Frage, dassdas für die Schweiz weitgehend neue (es gibt immerhinzahlreiche Spitäler, die z.T. seit Jahren schon mit DRGkalkulieren) Abrechnungssystem den Druck auf eine öko-nomische Führung der Spitalprozesse erhöhen wird [4].Effizientere Leistungserbringung, Reduktion unnötigerLeistungen und Verkürzung der Aufenthaltsdauer ohneVerlust in der Qualität der medizinischen Dienstleistung –und theoretisch auch ohne Verlust der Arbeitszufrieden-heit der Mitarbeiter und Zufriedenheit der Patienten – wä-ren die Ziele der Fallpauschalen-Regelung, die DRG mitsich bringt [5]. Die Geister scheiden sich bei der Frage, obdas DRG-System – unabhängig vom jetzigen Einführungs-zeitpunkt in der Schweiz – revolutionär, gefährlich oder

einfach ein etwas anderes Abrechnungssystem ist. Ziel desvorliegenden Artikels ist es nicht, diese Streitfrage zu erör-tern, sondern aufzuzeigen, wie sich die Vorbereitungen inder Spital STS AG, die seit Jahren als Netzwerkspital imRahmen der DRG-Einführung funktioniert, gestaltet habenund gestalten, dies in der Annahme, dass das Abrech-nungsmodell ab 2012 tatsächlich zum Einsatz kommenwird.

Grundlagen

Getrieben durch die Umsicht und die Überzeugung vorabdes früheren internistischen Chefarztes, wurde bereits inden Neunzigerjahren, und damit deutlich vor der Einfüh-rung von klinischen Informationssystemen, damit begon-nen, eine konsequente Prozessgestaltung nach dem Motto«people follow structure follow process» umzusetzen. Dasführte unter anderem dazu, dass der damals übliche«quick-and-dirty» Aufnahmeprozess von Notfallpatien-ten, mit anschliessend sorgfältiger Zweituntersuchungund -einschätzung auf der internistischen Station, verlas-sen wurde. Stattdessen wurde die Notfallstation zu einerregelrechten Aufnahmestation umfunktioniert, deren Zieles noch immer ist, den Patienten ausführlich mittels An-amnese, Status sowie umgehend durchgeführten Untersu-chungen zu beurteilen, eine möglichst definitive Diagnosezu stellen und die weiteren Therapie- aber auch Abklä-rungsschritte für die nächsten Tage zu definieren und aucheinzuleiten. Um den weiteren Verlauf effizient gestalten zukönnen, wurde eine neue Berufsgruppe, die sogenanntenCoaches (ehemalige Pflegefachkräfte) etabliert, deren pri-märes Ziel die optimale Betreuung des Patienten und des-sen Prozesses während des Spitalaufenthaltes ist. Die Aus-trittsplanung beginnt beim Eintritt, erst Recht, wenn eineRückkehr nach Hause schon zu Beginn der Hospitalisationfraglich ist. Bereits da wurde der Grundstein für eineschwergewichtig interdisziplinäre Arbeitsweise gelegt, diein der Folge an Bedeutung und an Abbildungsnotwendig-keit zunahm. Aus heutiger Sicht kann diese Umstellungdurchaus als Wegbereiter ins DRG Zeitalter verstandenwerden.

DRG und klinisches Informationssystem:primum nihil nocere!Marc OertleMedizininformatik, Spital STS AG, SpitalThun

Swiss Medical Informatics 2011; no 71

Korrespondenz:Dr. med. Marc OertleLeitender Arzt Medizin/MedizininformatikKrankenhausstrasse [email protected]

Page 21: Swiss Medical Informatics - SMI 71

DRG

20

Basis: die elektronische Patientenakte

Um die Prozesse so effizient wie möglich zu gestalten, sindeinerseits natürlich ablauftechnische Modifikationen vor-zunehmen, andererseits ermöglicht die elektronische Pa-tientenakte auch, völlig neue Abläufe zu definieren bzw. zuerstellen. Seit nunmehr zehn Jahren wird in Thun deshalbauch versucht, mit den vorhandenen Möglichkeiten deskommerziellen Produktes eines Klinikinformationssy-stems KIS, alle zentralen Elemente entweder im KIS abzu-bilden, oder aber Fremdsysteme derart tief zu integrieren,dass die Funktionsweise de facto einer einzigen Anwen-dung entspricht. Auf Redundanzen und Mehrfachsystemewird so wenn immer möglich verzichtet. Das hat zwar lang-wierigere Aufbauprozesse zur Folge, auf der anderen Seitewerden Kosten für die laufendenProgramme reduziert, derBetreuungsaufwand gebündelt, das interne Know-How ge-fördert und auch die Arbeitsabläufe schlank gehalten.Durch die konsequente und strategische Reduktion von(teil)redundanten Systemen gelingt es auch, die Spitalgrup-pe mit 16000 stationären und 40000 ambulanten Patien-tenfällen pro Jahr durch ein Team mit sieben Vollzeitstellenauf der Informatik und einer Teilzeitstelle auf der Medizin-informatik in einem 7/24 Konzept zu unterhalten und aus-zubauen.

Primum nihil nocere

Das Credo im Hinblick auf die Einführung des «neuen» Ab-rechnungssystems DRG bleibt innerhalb unserer Spital-gruppe im Wesentlichen dasselbe wie in den Jahren zuvor:derPrimärprozess imSpital, nämlichdiebestmöglicheVer-sorgung des Patienten, hat absoluten Vorrang. Dem musssich alles, auch DRG, unterordnen. Wenn dieser Primär-prozess effizient, qualitativ hochstehend und zur Zufrie-denheit aller Beteiligten abgehandelt und abgebildet wer-den kann, sollte die Finanzierung mit jedem beliebigenAbrechnungssystem erfolgreich durchgeführt werden kön-nen. Selbstverständlich dabei ist, dass das Abrechnungs-system selbst zu keiner Patientengefährdung führen kannoder führen darf.Entsprechend diesem Credo ist es auch das Ziel, nicht dieDokumentation dem DRG System unterzuordnen und imHinblick auf dessen Bedürfnisse auszugestalten, sondern –wie bei vielen anderen auswertungsrelevanten Prozessenauch – möglichst hohen Nutzen mit minimalem Aufwandund vor allem minimaler Beeinträchtigung der im Primär-prozess tätigen Berufsgruppen zu erreichen. Das erfordertallerdings eine transparente, durchgängige, interdiszipli-näre, strukturierte und teilautomatisierte Dokumenta-

tionsmöglichkeit in einem KIS. Doch gerade das ist ja dieStärke der elektronischen Variante der KG-Führung.Die Durchgängigkeit ist klassischerweise zum Beispiel imAnmelde- und Verordnungswesen zu finden. Die währendder mit WLAN-Unterstützung durchgeführten Arztvisitevorgenommene Anmeldung für eine Radiologieuntersu-chung landet innert Sekundenbruchteilen bei der MTRA.Auf Bestätigungsklick werden die Daten in die «worklist»der Modalität übernommen, im Hintergrund die nötigenEinstellungen der Geräte und die Vorbereitung der Lei-stungs- und Materialerfassung getätigt und nicht selten istder Patient aus der Untersuchung schon wieder zurück,bevor die 70-minütige Visite beendet ist. Dasselbe gilt sinn-gemäss für alle anderen Anmeldungsformen. Es ist selbst-verständlich, dass qualitative Aspekte mit einem medien-bruchfreien, elektronischen und strukturierten workflowwesentlich besser erreicht und kontrolliert werden könnenals bisher. Die qualitativen Nachweise werden nicht nur fürzukünftige DRG-Zwecke nötig, sondern auch für Bench-mark-Messungen mit anderen Institutionen oder fachspe-zifischen Statistiken. Zudem können die Daten natürlichauch im Datawarehouse analysiert werden und führen –unter Umständen auch im Sinne des data mining – zu einerkontinuierlichen Verbesserung der Arbeitsprozesse.Einen möglichst tiefen Grad an Interferenzen während derDokumentation zu erhalten steht nicht im Widerspruch zuDRG. Im Gegenteil: das Beispiel der semantischen Interpre-tation zeigt [6], dass – kaum wahrnehmbar für den Klinikerund ohne Einflussnahme des Kodierteams – eine recht gutereal-time-DRG-Berechnung vorgenommen werden kann.Der Arzt führt seine Problem- und Diagnoseliste weiterhinim Freitext – eine in Bezug auf Informationstiefe nach wievor unerreichte Dokumentationsart – und benötigt keinerleiKenntnisse von Kodierregeln (Abb. 1). Im Hintergrund (ca.2⁄3 der Fälle) oder mit gezielten Rückfragen (ca.1⁄3 der Fälle)erwartet die semantische Interpretation eine präzisierendeZusatzinformation. Nicht selten dient diese zudem dannnicht nur der Kodierung, sondern auch der Verbesserungder Freitextführung der Problemliste und damit wiederumauch der gesamten Behandlungskette bis zurück zum zu-weisenden Arzt. Die fortlaufende Anpassung der Problem-liste führt zueiner fortlaufendenAnpassungderDRG-Kenn-grössen, diese wiederum lassen lange bevor der Patient dasSpitalverlässterkennen,obessichumeinenInlieroderOut-lier handeln wird. Die Güte der mit dieser vergleichsweiseeinfachenund kaumstörendenMassnahmeerreichen lässt,zeigt Tabelle 1 anhand der Auswertung einer konsekutivenStichprobe von 100 Patientenfällen 2009. Zudem kann imSinne des Kollateralnutzens die gewonnene strukturierteInformation für weitere Einsatzgebiete genutzt werden,zum Beispiel im Bereich decision support.

Wie Abbildung 2 zeigt, werden durchdiese Massnahme ab dem ersten Ein-trag in der medizinischen Problem-liste die wichtigsten Kenngrössenden Aufenthalt betreffend dargestelltund dienen der allfälligen Steuerungdes Austrittsprozesses. Analysen ausDeutschland haben diesbezüglich ge-zeigt, dass es nicht zur befürchteten

Swiss Medical Informatics 2011; no 71

Abbildung 1Aus der Freitext-Diagnose wird mittels semantischer Interpretation direkt während der Dokumentation einICD-Code (oder mehrere) generiert und im Hintergrund für weitere Berechnungen/Verwendungen aufberei-tet.

Page 22: Swiss Medical Informatics - SMI 71

DRG

21

«blutigen Entlassung» kommt. Das Spital hat aktuell an ei-nem solchen Szenario weder im Hinblick auf die Behand-lungsqualität, noch in Bezug auf Patienten- und Zuweiser-zufriedenheit ein Interesse.Weitere Beispiele, bei denen der Primärprozess möglichstnicht beeinflusst werden soll, sind natürlich alle Formender Leistungserfassung oder des Leistungsnachweises(Tarmed, REKOLE, LEP etc.). Auch hier dient die Automa-tisation innerhalb der Krankenakte dazu, Kennzahlen oderLeistungen, die bisher manuell erfasst werden mussten, imHintergrund zu buchen. Trotz Verdichtung des Arbeitspro-zesses (häufig wegen DRG) und höheren Anforderungen andie Dokumentationsqualität (häufig aus medizinischen,versicherungstechnischen oder organisatorischen Grün-den) kann so die zeitliche Dimension der Krankenakten-führung zumindest nicht unnötig erhöht werden. In derSpital STS AG fielen bis 2009 z.B. insgesamt 8000 Stunden

Dokumentationsaufwand für die Erfassung von LEP-Varia-blen (Leistungs-Erfassung in der Pflege) an, ein Aufwand,der aktuell ohne Einbussen bezüglich erfasster Leistungs-minuten durch das Klinikinformationssystem vorgenom-men wird.Es gibt aber auch praktische Beispiele des «nihil nocere»,die weniger mit den Informationssystemen als mit organi-satorischen Aspekten zusammenhängen. So wäre aktuellz.B. für die Spitalgruppe der stete Wechsel auf das jeweilsaktuell günstigste Generikum eines bestimmten Medika-mentes kein Thema. Zu gross sind die Anpassungen, dieein solcher Wechsel quer durch alle Organisationen und Sy-steme der Spitalgruppe bringen würde, zu gross die Unsi-cherheit was die tägliche Arbeit von Pflegenden und ÄrztenmitdiesenMedikamentenbetrifft.Auchhierwirdundmussjeweils der komplette Prozess (z.B. eines Produktewech-sels) betrachtet und den reinen Einsparungen des Ein-

standspreises gegenübergestellt wer-den; erst wenn hier die Vorteile beiweitem überwiegen, wird sich einWechsel auch lohnen.Als weitere Massnahme der prakti-schen Art darf der Austrittsberichtgelten. Nicht selten wird dieser beiDRG-Häusern umfunktioniert zu ei-ner für das Kodierteam nützlichenAuflistung von kostenrelevanten In-formationen. Für uns nach wie vor imVordergrund steht aber klar die Funk-

tion des Austrittsberichts als Übermittler von Informatio-nen an nachgelagerte Fachkräfte, allen voran den Haus-arzt, aber natürlich auch andere Spitäler – oder sogar imFalle einer Rehospitalisation das eigene Spital. In dieserFunktionsindprimärdiemedizinischenBeurteilungenundTerminologien entscheidend und sollen auch so verwendetwerden. Nur die oft verwendete und an Detaillierungsgradder entscheidenden Information einer Terminologiestruk-tur weit überlegene Art der Freitextübermittlung bietet ak-tuell eine qualitativ hochstehende Weitervermittlung desmedizinischen Wissens. Damit die Kodierung – die schwer-gewichtig aber nicht ausschliesslich auf dem Austrittsbe-richt basiert – dennoch in erster «Lesung» auch kostenre-levante Informationen erhält, wird in einer gesondertenRubrik des Austrittswesens/-berichts eine mittels Trigger-faktoren zusammengesetzte «Kodierzusammenfassung»aus der Krankenakte generiert. Dadurch wird gewährlei-stet, dass der Arzt sich auf die medizinischen Inhalte kon-zentrieren kann – und in der Bearbeitung der Dokumenta-tion nicht ein zwangsläufig fragmentiertes DRG-Wissenmitführen muss – auf der anderen Seite wird auch Ansprü-chen der Kodierung Rechnung getragen. Zudem garantiertder Einsatz von standardisierten Trigger-Events währendderDokumentationaucheinuniformesBehandelnoderEr-kennen von bestimmten kodierrelevanten Informationendurch das Kodierteam. Dieses Miteinander von medizin-und kodierrelevanten Informationen ohne Übergewichtder DRG-Sicht ist eines der wesentlichen Leitmerkmale un-serer Umsetzung.

Swiss Medical Informatics 2011; no 71

Tabelle 1Anhand von 100 konsekutiven Patienten wird 2009 ein Vergleich zwischen den mittels semantischer Inter-pretation errechneten(*)Werten für LTP (low trim point), HTP (high trim point) und den definitiv durch dasKodierteam erstellten DRG (mit entsprechend folgender Definition der LTP und HTP) dargestellt. In 27 von100 Fällen kommt es zu einem identischen DRG zwischen semantischer Interpretation und dem Kodier-team.

LTP errechnet* LTP HTP1 HTP1 HTP2 HTP2definitiv errechnet* definitiv errechnet* definitiv

Mittelwert (Tage) 3,3 ± 0,7 3,3 ± 1,0 16,3 ± 7,6 19,7 ± 7,3 31,7 ± 19,0 39,4 ± 18,2

Abbildung 2Mittels semantischer Interpretation generierte ICD-Codes werden lau-fend zusammen mit verfügbaren CHOP-Codes für eine real-time DRGBerechnung verwendet.

Page 23: Swiss Medical Informatics - SMI 71

DRG

22

Weitere und zumTeil offeneAnforderungenan die Informationssysteme

Auch, aber nicht nur, im Zusammenhang mit DRG werdenimmer weitergehende Anforderungen an die Dokumenta-tion und Kontrolle der Arbeitsprozesse gestellt. So werdenimmer mehr Qualitätsparameter definiert, die Prozess-und Ergebnisqualität beurteilen sollen. Dies manuell zu er-fassen wäre nicht nur fehleranfällig, sondern auch aufwän-dig, ein Abbild in der ePatientenakte entsprechend unum-gänglich. Gerade SwissDRG wird ja qualitative Aspekte indie DRG-Entgeltung einbringen wollen, was eine entspre-chende Dokumentation erfordert.Dasselbe wird für die sinnvolle Abbildung klinischer Pfadegelten. Diese werden aktuell in unserer Spitalgruppe nursehr selektiv angewandt. Nur wo sinnvoll und nahtlos im-plementierbar, aber auch kohärent – auch bzw. vor allemaus medizinischer Sicht – kontrollierbar, wird der Nutzeneiner Pfadabbildung auch im Vordergrund stehen.Die Rahmenbedingungen, die DRG mit sich bringt, führenauch zwangsläufig zu Anforderungen an die Systemland-schaft. Redundanzen – von der Lizenzierung über die War-tung bis zur Nutzung – werden immer weniger tolerierbar,die nahtlose Implementation der miteinander funktionie-renden Systeme immer wichtiger. Das hat für das Beschaf-fungswesen der Spitalgruppe immer mehr Bedeutung, lei-derhabennochnichtalleHerstellervonmedizintechnischenoder medizininformatischen Produkten diesen Schritt voll-zogen und beharren oft noch zu stark auf proprietäremFunktionieren, das in der aktuellen Systemlandschaft nichtmehr akzeptabel und auch nicht mehr zeitgemäss ist.Darüber hinaus wird der Fokus auf interinstitutionelle Ko-operation im DRG-Zeitalter wichtiger werden als heute.Dies einerseits, weil Behandlungsketten etabliert und ge-nutzt werden müssen, andererseits, weil Qualitätsanforde-rungen (Stichwort: Minimalzahlen, z.B. Brustzentren) ein«Miteinander» fordernwerden.Diesbezüglichgilt esnatür-lich die eigene Institution noch stärker interoperabel zumachen, auf der anderen Seite besteht auch hier für dieSoftwarehäuser eine Anforderung, Ihre Produkte primärinteroperabel zu gestalten und auf die verteilte Datengene-rierung und -haltung vorzubereiten.

Start 2012?

Nach wie vor ist – in Anbetracht der politischen und stan-despolitischen Vorstösse – nicht vollständig klar, ob derStart ins DRG-Zeitalter für alle am 1. Januar 2012 definitiverfolgen wird. Es ist allerdings zu befürchten, dass es inAnalogie zur Einführung des Tarmed, viel zu spät zur pro-duktiven Nutzung aller Systeme und deren Implementationkommen kann. So gibt es schon jetzt Anbieter von Admini-strativsystemen, die versuchen, ihr eigenes Produkt als ein-zig gangbaren Weg bei der Verrechnung nach Swiss-DRG– unter Berücksichtigung der unsäglichen Fallklammern –zu vermarkten und wiederum auf eine rein proprietäre Lö-sung setzen wollen. Der Markt wird das mittelfristig sicherabstrafen, kurzfristig wird aber unnötigerweise viel Auf-wand von Seiten der Spitäler generiert, der primär auf Ko-

sten der Leistungserbringer und indirekt der Kranken-kassen geht. Bei Konstrukten wie den Fallklammern fürRe-Hospitalisationen besteht zudem die Gefahr, dass dieseungenügend durchdacht und nur mit Mühe sinnvoll abzu-bilden sind, sowohl im medizinischen wie auch im techni-schen Sinn. Diesbezüglich sollte man eigentlich erwarten,dass die globale Sicht, die sich die Spitäler zulegen müssen,um den Patientenprozess effizient und qualitativ hochste-hend zu gestalten, auch von den beteiligten Akteuren aufSeiten der DRG-Rahmenbedingungen eingenommen wirdund mit dem Motto «primum nihil nocere» auch hier ver-sucht wird, eine möglichst gut abbildbare und nachhaltigeÄnderung im Abrechnungssystem des Gesundheitswesenseinzuführen. Die Sicht darf dabei nicht nur die reine Defi-nition betreffen, sondern muss auch die Praktikabilität undVerfügbarkeit von möglichen Lösungen einschliessen. Nureben: die Partikularinteressen und -sichten überwiegen lei-der auch hier und es ist erneut zu befürchten, dass (zu) we-nig durchdachte Forderungen wiederum in letzter Minutezu aufwändigen Anpassungen im administrativen Patien-tenprozess führen werden, dies mit negativem Impact aufdie Güte des Gesamtprozesses.

Konklusion

Der produktive Abrechnungsprozess unter DRG führt zu ei-nem erhöhten Bedarf an detaillierter, strukturierter und in-terdisziplinärer Dokumentation. Der Hauptfokus und auchder Hauptnutzen für die Gesundheitsinstitutionen und dasGesamtsystem Gesundheitswesen Schweiz liegt dabei wohlnicht primär im Abrechnungsmodell, sondern in den da-durch in Angriff genommenen Änderungen von Arbeitsab-läufen. Es sind denn auch diese Prozesse, die im Vorder-grund stehen sollen, der Primärprozess: die Behandlung desPatienten. Wenn das Ziel erreicht wird, diesen Prozess opti-mal mit Informationsmitteln zu unterstützen und zu doku-mentieren, folgt daraus im Sinne eines hochwertigen Ab-fallproduktes auch eine zeitnahe und gute Abrechnung.Zweifelsohne können in allen Gesundheitsinstitutionen Ab-läufe optimiert, die Qualität gesteigert und auch Kosten ein-gedämmt oder gar reduziert werden. Der Fokus soll dabeiaber auf dem Patienten und seiner Behandlung bleiben undnichtdurchden(einfacheren)FokusDRGverdrängtwerden.

References

1 Reng CM, Tege B, Reicherzer HG, et al. Use of computer applications tosupport clinical processes. An electronic letterof discharge as resource forDRG-relevant coding. Med Klein. (Munich). 2004;99(9):548–56.

2 Suzuki T, Yokoi H, Fujita S, et al. Automatic DPC code selection from elect-ronic medical records: text mining trial of discharge summary MethodsInf Med. 2008;47(6):541–8.

3 Aardal S, Berge K, Breivik K, Flaatten HK, et al. Medical records, DRG andintensive care patients. Tidsskr Nor Laegeforen. 2005;125(7):903–6.

4 Hoelzer S, Hergeth C, Schmidt C. Arbeiten im Hinblick auf ein leistungs-gerechtes Abgeltungssystem spitalstationärer Leistungen. Schweiz Ärzte-zeitung. 2010;91:15: 578–9.

5 Fürstenberg T, Zich K, Nolting HD, et al. G-DRG Begleitforschung gemäss§ 17b Abs.8 KHG. Endbericht des ersten Forschungszyklus 2004-2006.IGES Institut GmbH. März 2010. www.gdrg.de. Letzter Zugriff 20.10.2010

6 Oertle M. Natural language processing. Swiss Medical Informatics.2007;62:15–8.

Swiss Medical Informatics 2011; no 71

Page 24: Swiss Medical Informatics - SMI 71

DRG

23

Summary

Geneva University Hospital uses the diagnosis relatedgroup (DRG) as the cornerstone of its billing system. Con-ventional international use of DRG calculation is based ona list of diagnoses and interventions quoted in the patient’shospital discharge documents. In Switzerland we code theinformation using a German instantiation of the interna-tional classification of diseases (ICD10) with a dictionary ofacts and interventions called CHOP2011. The codes arechosen manually by professional coders from all the docu-ments accessible in our electronic health record (HER). Pa-tients who are more seriously ill tend to require more hos-pital resources than those who are less seriously ill, eventhough they may be hospitalised for the same reason.Recognising this, the diagnosis-related group (DRG) man-ual splits certain DRGs based on the presence of secondarydiagnoses for specific complications or comorbidities (CC).Comorbidities are of major importance when it is necessaryto compute the DRG of a particular hospital stay. Comor-bidities carry considerable weight in determining the rea-sonable length of hospitalisation and its cost. Some comor-bidities are frequently forgotten on the hospital dischargesummaries, being so common and easy to manage that doc-tors often neglect to mention them. However, it is possibleto recreate them from the hospital information system datawarehouse. In this paper we show that an alert can be cre-ated regarding urinary infections using automated diagno-sis from the EHR via a computer-aided decision supportsystem (DSS). Based on very strict biological results andprescribing criteria, in 2009 we were able to identify 606realurinary infectionswhichshouldhave figured inourdis-charge summaries but did not. After being included into thecoding process, 97 of these urinary infections influencedthe final outcome of the DRG, resulting in additional incomein 2009. This could mean an annual benefit of more thanCHF 160K per year using this type of alert system for thispathologyalone.On thisbasiswe intend toextend this studyto other comorbidities such as dyskalaemias, haemor-rhages or malnutrition.Key words: DRG; comorbidités; cost-weight; infections uri-naires; codage; détection automatiséeACM: H.2.8 Database Applications, data mining.

Introduction

Aux Hôpitaux Universitaires de Genève (HUG), l’introduc-tion d’une facturation par groupes homogènes de diagnos-

tic (diagnosis related groups ou DRG) a eu et a encore d’im-portantes répercussions sur les circuits d’information [1].Le calcul du DRG se fait sur la base d’une liste de diagnosticset d’interventions présents dans les documents de sortie dupatient, codés grâce à l’emploi de dictionnaires (CIM10-GM, CHOP11). Les codes sont choisis par des codeurs pro-fessionnels, après analyse des documents de sorties néces-saires: les résumésstandarddesortie (RSS).Cesdocumentsprocèdent initialement de l’échange d’informations médi-cales et sont incidemment utilisés pour faire de la factura-tion.Ce système, à l’origine de la tarification à l’activité depuis2004 en France, a été employé en Amérique du Nord, de-puis 1983, pour déterminer combien l’assurance-maladiepaye aux établissements de santé. L’objectif original desDRG était de développer un système de classification despatients séparant les patients avec leur traitement engroupes définis cliniquement (regrouper les patients engroupes homogènes sur le plan médical) et les coûts de trai-tement comparables (consommation de ressources dechaque hospitalisation).Les DRGs ne sont pas, dans la majorité des cas, utilisés àdes fins financières, mais servent avant tout à rendre l’ac-tivité lisible, et transparente. L’amélioration de la qualitédes soins et le benchmarking ont également incité les hos-pitaliers européens à introduire les DRGs.La facturation par DRGneconcerneque leshospitalisationsen zones de soins aigus et somatiques [2, 3]. Un séjour enzone de soins aigus est qualifié sur la base du parcoursclinique du patient durant son épisode de soins (EDS). Lesdifférents mouvements sont gérés dans le dossier adminis-tratif du patient (DPA). L’ensemble du processus de docu-mentation clinique est, quant à lui, centralisée dans le dos-sier patient informatisé (DPI). Ainsi pour les patients sortis,une fois la documentation réalisée dans tous les services duséjour, le cas est aléatoirement attribué à un codeur. La rè-gle veut que le codeur ne puise l’information que dans leslettres de sortie ou des comptes rendus opératoires, en touscas dans une source émanant d’une autorité médicale etayant signé numériquement le document.

Swiss Medical Informatics 2011; no 71

Détection automatique d’infections urinairesdans le cadre du codageAPDRG et SwissDRGPhilippe Rossier, Gilles Cohen, Rodolphe MeyerHôpitaux Universitaires de Genève, Direction de l’Analyse Médico-Economique

Correspondance:Rodolphe Meyer, MD, PhDHôpitaux Universitaires de Genève – D.A.M.E. – DTSDRue Gabrielle-Perret-Gentil 4CH-1211 Genève [email protected]

Page 25: Swiss Medical Informatics - SMI 71

DRG

24

Quand le codeur estime que toutes les informations perti-nentes ont étés saisies pour tous les services médicaux duséjour, il déclare le codage terminé. Une synthèse électro-nique est transmise à un programme nommé groupeur quicalcule le DRG. Ensuite le dossier est transmis au systèmeOPALE qui adresse les factures aux débiteurs des HUG.

Problématique

Le groupage en DRG fait appel à un calcul combinant diag-nostics et actes codés lorsqu’ils existent [4]. Le problèmeauquel les HUG doivent faire face réside dans la qualité desRSS. En effet ce sont des résumés. Il est donc implicite qu’ilsne contiendront pas toute l’activité réalisée pour un patientdurant son EDS mais les problématiques marquantes ouqui font du sens pour le clinicien rédacteur. Ce sens étantsouvent celui de sa spécialité. Un cardiologue ne mention-nera pas toujours une petite hypokaliémie durant un EDSd’infarctus massif. De même un neurochirurgien ne focali-sera pas son compte rendu sur l’infection urinaire de sa pa-tiente venue pour une embarrure avec coma stade 2.C’est naturel, mais pénalisant car la construction des DRGse fait aussi sur la base des comorbidités actives durant leséjour. Certains séjours voient leur catégorie de DRG chan-gerselon lapriseencomptedecertainescomorbiditésd’ap-parence banale, et passent du DRG simple au DRG aveccomplication. Dans le cadre d’un remboursement par DRG,le report de ces informations devient important et légitime.Elles reflètent la complexité du cas souvent bien différentedans le contexte de la prise en charge en urgence versus ce-lui des soins électifs [5, 6].

Hypothèses de travail

Certainesdeces comorbités sontdécelablesàpartirdedon-nées objectives présentes dans le dossier patient informa-tisé (DPI) du système d’information des HUG [7]. Nous nousproposons donc d’améliorer les RSS à partir de données delaboratoire, de prescription de médicaments, etc. conte-nues dans les bases d’archivage.Il s’agit d’analyser toutes les données recueillies pour unpatient au cours de son séjour et d’y tester les indices de laprésence de quelques complications. Pour chaque type decomorbité à mettre en évidence, nous cherchons un critèreplausible d’alerte aux codeurs en cas de suspicion de cettecomorbité. Ce critère doit être simple pour que les acteurspuissent en connaître la raison. Suffisamment large pourne pas rater des cas évidents et assez fin pour ne pas inon-der le codeur de messages inutiles.

MéthodologieDans le cas présent nous avons choisi de rechercher les in-fections urinaires identifiables dans le DPI. Le système d’in-formation ne contient pas la trace de l’intention du médecinet nous ne connaissons pas la complexité de la situation cli-nique, ni le contexte. Nous ne savons pas si les élémentsidentifiable furent réalisés dans un but de test à priori, debilan, de contrôle ou de surveillance thérapeutique. Le butn’est donc pas de choisir automatiquement quel codeCIM10 est le plus relevant de la maladie mais d’avertir lecodeur qui a au moins lu la lettre de sortie, si à partir desdonnées du DPI il y a une possible infection urinaire. Cettealerte ne surviendra ensuite qu’après le groupage du caspar le codeur et seulement si l’ajout de l’infection urinairefait basculer le DRG de simple à compliqué. Si le DRG estdéjà compliqué, il n’y aura pas d’alerte. En cas d’alerte, lecodeur n’est pas autorisé à modifier lui-même le codage, ildevra demander que des précisions soient ajoutées par leclinicien au RSS. Si le clinicien confirme bien que le patienta eu une infection urinaire durant son séjour le RSS seramodifié et recodé en conséquence. Ces différentes étapessont résumées dans l’algorithme décisionnel de la figure 1.

Critères infections urinairesComme critère d’infection urinaire probable [8], nous rete-nons les EDS avec:– au moins un résultat de laboratoire de bactériologie com-

portant une bactériurie supérieure ou égale à 105 bacté-ries par millilitre avec les bactéries urinaires les plus clas-siques (Escherichia coli, Staphylococcus saprophyticus,Proteus mirabilis, Klebsiella spp, Enterobacter spp, Pro-teus vulgaris, Morganella morganii, Serratia spp, Citro-bacter spp, Providencia stuartii, Pseudomonas aerugi-nosa, Enterococcus spp et Staphylococcus aureus);

– et une prescription d’antibiotiques classiquement utili-sés dans les infections urinaires (ATC: J01) concomitante(avant, pendant ou suivant l’analyse de laboratoire maisdans le même EDS).

Swiss Medical Informatics 2011; no 71

Tableau 1Codes CIM10 des infections urinaires.

CDCIM10 Libellé

A56.0 Infection à Chlamydia de la partie inférieure del’appareil génito-urinaire

A56.1 Infection à Chlamydia, pelvi-péritonéale et des autresorganes génito-urinaires

A56.2 Infection à Chlamydia de l’appareil génito-urinaire,sans précision

A60.0 Infection des organes génitaux et de l’appareilgénito-urinaire parle virus de l’herpès

N30.0 Cystite aiguë

N30.1 Cystite interstitielle (chronique)

N30.2 Autres cystites chroniques

N30.8 Autres cystites

N30.9 Cystite, sans précision

N39.0 Infection des voies urinaires, siège non précisé

023.3 Infections d’autres parties de l’appareil urinaire aucours de la grossesse

023.9 Infection de l’appareil génito-urinaire au cours de lagrossesse, autres et sans précision

086.2 Infection des voies urinaires, après accouchement

086.3 Autres infections des voies génito-urinaires, aprèsaccouchement

P39.3 Infection néonatale des voies urinaires

Page 26: Swiss Medical Informatics - SMI 71

DRG

25

Critères d’alerteAu cours de son codage si le codeur entre les codes CIM10-GM du tableau 1, le cas sera considéré comme codé par lesystème d’alerte n’entrainant pas la recherche de l’infec-tion urinaire dans DPI. Dans le cas contraire il ira regardersi les critères de bactériurie existent et si un antibiotiquedu tableau2estutilisédans l’EDS.Encasdedouble réponsepositive le système procédera à une analyse du DRG codé.Si c’est un DRG simple (sans complication) il procède à unesimulation de groupage avec un code du tableau 1 et si leDRG est changé il alertera le codeur pour qu’il demande

une précision au clinicien. Le codage définitif sera réaliséen fonction de cette précision.

Résultats

Identification des infections urinairesLe système est en cours d’implémentation aux HUG, nousavons donc effectué une simulation de son utilisation surles données de l’année 2009 en considérant comme incon-testables les comorbidités déjà inscrites par les codeurs desHUG.Sur ces 46026 séjours 27409 ont eu un examen urinaire(59,6%), dont 1789 avec un résultat au moins une fois po-sitif (3,89% des séjours) selon nos critères.Sur ces 1789 EDS possédant une bactériurie significative:– 588 (32,87%) ont été codées comme des EDS avec infec-

tion urinaire;– 1201 (67,13%) n’ont pas été codées comme des EDS avec

infection urinaire;– 606 (33,87%) auraient dû être codés avec une infection

urinaire (labo + traitement);– 90 (5,03%) ont été codés mais apparaissent comme faux

négatifs selon nos critères.Les 9201 cas, non codés, sans laboratoire positif, mais avecau moins un médicament s’expliquent par le large emploide cette classe de médicaments pour d’autres types d’infec-tions. 595 cas ont eu un examen d’urine positif mais aucundes traitements retenus n’a été identifié.

Génération des alertesSi le critère avait été appliqué lors du codage de cette co-horte, 606 messages d’alerte auraient déclenché une ana-lyse du DRG par l’algorithme et dans 96 cas le DRG auraitété modifié par l’ajout de la comorbidité infection urinaire(N30.9: Cystite, sans précision) soit 0,21% du total des EDSde 2009. 79 EDs ont vu leur CW augmenter et 17 EDS ontun CW diminuée. À condition que les cliniciens aient répon-dus positivement à la totalité des demandes de précisiondans les RSS, cela aurait représenté une augmentation mi-nimum de 13,91 points cost-weight (corrigé en fonction dela durée de séjour) soit CHF 166908.– théorique de factu-ration supplémentaire.

Discussion et perspectives

Dans ce travail nous voyons qu’une des limites consiste enl’identification de la comorbidité infection urinaire après larédaction du RSS. L’objectif de l’étude se positionne dupoint de vue médico-économique et non pas clinique. Il se-rait souhaitable que l’alerte provienne directement du DPIet au mieux avant la rédaction des documents de sortie.Cette fonctionnalité d’aide à la rédaction des RSS n’étantpas encore implémentée aux HUG nous avons par contrepu facilement la mettre en œuvre à postériori dans le sys-tème information du codage utilisé par seulement 15 per-sonnes.Par ailleurs nous voyons que près de la moitié des infectionsbiologiques ne donnent pas lieu à la prescription dans leDPI des antibiotiques que nous avons sélectionnés. Les pre-

Swiss Medical Informatics 2011; no 71

Tableau 2Antibiotiques ATC-J01.

ATC Libellé

J01CR02 amoxicilline + acide clavulanique

J01DA13 ceftriaxone

J01XD01 métronidazole

J01MA02 ciprofloxacine

J01EE01 co-trimoxazole

J01DH51 imipénem + cilastatine

J01DA06 céfuroxime

J01XA02 vancomycine

J01CA04 amoxicilline

J01FA09 clarithromycine

Figure 1Algorithme décisionnel.

Page 27: Swiss Medical Informatics - SMI 71

DRG

26

mières explications fournies par l’étude des EDS sont assezsimples. Il s’agit de patient pour lesquels le logiciel de pres-cription n’a pas été utilisé soit du fait que son déploiementn’était pas encore complet en 2009, soit du fait que les sé-jours étant courts le traitement a été prescrit sur des ordon-nances de sorties rédigées manuellement. Certaines infec-tions n’ont pas données lieu à des traitements antibiotiqueset d’autres étaient des contaminations des prélèvements.Toutefois cela n’explique pas 100% de ces cas non alertésqui nécessiteront un affinage des règles d’identificationsdes traitements. Les 90 cas codés pour lesquels nous ne re-trouvons pas de traitement selon nos critères seront à ana-lyser même si ils ne représentent que 5% de nos cas de labospositifs. L’étudedesdonnées2010devraitnousdonnerplusde précisions notamment sur la part de ce qui est lié au dé-ploiement et à l’utilisation du logiciel de prescription insti-tutionnel. On constate par ailleurs qu’aucun cas d’infectionurinaire n’a été codé avec des labos négatifs ce qui tend àmontrer que nos critère d’identification biologiques ne ra-mènent pas de faux négatifs.Concernant le volet de l’identification, l’ajout de critèresconfirmant les infections (leucocyturie, nitrites, CRP, VS,procalcitonine, etc.) pourrait permettre de retenir plus decas notamment dans le groupe des patients ayant des exa-mens de laboratoire négatifs mais ayant reçu des antibio-tiques. Cela serait intéressant dans une perspective d’as-sistance au diagnostic mais ce n’est pas notre objectif quireste médico-économique. Dans ce cadre-là, ces patientsont déjà des DRG avec complication et ne représentent pasune cible d’amélioration de la facturation par mise en évi-dence de la complexité du cas.Par ailleurs nous ne prenons en compte dans les alertes quela concentration de bactéries la plus strictement significa-tive (≥105 ufc/ml) alors que lors de la conférence de consen-sus sur les infections nosocomiales de Paris en novembre2002, il a été établi qu’une bactériurie est à prendre enconsidération si elle est ≥103 ufc/ml sous respect strict desconditions de prélèvement, de transport et d’analyse desurines [9].Compte tenu des résultats plutôt encourageants de cettepremière phase concernant les infections urinaires, nousprévoyons d’étendre les alertes sur d’autres comorbiditésen réalisant des algorithmes dédiés concernant les dyska-liémies par exemple ou l’identification des dénutritionssouvent oubliées lors de la rédaction des RSS.

Conclusions

La démarche consistant à prévenir les codeurs d’une co-morbité oubliée dans un RSS comme l’infection urinaire àpartir de résultats biologiques issus du système d’informa-tion clinique peut paraître simpliste. Cependant regardéedans l’ensemble des circuits d’informations hospitalières,elle permet d’augmenter la fiabilité du codage, d’améliorerla facturation, de favoriser le dialogue entre codeur et cli-niciens et au final d’affiner la précision des RSS. Elle rendattentif ces derniers à rapporter toutes les comorbiditésd’un séjour sans à priori sur leur importance pour un co-dage plus honnête – car certains séjours ont vu une dimi-nution de leur CW.Basée sur des données objectives, elle questionne la com-plexité de l’hôpital. Toutes alertes ne débouchent pas for-cément sur un codage. La simplicité du critère permet auxacteurs de comprendre le pourquoi et le comment de sondéclenchement.Il ne s’agit pas d’un prélude à la détermination automatiquedes codes diagnostics à partir des données, mais d’une dé-marche vers une détection plus systématique des comorbi-dités actives et une prise de conscience des enjeux de la do-cumentation sur la facturation des actes réalisés dans lescentreshospitaliersuniversitairesqui reçoiventdespatientssouvent plus délicats à prendre en charge [5, 6] et dont lacomplexité doit apparaitre au moment de la facturation.

Références

1 Ch Lovis & al. Codification des diagnostics et procédures: évaluation et im-plémentation d’une solution globale. Informatique et Santé: Springer-Ver-lag France, Paris, 1996;(8):99–110.

2 Fetter RB, Freeman JL. Diagnosis Related Groups: Product Line Manage-ment within Hospitals. The Academy of Management Review 1986;11(1):41–54.

3 Wennbero JE, McPherson K, Caper P. Will Payment Based on Diagnosis-Related Groups Control Hospital Costs? N Engl J Med. 1984;311:295–300.

4 Huber ZS. In: Système de santé suisse: formation et maîtrise des coûts. Pe-ter Lang SA ed. Éditions Scientifiques Européennes. Berne 2005:127–64.

5 Valderas JM, et al. Defining Comorbidity: Implications for UnderstandingHealth and Health Services. Ann Fam Med. 2009;7:357–63.

6 Hensen P, et al. Introduction of diagnosis-related groups in Germany: eva-luationof impacton in-patient care inadermatological setting.EurJPublicHealth. 2008;18(1):85–91.

7 Trolliard P, et al. Risques, Technologies de l’Information pour les PratiquesMédicales, Informatique et Santé. 2009;17(1):15–22.

8 Kasper DL, et al. In: Harrison’s Manual of Medicine. McGraw-Hill MedicalPublishing Division. New-York 2005:724–8.

9 Bruyère F, et al. Généralités sur les infections bactériennes urinaires del’adulte. Progrès en Urologie 2008;18(Suppl. 1):S4–S8.

Swiss Medical Informatics 2011; no 71

Tableau 3Résultats des infections urinaires.

Codé Ul LABO MEDIC NB total % % Labo1 Femmes % Hommes %

0 0 0 35036 76,12 19627 78,83 15409 73,25

0 0 1 9201 19,99 4105 16,49 5006 23,80

0 1 0 595 1,29 33,26 425 1,71 170 0,81

0 1 1 606 1,32 33,87 363 1,46 243 1,16

1 1 0 90 0,20 5,03 70 0,28 20 0,10

1 1 1 498 1,08 27,84 309 1,24 189 0,90

588 1789 10305 46026 24899 21037

0 = résultat négatif ou pas d’examen, 1 = résultat positif

Page 28: Swiss Medical Informatics - SMI 71

DRG

27Swiss Medical Informatics 2011; no 71

Summary

2012 will see a fundamental change in Swiss hospital fi-nancing. For example, inpatient health care will be com-pensated on the basis of uniform countrywide structures.The introduction of these so called SwissDRGs will lastinglychange data flow between hospitals and health insurers.To ensure that the auditing of accounts and checks on prof-itability also remain feasible in the future, hospitals will berequired to disclose the appropriate medical informationsystematically and thus enable health insurers to do theirjob. The legal basis for data security of processing is high-lighted for the insurers. While these regulations are highlycontroversial, they show that the dissemination of data islegally permitted. Finally, the system-oriented conversionof the new conditions is described for Helsana insuranceinstitution.

Kernelemente neue Spitalfinanzierung

Die stationären Leistungen von Listenspitälern werdenneu von den Kantonen zu mindestens 55% und den Kran-kenversicherern zu maximal 45% übernommen. Neu ha-ben die Krankenversicherer neben den Betriebskostenauch die Investition aus der obligatorischen Krankenpfle-geversicherung (OKP) mitzufinanzieren. Die OKP wird da-durch zusätzlich belastet.Die neue Finanzierungsregel gilt für KVG-Leistungen in öf-fentlichen und privaten Spitälern auf der kantonalen Spi-talliste und zwar sowohl für Grundversicherte als auch fürPrivat- und Halbprivatpatienten. Da bisher der kantonaleAnteil bei Behandlungen in privaten Spitälern nicht aus-bezahlt wird, ist davon auszugehen, dass die Zusatzversi-cherung entlastet wird und so die Quersubventionierungder OKP abnimmt.Eine weitere bedeutende Neuerung ist die leistungsbezo-gene Finanzierung der Spitäler mittels diagnosebasierterFallpauschalen. Die Tarifvielfalt entfällt, es findet gar eineigentlicher Paradigmenwechsel bei der Finanzierungstatt: Die Spitäler erhalten für die jeweilige stationäre Be-handlung nur noch einen Fixbetrag. Dieser Fixbetrag ori-entiert sich aber nicht mehr an den effektiven Kosten dereinzelnen Spitäler (sogenanntes Kostendeckungsprinzip),sondern an den durchschnittlichen Aufwendungen einerBehandlung. Damit wird von einer objektorientierten aufeine subjektorientierte Finanzierung umgestellt. Das Geldfolgt also neu den Patienten und nicht mehr den Spitälern.Dadurch sollen die Spitäler veranlasst werden, Behand-lungen wirtschaftlicher durchzuführen.

Die neuen Fallpauschalen sollen aber auch Transparenzschaffen. Indem alle Akutspitäler auf der Basis der gesamt-schweizerisch einheitlichen Tarifstruktur SwissDRG [1]entschädigt werden, lassen sie sich auch miteinander ver-gleichen. Das Gesetz schreibt in Art. 49 Abs. 1 explizit vor,dass sich die Spitaltarife an der Entschädigung jener Spi-täler orientieren sollen, die die tarifierte obligatorisch ver-sicherte Leistung in der notwendigen Qualität effizient undgünstig erbringen. Damit wird die Tariffindung über einBenchmarking der Spitäler obligatorisch.Auch die Vorgaben für die Kantone bei der Spitalplanungändern sich: Neben zahlreichen neuen Planungsvorgaben,einer leistungsorientierten Ausrichtung sowie der Ver-pflichtung zur interkantonalen Koordination werden dieSpitallisten nicht mehr als Zulassungsfilter für die OKP fun-gieren, sondern als Verteilungsmechanismus von Finan-zierungsmitteln. All jene Spitäler, die ein Kanton auf seinerListe führt, erhalten auch entsprechende kantonale Mittel.Die Berücksichtigung der Privatspitäler bedeutet dann imVergleich zu heute eine Mehrbelastung der Kantone.

Grundsätze der Datenbearbeitung

Krankenversicherer, die die OKP anbieten, haben bei derBearbeitung personenbezogener Daten Vorgaben zu be-achten, die sich sowohl aus dem Datenschutzgesetz (DSG)als auch aus dem KVG ergeben. Die Datenbearbeitungrichtet sich nach den allgemeinen Grundsätzen des DSG.Grundlegend istdieOrientierungandenPrinzipienderVer-hältnismässigkeit, Zweckbindung und Erforderlichkeit.Die Krankenversicherer gelten als Bundesorgane im Sinnevon Art. 2 Abs. 1 lit. b DSG. Sie dürfen nach Art. 17 Abs. 2DSG höchstpersönliche Daten nur bearbeiten, wenn diesfür eine in einem formellen Gesetz umschriebene Aufgabeunentbehrlich ist (lit. a) oder wenn die betroffene Personeingewilligt hat (lit. b).Das KVG ist diese gesetzliche Grundlage. EntsprechendeRegelungen finden sich insbesondere in Art. 84 und 84aKVG. Die mit der Durchführung sowie der Kontrolle oderder Beaufsichtigung der Durchführung betrauten Organe

Spitalfinanzierung 2012 – DatenschutzAde?Wolfram StrüweHelsana Versicherungen AG, Zürich

Korrespondenz:Wolfram StrüweHelsana Versicherungen AGAbteilung GesundheitspolitikPostfachCH-8081 Zü[email protected]

Page 29: Swiss Medical Informatics - SMI 71

DRG

28

sind befugt, Personendaten einschliesslich besondersschützenswerter Daten und Persönlichkeitsprofilen zu be-arbeiten oder bearbeiten zu lassen, die sie benötigen, umdie ihnen nach diesem Gesetz übertragenen Arbeiten zuerfüllen. Hier sind insbesondere Beurteilung, Berechnungund Gewährung von Leistungsansprüchen, Koordinationmit anderen Sozialversicherungen, die Geltendmachungdes Rückgriffsrechts gegenüber einem haftpflichtigen Drit-ten und die Führung von Statistiken zu nennen.

Erforderlichkeit

Der Grundsatz der Erforderlichkeit ist zentral im Daten-schutzrecht. Demnach dürfen ausschliesslich Daten be-schafft werden, die zur Erfüllung des Gesetzesauftrags er-forderlich sind. Er kann daher auch als Ausfluss desVerhältnismässigkeitsgrundsatzes angesehen werden.Ausdruck hierfür ist Art. 84 KVG.Es dürfen nur Daten eingefordert werden, die wenigstensvom Grundsatz her geeignet und notwendig sind, den Kran-kenversicherern die Erfüllung ihrer gesetzlich aufgetrage-nen Aufgaben zu ermöglichen. In der Frage, welche Datenkonkret notwendig sind, haben die Krankenversicherer ei-nen weiten Ermessensspielraum. So hält beispielsweise dasBundesverwaltungsgericht (BVG) in seinem Urteil K 12/06vom März 2007 fest: «Die Wirtschaftlichkeitskontrolle, dieder Versicherer gemäss Art. 56 Abs. 2 KVG vornehmenmuss, dient der Kontrolle über die Leistungserbringer.Schon aus dieser Zielsetzung ergibt sich, dass (…) nicht vomLeistungserbringer zu beurteilen ist, welche Angaben erdem Versicherer liefert, würde doch sonst der zu Kontrol-lierende selber den Umfang der Kontrolle festlegen.» DieAuskunftspflicht kann sich aber nur auf Angaben erstrek-ken, die objektiv erforderlich und geeignet sind, um dieWirtschaftlichkeit der Leistung überprüfen zu können. IndiesemKontextmussdemKrankenversicherereingewisserBeurteilungsspielraum darüber eingeräumt werden, aufwelche Weise und mit welchen Angaben er die Überprüfungvornimmt.

Zweckbindung

Der Grundsatz der Zweckbindung hängt eng mit jenem derErforderlichkeit zusammen. Personendaten dürfen ge-mäss Art. 4 Abs. 3 DSG nur für die Erfüllung von Aufgabengenutzt werden, die im gleichen Zweckrahmen liegen wiediejenigen Aufgaben, zu deren Erfüllung sie erhoben wor-den sind. Der oberste Zweck der OKP besteht darin, dassdie versicherungsmässigen Voraussetzungen einer umfas-senden, qualitativ hochstehenden und zweckmässigenmedizinischen Versorgung für die gesamte Bevölkerung zumöglichst tiefen Kosten zu gewährleisten sind [2].Insbesondere die Krankenversicherer haben diese Auf-gabe zu erfüllen. Dies erfordert beispielsweise eine geord-nete und gesetzesmässige Leistungsgewährung, indem dieKrankenversicherung nur von wirklich versicherten Per-sonen in Anspruch genommen wird. Zu einer gesetzes-mässigen Leistungsgewährung gehört immer auch die

Prüfung der Leistungsvoraussetzungen, insbesondere, obeine Leistung auch wirksam, zweckmässig und wirtschaft-lich erbracht wurde. (Art. 32 Abs. 1 KVG). Die zur Feststel-lung der Leistungsansprüche erfassten Daten dürfen nichtbloss zum Zwecke der Leistungs- und Wirtschaftlichkeits-kontrolle verwendet werden, sondern zudem für alle Auf-gaben, die dem generellen Ziel der Kosteneindämmung imGesundheitswesen dienen [3].

Persönlichkeitsschutz

Es ist evident, dass sich die Krankenversicherer im Zugeder Leistungs- und Wirtschaftlichkeitskontrolle tagtäglichmit sensiblen Daten beschäftigen. Angesichts mehrererMillionen Rechnungen, die jährlich zu prüfen und auszah-len sind, könnte man fast sagen, dass dies ihr Kerngeschäftin der Abwicklung der OKP ist.Dem Gesetzgeber war dies bewusst. Da in der Administra-tion der Krankenversicherer besonders schützenswerteDaten bearbeitet werden, unterliegen sämtliche Mitarbei-tende der Schweigepflicht nach Art. 33 ATSG. Zudem hater ein System mit einem doppelten Schutzwall zur Siche-rung der Persönlichkeitsrechte der Versicherten geschaf-fen:a)Alle Mitarbeitende der Krankenversicherer unterstehen

Dritten gegenüber der Schweigepflicht gemäss Art. 33ATSG. Bei einer Verletzung dieser Schweigepflicht drohtArt. 92 lit. c KVG mit einer Geldstrafe von bis zu 180 Ta-gessätzen. Diese Vorschriften bilden den ersten Schutz-wall der Krankenversicherung.

b)Für besonders sensible Sachverhalte hat der Gesetzge-ber noch einen engeren Schutzwall gezogen: GemässArt. 42 Abs. 5 KVG darf der Leistungserbringer in be-gründeten Fällen oder auf Verlangen des Versichertenmedizinische Angaben nur dem Vertrauensarzt bekanntgeben. Die Vertrauensärzte wiederum geben gemässArt. 57 Abs. 7 KVG den zuständigen Stellen der Versi-cherer nur diejenigen Angaben weiter, die notwendigsind, um über die Leistungspflicht zu entscheiden, dieVergütung festzusetzen oder eine Verfügung begründenzu können.

Zudem hat das Parlament schon im Dezember 2007 einenneuen Art. 84b KVG verabschiedet, der auf 2012 in Krafttritt. Er betrifft die Sicherstellung des Datenschutzes durchdie Versicherer. Demnach haben die Versicherer die erfor-derlichen technischen und organisatorischen Massnah-men zur Sicherstellung des Datenschutzes zu treffen. Sieerstellen insbesondere die gemäss Verordnung zum DSGnotwendigen Bearbeitungsreglemente. Diese sind demEidgenössischen Datenschutz- und Öffentlichkeitsbeauf-tragten zur Beurteilung vorzulegen und öffentlich zugäng-lich zu machen.Der Persönlichkeitsschutz der Versicherten ist also ein we-sentliches Merkmal beim Vollzug des KVG und ist gegen-über Aussenstehenden in doppelten Masse geschützt: EineVerletzung dieser Vorgaben zieht in jedem Fall ernsthaftestrafrechtliche Konsequenzen nach sich.

Swiss Medical Informatics 2011; no 71

Page 30: Swiss Medical Informatics - SMI 71

DRG

29

Gesetzesinterpretation und Gesetzauslegung

Obwohl die Rechtslage für die Bearbeitung personenbezo-gener Daten durch die Krankenversicherung klar ist, stehtsie dennoch immer wieder im Brennpunkt. Dies lässt sicham Besten bei der (systematischen) Weitergabe von Dia-gnosen von Leistungserbringern an die Krankenversiche-rer veranschaulichen.Im Zentrum steht dabei die Interpretation von Art. 42 KVG.Gemäss Art. 42 Abs. 3 KVG muss der Leistungserbringerdem Schuldner eine detaillierte und verständliche Rech-nung zustellen. Er muss ihm auch alle Angaben machen,die dieser benötigt, um die Berechnung der Vergütung unddie Wirtschaftlichkeit der Leistung überprüfen zu können.Der Versicherer kann eine genaue Diagnose oder zusätz-liche Auskünfte medizinischer Natur verlangen (Art. 42Abs. 4 KVG). Nach Art. 42 Abs. 5 KVG schliesslich ist derLeistungserbringer in begründeten Fällen berechtigt undauf Verlangen der versicherten Person in jedem Fall ver-pflichtet, medizinische Angaben nur dem Vertrauensarztdes Versicherers nach Art. 57 KVG bekannt zu geben.Der Eidgenössische Datenschutz- und Öffentlichkeitsbe-auftragte (EDÖB) beispielsweise sieht mit den Absätzen 3und 4 von Art. 42 KVG eine stufenweise Bekanntgabe derBehandlungsdaten durch die Leistungserbringer gegeben[4]. Mit Absatz 4 als Ergänzung zu Absatz 3 mache der Ge-setzgeber deutlich, dass der Krankenversicherer zusätzli-che Angaben verlangen kann. Dies schliesse folglich aus,dass der Wortlaut von Ansatz 3 die systematische Weiter-gabe von Behandlungsdaten und Diagnosen in detaillierterForm vorsieht. Die systematische Bekanntgabe von detail-lierten Diagnosen bzw. Diagnosecodes an die Krankenver-sicherer verstosse daher sowohl gegen das im DSG veran-kerte Verhältnismässigkeitsprinzip sowie gegen Art. 42KVG.Diese Gesetzesinterpretation hat das BVG klar verworfen.Im Urteil C-6570/2007 vom 29. Mai 2009 wird festgehal-ten, dass Art. 42 Abs. 3 und 4 KVG, in Verbindung mit Art.84 KVG und 84a KVG, an sich als genügende formell-ge-setzliche Grundlage für die tarifvertragliche Vereinbarungder systematischen Weitergabe der Diagnose und des Ein-griffscodes mit der Rechnungsstellung zu erachten ist. Ins-besondere hält das BVG fest:– Der gesetzlich vorgesehene Regelfall ist die Lieferung

der medizinischen Informationen an die Verwaltung desKrankenversicherers. Die Lieferung an den Vertrauens-arzt ist die Ausnahme.

– Eine Aufteilung der Bekanntgabe der Informationen inzwei Stufen – zuerst eine allgemein gehaltene Diagnoseund dann erst auf Verlangen und bei begründetem Ver-dacht eine detaillierte Diagnose – ist nicht haltbar.

– Dem Datenschutz ist besser gedient, wenn Diagnoseda-ten in codierter Form statt im Klartext übermittelt wer-den.

– Erweisen sich Diagnose und der Eingriffscode zur Prü-fung der Leistungspflicht oder der Wirtschaftlichkeit re-gelmässig als notwendig, so stellt es für die Krankenver-sicherer einen grossen und kaum zu begründendenadministrativen Mehraufwand dar, wenn diese Angabenin jedem Einzelfall (bzw. in jedem Fall, in dem eine Wirt-

schaftlichkeitsprüfung vorgenommen werden soll)nachverlangt werden müssten, zumal diese Gesuchekeiner Begründung bedürften.

– Die Wirtschaftlichkeitsprüfung hat möglichst früh einzu-setzen, d.h. bereits mit der Eintrittsmeldung. Diagnose-und Eingriffscodes sind also geeignete und adäquateAusgangspunkte. Sie sollen nicht erst beim Rechnungs-eingang greifen. Damit ist zugleich ein Kostenschutz derVersicherten verbunden: Falls die Behandlung vomKrankenversicherer nicht übernommen wird, ist diesbei der Rechnungsstellung und folglich nach erfolgterBehandlung zu spät um festzustellen, dass der Patient(oder seine Zusatzversicherung) die Kosten überneh-men muss.

– Der Leistungserbringer soll die Informationen als Aus-nahmefall, beispielsweise bei gesellschaftlich stigmati-sierenden Diagnosen, dem Vertrauensarzt übermittelnkönnen [5].

Mit diesem Urteil rückt das Gericht wieder einmal zweizentrale Eckpunkte des KVG in den Mittelpunkt und klärtvermeintliche Unklarheiten:– Es wird erneut zum Ausdruck gebracht, dass die Persön-

lichkeitsrechte des Versicherten im Zentrum stehen undzu schützen sind. Auf sein Verlangen hin müssen die me-dizinischen Angaben zwingend an den Vertrauensarztübermittelt werden. Damit er dieses Recht auch wahr-nehmen kann, muss der Patient vom Leistungserbringerausdrücklich darauf hingewiesen werden.

– Das BVG misst der Wirtschaftlichkeit der Wirtschaftlich-keitsprüfung erhebliche Bedeutung bei und hält fest,dass auch der Verwaltungsaufwand der Krankenversi-cherer über die Allgemeinheit finanziert werden muss.In einer für alle obligatorischen Versicherung sind diePrämiengelder also Zwangsabgaben, mit denen sorg-sam umzugehen ist. Daher ist es gleichgültig, ob dieKrankenversicherer ihre Aufgaben unzweckmässigoder mit einem unverhältnismässigen Aufwand betrei-ben. Die Wirtschaftlichkeitskontrolle selbst muss wirt-schaftlich sein.

Medizinische Daten im Fallpauschalensystem

Tarifpartner und Kantone haben am 18. Januar 2008 ge-mäss den gesetzlichen Vorgaben die SwissDRG AG gegrün-det. Die Gesellschaft hat zur Aufgabe, die schweizweit ein-heitliche Tarifstruktur für die akut-somatischen Spitäler zuentwickeln und zu pflegen [6]. Die Einführungsversionwird im April 2011 bereitgestellt. Ein solches DRG-Systemzeichnet sich insbesondere dadurch aus, dass es datenge-trieben ist, und zwar in zweifacher Hinsicht:– Für die integrale Kalkulation der gesamten Tarifstruktur

durch die SwissDRG AG werden die Kosten- und Leis-tungsdaten [7] der einzelnen Patienten herangezogen.

– Die Tarifbildung und damit die Vergütung der Spitälerhängt massgeblich von den Diagnosen und Behandlun-gen jedes einzelnen Patienten ab.

Swiss Medical Informatics 2011; no 71

Page 31: Swiss Medical Informatics - SMI 71

DRG

30

Abbildung 1 verdeutlicht diesen Zusammenhang: Die sta-tionär behandelten Patienten von Akutspitälern werden inmedizinisch und ökonomisch homogene Fallgruppen ein-geteilt. Das wichtigste Kriterium für die Zuordnung einesPatienten zu einer Fallgruppe ist die Hauptdiagnose beiSpitalaustritt. Weitere Klassifikationsmerkmale sind Ne-bendiagnosen, Prozeduren, Alter, Geschlecht, Art des Spi-talaustritts, Schweregrad, bei Neugeborenen das Geburts-gewicht und weitere Faktoren (MDS). Diese Informationenwerden den Krankenakten der Patienten entnommen. DieZuweisung einer Hospitalisation zu einer bestimmten DRGerfolgt unter Beachtung der Kodierrichtlinien durch einevollautomatische Gruppierungssoftware (Grouper). JederDRG ist einer Kennzahl, das sogenannte Kostengewicht,zugeordnet. Dieses Kostengewicht wird anhand der tat-sächlich anfallenden Kosten der Schweizer Spitäler be-rechnet und gibt für jeden Fall den durchschnittlichen Ver-brauch über alle Spitäler wieder. Multipliziert mit demBasispreis ergibt sich die Fallpauschale, die von einemKrankenversicherer zu vergüten ist. Damit orientiert sichzukünftig die Vergütung nicht mehr an den effektiv ent-standenen Kosten, sondern an den Durchschnittskostenall jener Spitäler, die ihre Daten für die Kalkulation bereit-gestellt haben. Je höher dieses Kostengewicht ausfällt, de-sto höher ist die Vergütung eines Falls. Das Spital hat daherden potenziellen Anreiz, Haupt- und Nebendiagnosen so-wie Behandlungen in der Weise zu codieren, dass einemöglichst hohe Vergütung im Einzelfall resultiert (soge-nanntes Upcoding).Damit lassen sich die folgenden Schlüsse ziehen:– Ein DRG-System ordnet Fälle ähnlichen Ressourcenver-

brauchs einer bestimmten Fallgruppe zu, um so dendurchschnittlichen Ressourcenverbrauch zu ermitteln.Es ist also ein am statistischen Durchschnitt kalkuliertesSystem, dass auf Einzelfalldaten beruht.

– Eine Einzelfallprüfung ist in einem solchermassen sta-tistisch kalkulierten System natürlich möglich. Auch die-ser Sachverhalt wird in der Abbildung wiedergegeben.Das Spital stellt dem Krankenversicherer für jeden ein-zelnen Patienten Rechnung. Mit Hilfe der codiertenDiagnosen und Behandlungen kann dieser jene Fälletriagieren, bei denen er die eigentliche Wirtschaftlich-

keitsprüfung durchführen will, also die Krankenakteeinfordern will. Eine stichprobenorientierte Wirtschaft-lichkeitsprüfung ist dabei gemäss BVG zulässig.

Rechnungs- und Wirtschaftlichkeitskontrolle

Die Krankenversicherer sind gemäss KVG zu zahlreichenPrüfungen und Kontrollen verpflichtet. Art. 32 KVG besagtnämlich, dass alle Leistungen wirksam, zweckmässig undwirtschaftlich sein müssen. Darin wird also nicht nur einGebot der Wirtschaftlichkeit für die Leistungserbringeraufgestellt, sondern auch der Wirtschaftlichkeit der einzel-nen Tätigkeiten eines Leistungserbringers. Diese Wirt-schaftlichkeit wird im Rahmen der Rechnungskontrollegeprüft, d.h., jede Rechnung bzw. die darin aufgeführtenLeistungen werden darauf geprüft, ob sie wirksam, zweck-mässig und wirtschaftlich waren. Der Kontrollprozesslässt sich grundsätzlich wie folgt strukturieren.

PersonenidentifikationEs gilt zunächst zu überprüfen, ob der Patient beim ent-sprechenden Krankenversicherer überhaupt versichertist. Es kommt beispielsweise oft vor, dass die Spitäler dieRechnung an einen falschen Krankenversicherer adressie-ren. Zu dieser Kontrolle gehört neben der Abklärung derIdentität des Versicherten auch die Abklärung bezüglicheines allfällig bestehenden Leistungsaufschubs bei nicht-bezahlten Prämien.

Formelle PrüfungEs gilt zu prüfen, ob die Rechnung die formellen Kriterienfür eine Abwicklung überhaupt erfüllt. So muss zwingendeine Behandlungsperiode angegeben sein, damit die se-quentielle Abfolge aller Behandlungen überprüft werdenkann, denn es darf nicht sein, dass bei einer stationärenBehandlung gleichzeitig eine ambulante Behandlung statt-gefunden hat. Es muss aber auch überprüft werden, ob diegelieferte DRG korrekt aus den angelieferten Daten errech-net werden kann. Dies ist jedoch nur möglich, wenn dasMDS vollständig geliefert wird, da sonst der Grouper eineFehlermeldung generiert. Der Versicherer ist gemäss Art.42 Abs. 3 KVG verpflichtet, die Berechnung der Vergütungzu überprüfen.

LeistungserbringerprüfungDann gibt es formelle Überprüfungen und Kontrollen da-für, ob der betreffende Leistungserbringer die Zulassungs-voraussetzungen des KVG überhaupt erfüllt. Im Falle einesSpitals geht es dabei z.B. um die Frage, ob das Spital fürdie erbrachte Leistung auf der Spitalliste des Kantons auf-geführt ist (Art. 39 Abs. 1 lit. d KVG). Zu überprüfen sinddabei z.B. die Fälle ausserkantonaler Hospitalisationen.Hier besteht unter Umständen eine Leistungspflicht desWohnkantons des Versicherten, wenn nämlich die medi-zinische Leistung dort nicht erbracht werden kann oderwenn es sich um einen Notfall handelt (Art. 41. Abs. 3 KVG).

Swiss Medical Informatics 2011; no 71

Abbildung 1Bedeutung medizinischer Informationen unter DRG.

Page 32: Swiss Medical Informatics - SMI 71

DRG

31

Prüfung aufWirksamkeit, Zweckmässigkeit undWirtschaftlichkeitAnschliessend erfolgt die Prüfung der grundlegenden Vor-aussetzungen Wirksamkeit, Zweckmässigkeit und Wirt-schaftlichkeitder inRechnunggestelltenLeistungen.Hierzumüssen mitunter umfangreiche Abklärungen durchgeführtwerden. Es geht beispielsweise um die Frage, ob ein Eingriffgrundsätzlich eine Pflichtleistung darstellt oder ob eine Be-handlung vielleicht kosmetischen Charakter hatte. Dabeiwerden u.a. die Voraussetzungen geprüft, die vom Gesetz-geber imAnhang1zurKLVerlassenwordensind. IndiesemAnhang werden verschiedene Leistungen der Spitäler bzw.deren Ärzte geprüft und bewertet.Die Krankenversicherer haben die Aufgabe, die darin auf-gestellten Voraussetzungen zu prüfen und deren Einhal-tung zu gewährleisten. Beispielsweise muss für die Be-gründung einer operativen Adipositas-Behandlung derVersicherte einen BMI von über 35 haben. Vor einem Ein-griff muss der Patient jedoch während zwei Jahren erfolg-los eine nicht-chirurgische Therapie absolviert haben undder Eingriff muss nach den aktuellen Richtlinien der SwissStudy Group für Morbid Obesity durchgeführt werden. Da-zu gehören auch Mindestfallzahlen für die durchführen-den Zentren (Ziff. 1.1 des Anhanges 1 KLV).Um überhaupt zu erkennen, dass es sich um einen solchenEingriff handelt, muss die entsprechende Diagnose auf derRechnung ersichtlich sein. Man sieht es der Rechnungsonst nicht an, welcher Eingriff durchgeführt wurde. Nuranhand dieser Information kann der Krankenversichererentscheiden, ob er eine vertieftere Prüfung durchführenmuss. Ansonsten muss er einfach darauf hoffen, dass dasSpital alles richtig gemacht hat.

Tarifansatz- undTarifregelprüfungEs ist auch die Einhaltung der im Vertrag vereinbartenTarifansätze und Tarifregeln zu prüfen. Gemäss Art. 42Abs. 3 KVG muss der Leistungserbringer alle Angabenmachen, die der Schuldner benötigt, um die Berechnungder Vergütung überprüfen zu können. Dies erfordert jenach vereinbartem Tarif eine unterschiedliche Datende-taillierung. Diese Offenbarungspflicht ist direkt abhängigvon der gewählten Tarifstruktur. Es ist etwas völlig unter-schiedliches unter dem Aspekt des Datenbedarfs, ob eineTagespauschale vereinbart ist oder ein detailliertes undausgefeiltes System wie beispielsweise DRG. Während esbei Tagespauschalen höchstens eine untergeordnete Rol-le spielt, welche Nebendiagnosen ein Patient hat, sinddiese Informationen in einem den Schweregrad differen-zierenden DRG-System ausgesprochen wichtig, weil dieCodierung einer Nebendiagnose zu einer massiv höherenFallpauschale führen kann (vgl. oben). Hierzu ist die Be-kanntgabe der Diagnose aber unerlässliche Grundvor-aussetzung.

Kodierrevisionen alsAlternative?

Bezüglich der Beurteilung der Wirtschaftlichkeit wird häu-fig angeführt, dass die Krankenversicherer eigentlich gar

keinepersonenbezogenenmedizinischenDatenbenötigen.«Für die Beurteilung der Wirtschaftlichkeit eines Spitalssind keine personenbezogenen Daten nötig. Im Einzelfallkann mit einer Pseudonymisierung genügend Transparenzgeschaffen werden», so beispielsweise der EidgenössischeDatenschutz- und Öffentlichkeitsbeauftragte [8].Als Lösung wird eine Kodierrevision vorgeschlagen [9].Wie in der Wirtschaft für die Prüfung der Jahresrechnungsoll es private Firmen geben, die auf die Revision der Co-dierpraxis von Spitälern spezialisiert sind. Die inhaltlichePrüfung der Codierpraxis erfolgt auf Stichprobenbasis an-hand der – heute bereits bestehenden – Codierrichtliniendes Bundesamts für Statistik.So könntendievertraulichen Patientendaten im Spital blei-ben und die Revisorenteams unterstehen der Geheimhal-tungspflicht. Auch sei die Prüfung zuverlässig, da sie dortansetze, wo eine fehlerhafte Handhabung entstehen könn-te, nämlich beim Erfassen der Codes aus der Krankenge-schichte. Zudem sei die Prüfung effizient: Sie erfolgt einmalpro Spital und Jahr, einmal für alle Versicherer zusammenund nach einheitlichen Kriterien. Das spare Ressourcenbei den Spitälern und den Versicherungen.Eine solche statistische Prüfung der Wirtschaftlichkeit un-ter DRG mag zwar verlockend erscheinen, da das Systemstatistischer Natur ist, aber ein solches Vorgehen ist miterheblichen Mängeln behaftet, ja sie verunmöglicht denKrankenversicherern, ihrem gesetzlichen Auftrag ad-äquat nachzukommen.Kontrollen gemäss KVG bedingen immer einen direktenPersonenbezug zum Versicherten. Unter einer Rechnungs-kontrolle darf eben nicht nur die mathematische Prüfungder Summe der erbrachten Leistungen verstanden wer-den, sondern gerade auch deren Zweckmässigkeit undWirksamkeit sowie deren korrekte Verrechnung nach ei-nem vereinbarten Tarifwerk. Rechnungs- und Wirtschaft-lichkeitskontrolle sind untrennbar miteinander verknüpft.Ein einfaches Beispiel aus dem ambulanten Bereich ver-deutlicht dies: Ein Arzt, der in der statistischen Durch-schnittskostenbetrachtung nicht sonderlich auffällt, kanndurchaus im Einzelfall unwirtschaftlich handeln, indem erzu viele Sitzungen mit seinem Patienten durchführt oderzu viele Medikamente abgibt. Die Tatsache, dass seineRechnungen im Durchschnitt wirtschaftlich erscheinen,berechtigt ihn aber nicht dazu, beispielsweise Nichtpflicht-leistungen zu verrechnen. Solche falschen Verrechnungenmüssen durch den Krankenversicherer in jedem Fall ge-prüft und beanstandet werden. Solche Verrechnungswei-sen können durch statistische Methoden nicht erkanntwerden.Die Kodierrevision selbst zielt lediglich auf eine Überprü-fung der Kodierqualität eines Spitals ab. Eine möglichst gu-te Kodierqualität ist sicherlich anzustreben, aber dies sagtnoch nichts darüber aus, ob in einem konkreten Fall dieKodierung richtig erfolgt. Mit einer guten Kodierqualitätgelingt das oben beschrieben Upcoding von Fällen nämlichwesentlich besser und gezielter.Der Gesetzgeber hat zudem den Krankenversicherern imKVG die Aufgabe zugewiesen, die Rechnungs- und Wirt-schaftlichkeitskontrollen durchzuführen. Die Übertragungdieser Tätigkeit auf eine externe Institution ist also im KVG

Swiss Medical Informatics 2011; no 71

Page 33: Swiss Medical Informatics - SMI 71

DRG

32

gar nicht vorgesehen, mit der Konsequenz, dass die For-derung nach einer substitutiven Kodierrevision letztlichder Forderung nach Herbeiführung eines gesetzeswidri-gen Zustands gleichkommt.Auch das BVG hat sich mit dieser Fragestellung befasst[10]. Es wägt für den stationären Bereich zwischen der sta-tistischen Methode, die sich an einem Durchschnitts-kostenvergleich orientiert, und der analytischen Methode,also der Einzelfallprüfung, ab. Das Gericht kommt zumSchluss, dass bei der Prüfung der Wirtschaftlichkeit statio-närer Leistungen grundsätzlich nach der analytischen Me-thode (Einzelfallprüfung) vorgegangen werden muss, dieaufwändige statistische Methode also nur im Ausnahme-fall anwendbar ist.Damit ist auch in der höchstrichterlichen Rechtssprechungdie Kodierrevision als Ersatzmethode der Einzelfallprü-fung verworfen worden.

Voraussetzungen der Datenübermittlung

Der neu einzurichtende, systematische Datenfluss zwi-schen den Spitälern und den Krankenversicherern muss

in den jeweiligen Systemen abgebildet werden. Damit die-ser Datenaustausch effizient erfolgen kann, sind drei Vor-aussetzungen unabdingbar:– Die Daten sind elektronisch auszutauschen. Dieser Aus-

tauschkanal wurde zwischen den Spitälern und denKrankenversichern im Laufe der letzten Jahre im Zugeder TARMED-Umsetzung geschaffen.

– Die Beteiligten haben sich auf einen für alle verbindli-chen Austauschstandard zu einigen. Diese Bedingungwurde vom dafür zuständigen Gremium, dem ForumDatenaustausch, am 31. August 2010 erfüllt [11]. Mitdem neuen XML-Standard 4.3 können sowohl die Rech-nungsinformationen als auch die Diagnose- und Be-handlungscodes gemeinsam übermittelt werden. Dieswar mit den bisher geltenden Standards nicht möglich.

– Die administrativen Prozesse zwischen den Kranken-versicherern und den Spitälern sind aufzunehmen bzw.zu definieren. An jedem Punkt der Prozesskette mussklar sein, welche Information jeweils benötigt wird undwelche für den nächsten Prozessschritt vorliegen muss.Die entsprechenden Anforderungen wurden im ProjekteKARUS gemeinsam von grossen Krankenversicherernund acht Grossspitälern erarbeitet [12].

Swiss Medical Informatics 2011; no 71

Abbildung 2Datenflusss- und Datenbearbeitungsschema Helsana.

Page 34: Swiss Medical Informatics - SMI 71

DRG

33

Umsetzung bei Helsana

In Abbildung 2 ist das Datenfluss- und Datenbearbeitungs-schema von Helsana wiedergegeben. Die Spitäler schickendie Rechnungsdaten sowie die Diagnose-und Behandlung-scodes (MDS-Daten) gemeinsam für jede Rechnung ssl-verschlüsselt an Helsana. Die Regellieferung erfolgt immeran die Administration, wie es das KVG vorsieht und im na-tionalen Tarifstrukturvertrag vereinbart wurde [13]. Ist imDatensatz jedoch gekennzeichnet, dass die medizinischenDaten an den vertrauensärztlichen Dienst (VAD) gehenmüssen – beispielsweise, weil der Patient gemäss Art. 42Abs. 5 KVG darauf besteht – wird der gesamte Datensatzautomatisch in diesen Bereich umgelenkt. Die Rechnungs-daten, die ja datenschutzrechtlich unbedenklich sind, blei-ben für die Administration jederzeit einsehbar. Die medi-zinischen Informationen hingegen nicht. Sie sind nur demVAD zugänglich.Unabhängig davon, wo sich die Datensätze befinden, wer-den sie mit Hilfe eines Regelwerks maschinell triagiert (vgl.Abb. 1). Kein Mitarbeitender hat in diesem ProzessschrittEinblick in die Daten. Jene Rechnungen, bei denen das Re-gelwerk nicht anschlägt, werden automatisch abgerechnetund gelangen ungesehen zur Auszahlung (sogenannteDunkelverarbeitung) [14]. Schlägt das Regelwerk hinge-gen an, ist eine manuelle Nachbearbeitung notwenig. Dieweitere Bearbeitung ist dann davon abhängig, wo sich derDatensatz befindet:– Ist der Datensatz im Bereich der Administration, so ist

er nur jenen Mitarbeitenden zugänglich, die die MDS-Daten zur Ausführung ihrer Arbeit benötigen (Level 2).Nach den notwendigen Abklärungen gelangt die Rech-nung zur Auszahlung bzw. zur Rückweisung. In jedemFall wird der gesamte Datensatz anschliessend archi-viert [15]. Wichtig ist, dass die MDS-Daten gemäss Art.59 Abs. 1ter KVV pseudonymisiert archiviert werden unddie Pseudonymisierung nur vom Vertrauensarzt aufge-hoben werden kann.

– Ist der Datensatz im Bereich des VAD, so haben nur dieVertrauensärzte und ihre Hilfspersonen auf die MDS-Daten Zugriff. Die Hilfspersonen unterstehen dem ärzt-lichen Berufsgeheimnis und der VAD ist dafür verant-wortlich, dass sie das ärztliche Berufsgeheimnis wahren[16]. Auch hier gilt: Nach Abrechnung oder Rückwei-sung einer Rechnung werden die MDS-Daten archiviert.Die Archivierung erfolgt aber auf einer separat bereitge-stellten Datenbank im VAD, zu der nur der VAD Zugriffhat.

Schlussbetrachtung

Neu an der neuen Spitalfinanzierung ist u.a., dass Diagno-sen und Behandlungen zur massgeblichen Grundlage derVergütung werden. Damit erlangen medizinische Informa-tionen einen ganz neuen Stellenwert. Die Persönlichkeits-

rechte der Versicherten müssen aber auch dann gewahrtbleiben. Die Rechtssprechung zeigt, dass das KVG die not-wendigen Grundlagen liefert. Hinreichend ist aber nur diekonkrete Umsetzung. Mit dem skizzierten Vorgehen wahrtHelsana die Persönlichkeitsrechte ihrer Versicherten underfüllt die entsprechenden gesetzlichen Bestimmungen,kann aber gleichzeitig ihrem gesetzlichen Auftrag zur Re-chungs- und Wirtschaftlichkeitskontrolle zum Wohle ihrerVersicherten nachkommen.Damit ist ein oftmals stipulierter Gegensatz ad acta gelegt.

Referenzen

1 vgl. www.swissdrg.org2 BGE 123 V 305 Erw. 6c/aa3 Eugster/Luginbühl (2001), Datenschutz in der Krankenpflegeversiche-

rung, in: Hürlimann/Jakobs/Poledna (Hrsg.): Datenschutz im Gesund-heitswesen (Zürich), S. 86 ff.

4 Eidgenössischer Datenschutzbeauftragter, Bericht zu TARMED und Da-tenschutz vom 22. Juni 2004, Bern. (http://www.edoeb.admin.ch/dokumentation/00438/00465/00645/00839/index.html?lang=de)

5 Zu den erheblichen Problemen bei der Erstellung solcher Listen stigma-tisierender Diagnosen vgl. Lang et al, «Gewährleistung des Datenschut-zes – externe und professionelle Kodierrevision macht es möglich», SAeZ(34/2010): 1265. (http://www.saez.ch/pdf_d/2010/2010-34/2010-34-676.PDF)

6 Die Tarifstrukturen für den psychiatrischen und rehabilitativen Bereichwerden erst zu einem späteren Zeitpunkt fertig gestellt und eingeführt.

7 Insbesondere bei den Kostendaten wird deutlich, dass die Anforderun-gen an die Spitäler hoch sind. Streng genommen ist eine Kostenträger-rechnung erforderlich, wobei der Patient der Kostenträger ist.

8 Thür H. «Arztgeheimnis und Datenschutz», SAeZ (1/2 2011):14.(http://www.saez.ch/pdf_d/2011/2011-01/2011-01-1129.PDF)

9 vgl. etwa Medienmitteilung H+ vom 10. Mai 2007 «Ja zur Kontrolle derWirtschaftlichkeit, Nein zum Gläsernen Patienten». (http://www.hplus.ch/de/servicenav/aktuell_medien/details/article/2007/05/10/ja_zur_kontrolle_der_wirtschaftlichkeit_nein_zum_glaesernen_patien-ten/)

10 vgl. BVG-Urteil C-6570/2007 vom 29. Mai 200911 Der neue Standard XML 4.3 ist unter http://www.forum-datenaus-

tausch.ch publiziert.12 Die Ergebnisse des Projektes eKARUS finden sich unter http://www.san-

tesuisse.ch. Nicht umsonst haben sich in diesem Projekt Grossversiche-rer und grosse Spitäler zusammengefunden. Gerade sie sehen sich ad-ministrativ einem Massengeschäft gegenüber und haben für eineeffiziente Abwicklung des Geschäftsprozesses zu sorgen, nämlich derErstellung 10’000er von Rechnungen und ihrer Abrechnung.

13 http://www.swissdrg.org/de/07_casemix_office/Tarifdokumente.asp?navid=17.

14 Bei Helsana werden mittlerweile über 90% der Apothekerrechnungenverarbeitet, ohne dass irgendeine Mitarbeitende sie zu Gesicht be-kommt.

15 Das Obligationenrecht schreibt eine mehrjährige Archivierungsfrist vor.16 vgl. Vertrauensarztvertrag, geschlossen am 14. Dezember 2001 zwi-

schen der FMH und santésuisse (http://www.santesuisse.ch/datasheets/files/20020131152014.pdf). Helsana hat selbstverständlich si-chergestellt, dass andere Tätigkeiten der Hilfspersonen nicht zu Inte-ressenkonflikten führen.

Swiss Medical Informatics 2011; no 71

Page 35: Swiss Medical Informatics - SMI 71

DRG

34Swiss Medical Informatics 2011; no 71

Summary

Most of the clinically relevant information on a patient isdocumented in freetext. Diagnoses and procedures in par-ticular are usually written in free wording. They are there-fore not structured and cannot be analysed statisticallywithout prior manual processing. When diagnoses andprocedures are coded (ICD-10, CHOP), only a small amountof the primary information is retained and the structuringis poor.However, with a fully automatic semantic coding pro-gramme the primary documentation’s input text is cast inan internal form which is well structured, keeps the de-tailed information of the original text and reconstructs im-plicit meanings. This internal representation is usually dis-carded in the process of coding and only the final codes areoutputted. It could, however, be exported to a data base(CDR = Clinical Data Repository). Thanks to its structuredand detailed representation of clinical facts, diagnoses,procedures, medications and others, very precise statisticscould be calculated. The CDR could thus serve scientificpurposes as well as clinical management of the patients(e.g., alertswhenprescribingcontraindicateddrugs). Inad-dition, easy-to-perform online queries in natural languageof the full patient base’s clinical information are possible.The precise semantic structure of the internal form, thepreservation of the full original information and the recon-struction of implicit information allow much more definiteanswers than queries of free text or of the poorly structuredand less detailed codes. Because the internal form origi-nates automatically when coding, no additional work hasto be done by clinicians or coders.

DRGs:A big part of the workloadfalls on clinical personnel

SwissDRGs will be implemented and they will have impli-cations it is already worthwhile to consider [1]. Howevermuch the expectations and fears of those concerned maydiffer, one prognosis can be regarded as certain: a consid-erable workload awaits the clinics in Switzerland.The workload will fall not only on staff concerned withbilling and controlling. As DRGs are based on the complexfield of patient diagnosis and treatment, the primary infor-mation must come from those who actually see and treatthe cases: the doctors in the clinical departments must pro-vide the necessary data. This means that their documen-

tation must be precisely formulated, but also, in point offact, that clinicians must relearn and document not onlythe clinically relevant facts, but pay particular attention tothose characteristics which are relevant for assigning theappropriate DRG – in providing, for example, the correctand honest arguments for a more costly DRG (right-cod-ing). The accurate coding (ICD-10 and CHOP) can only bedone when all the necessary facts are known, and thismeans that the clinical documentation must be completeand DRG-oriented. The clinician must know what informa-tion is crucial for the coding and grouping of the billing sec-tion.In view of the additional workload to be expected for clini-cians, one may enquire whether the clinical departmentdoes not directly recover some value from which the actualwork of the physicians with the patients could benefit. It isthe opinion of the authors that such a return is not onlypossible but could be earned with modest effort.

What information on a case is documented?

We should be aware that only structured information canbe analysed reliably. Structured means that the scale of avariable and its possible values are well defined. In thisway we can compare costs (scale = CHF) or the age of pa-tients (scale = years). Unfortunately, this well-structuredcomparability is applicable to only a few patient charac-teristics. And the clinically interesting data, i.e., diagnosesand procedures, have no common scale and not even amandatory set of standard values. Diagnoses and proce-dures are therefore not statistically analysable without pri-or editing by hand.Clinicians traditionally note diagnoses and procedures intheir documents in free wording. The wordings in use havestood the test of centuries and colleagues can take all es-sential information concerning the case from them. Butthis is only true if one looks at just one case.

A semantic clinical data repository – how the workon DRGs can serve clinical medicine, tooHans Rudolf Straub, Michael LehmannSemfinder AG, Kreuzlingen

Correspondence:Hans Rudolf StraubSemfinder AGHauptstrasse 53CH-8280 [email protected]

Page 36: Swiss Medical Informatics - SMI 71

DRG

35

When cases are grouped, statistically analysed or theircontent processed by computers, they must be edited inadvance by hand. This task is time-consuming and error-prone.To be sure, SwissDRGs offer, together with a thorough cod-ing of diagnoses and procedures, a systematic structuringof medical cases. Unfortunately, this structuring is inap-propriate for clinical use. We will show why this is the caseand how the structuring can be made suitable for clinicianswith very little effort.

Figure 1 shows the flow of information from the real situ-ation (patient and physician) to the documentation, thecoding and finally the DRG. It is easy to understand thatthe quantitative information content diminishes continu-ously thereby. It is difficult to overstate how drastic this re-duction of information is. While for a real patient, e.g., acase of acute appendicitis, in principle each of the approx.25 thousand billion red blood cells could be counted, local-ised and described in detail, the laboratory documenta-tion merely mentions Hb = 15 g/dl. In the discharge letterthe diagnoses, the ICD-10 codes and the DRG contain noreference to the red blood cells, due to lack of relevance.This, of course, is not only the case for the red blood cells.However we look at the patient, there is always a radicalreduction of information between what can be found in thereal life case to the notes in the documents and further tothe diagnosis codes and DRGs. This radical reduction ofinformation is intended and nothing but sensible: to gainan overview of the facts, we leave out the less importantdetails [2]. This is true for all levels of documentation: whilea diagnosis in text form is a choice among more than1000 million possibilities, an ICD-10 code is one out of15000 and a DRG one out of 1000.The question is, which information is omitted by each stepin this process? Which information is kept will depend onthe goal of the coding and grouping, and so will the infor-mation to be dropped (fig. 2). There is no natural or manda-tory way to select the information to be dropped when clas-sifying and grouping diagnoses. There is no naturalhierarchy in which diagnoses and procedures can bearranged in an orderly manner, such as we find in the sys-tems of zoology and botany [2].

The facts of the case become more evident when we lookat an example. In figure 3 the coding of a free text diagnosisis shown. In the field at the top the input text from the pa-tient record (EPR) is entered: “E. coli cystitis”. Below thatwe see a construction of several boxes, a “concept mole-cule”, which represents the content analysis of the diagno-sis text by the semantic coding programme [3, 4]. Each boxrepresents an atomic concept obtained from the text by theprogramme. These concepts are not accidentally chosenwords but well-defined nodes of a carefully elaborated se-mantic net. Various wordings of the same diagnosis alwayslead to the same atomic concepts. The arrangement of theboxes shows their conceptual relations, and in doing so the“semantic space” in which the semantic net is spread. Therepresentation is unambiguous, structured and complete,i.e., the complete information of the input text is retained.For the ICD codes this is not the case. In figure 3 the twoICD-10 codes which together code “E. coli cystitis” areshaded in grey. But the two codes do not contain the text’sfull information. For various reasons, an ICD-10 type ofcode can only represent a reduced information content ofa diagnosis in a structured way (fig. 2, see also [2]). Whilethe input text carries the full information content, but notin a structured form, the ICD code is roughly structured but

Swiss Medical Informatics 2011; no 71

Figure 1Information reduction.

Figure 2Depending on our goals, codes and groups retain different aspectsof the primary information.

Figure 3Coding of the diagnosis “E. coli cystitis” – and the semantic analysis behind it.

Page 37: Swiss Medical Informatics - SMI 71

DRG

36

contains only a part of the original information. The inter-nal representation, however, which develops automatical-ly during the semantic coding, is both complete and wellstructured. Due to its inherent systematic structure, itcould easily be analysed in statistics and queries. But be-cause the internal representation is used only for the cod-ing process, it is cleared immediately after creation andonly the codes are issued.

A semantic Clinical Data Repository (CDR)

The well-structured and complete information (the fabricof boxes in fig. 3) which emerges automatically during thesemantic coding process could be given to a data base with-out any additional effort on the part of physicians orcoders. Thus the complete semantic information contentof the diagnoses of all the clinic’s patients would be directlyaccessible for computer evaluation.While the DRGs represent each case only from the econom-ic point of view and the ICD-10 codes lead to an uncertainand faulty evaluation, the structured semantic representa-tion of figure 3 allows the clinicians a direct, targeted andprecise analysis of the full set of patients’ diagnoses. Thusa search for “gram-negative infections of the lower genito-urinary tract” matches directly with the diagnosis “E. colicystitis”, although none of the words of the diagnosis arementioned in the query. But the internal composite seman-tic representation formed during the coding process of thediagnosis already lists all the searched concepts. The querycan also directly access all those concepts which are onlyimplicitly contained in the diagnoses, such as “gram-neg-ative”, because the semantic analysis of the coding pro-gramme makes them explicit. If the atomic concepts of theinternal representation are not directly expressed in thequery, they are found, too, e.g., in a search for “catarrhs ofthe bladder”: the programme’s semantic machine trans-lates such expressions to its unique atomic concepts – as itreduces synonymous expressions in the patients’ diag-noses to its structured basic concepts when coding.

Efforts for and benefits of a semantic clinicaldata repository

The workload of building and maintaining a clinical datarepository does not fall on the physicians and coders. Be-cause the semantic representation of figure 3 is automat-ically built by the programme during the coding process,it involves no human work.The effort is only a technical one: the internal representa-tion of the coding programme must be stored in a data-base. For this purpose a unidirectional interface betweenthe programme and the database must be implemented.Then a query programme for searches of the databasemust be written. This programme most reasonably usesthe existing semantic interpretation machine of the codingtool, so that queries in natural language (NLP) are possible(fig. 4). Thisallowsclinicianswith scientific intent to searchthe content of the CDR without training, simply using theirown medical language. The full set of the clinic’s patients’routine medical data can be queried easily and preciselyfor its semantic content. Apart from these online searches,preformed queries are possible, e.g., for precise and de-tailed operation statistics and for alerts in the clinical rou-tine, warnings for contraindications when prescribingdrugs and hints for useful procedures in particular clinicalsituations. Due to thecompleteand well-structured seman-tic representation of the clinical data, such warnings andhints will be very precise and without the many irritatingfalse positive alarms of the conventional solutions basedon vocabularies or ICD-codes, which discourage their usein practice.The effort of acquiring the data in the clinical routine is sominimal because the structured semantic representationof the medical data is gained automatically during the rou-tine coding process. Apart from that the programme canbuild the structured concepts in the background fromproblem lists or routine diagnosis entries in the electronicpatient record. The flexible structure of the semantic con-cept representation allows it to link the diagnoses’ seman-tic information systematically with information on opera-tions, medications, therapies and laboratory results.

References

1 Berchtold P, Schmitz CH. Eine Zukunft für Spitäler. Schweiz Ärztezeitung.2010;91(48):1914–6.

2 Straub HR, Duelli M, Mosimann H, et al. From Terminologies to Classifica-tions – the Challenge of Information Reduction, in: Proceedings of the Eu-ropean Federation for Medical Informatics Special Topic Conference,Timisoara, Romania, 2006: 341–52. See also: http://www.semfinder.com/fileadmin/Daten/Dateien/Publikationen/From_terminologies_to_classifi-cation.pdf [Last visited 28. Jan. 2010].

3 Straub HR, Frei N, Mosimann H, et al. Simplified Representation of Con-cepts and Relations on Screen, Proceedings of MIE 2005: pp. 799–804.See also: http://meditext.ch/texte/Simplified_Representation_on_Screen.pdf [Last visited 4.Feb.2010].

4 Oertle M. Natural Language Processing: Real-time-Struktur aus Freitextim Klinikalltag? SMI. 2007(61):15–7.

Swiss Medical Informatics 2011; no 71

Figure 4Benefits of a semantic Clinical Data Repository (CDR).

Page 38: Swiss Medical Informatics - SMI 71

Swiss Medical Informatics 2011; no 71

Europe/World

eHealth 2011Health Informatics meets eHealth26.–27.5.2011, Vienna, Austriahttp://www.ehealth2011.at

MIE2011XXIII International Conference of the EuropeanFederation for Medical Informatics (EFMI)28.–31.8.2011 Oslo, Norwayhttp://www.mie2011.org

Events in medical informatics

Switzerland

24. Jahrestagung der SGMI zusammen mit SwisseHealth-Summit 201123.–24.8.2011 BEA bern expo, Bernwww.swissehealthsummit.ch

eHealthcare.ch21.–22.9.2011, GZI-Seminarhotel, Nottwilhttp://www.ehealthcare.ch

Impressum

Herausgeber / Editeur

SGMI, Schweizerische Gesellschaftfür Medizinische InformatikSGMI-Geschäftsstelle:Im Lehn, CH-3116 Kirchdorf BETel. 031 781 46 64E-Mail: [email protected]

Vorstand der SGMI /Comité de la SSIM

Christian Lovis, Präsident, présidentJürg Blaser, Martin Graf, Christian Hay,Jean-Paul Hofstetter, Alain Junger, Marc Oertle,JudithWagner, PascalWalliser

Redaktion / Rédaction

Christian Lovis, Marc Oertle

Umschlagfoto / Photo de couverture:

© Joanne Zh, Dreamstime.com

Review board:

Prof. Christian Lovis, Prof. Jürg Blaser,Dr. Marc Oertle, Dr. PascalWalliser,Dr. JudithWagner, Christian Hay, Alain Junger,Martin Graf, Jean-Paul HofstetterInternational:Prof. Patrice Degoulet, Prof. Bernd Blobel

Redaktionsadresse / Adresse de rédaction

Marc Oertle MD, MScLeitender Arzt Medizin & Medizin-InformatikKrankenhausstrasse 12Spital STS [email protected]

Autorenrichtlinien / Directives pour les auteurs

http://www.sgmi-ssim.ch

Verlag / Editions

Schwabe AGSteinentorstrasse 13, CH-4010 BaselBetreuung imVerlag:Dr. med. Natalie MartyTel. 061 467 85 55 / Fax 061 467 85 56E-Mail: [email protected]

Druck undVersand / Impression et distribution

Druckerei Schwabe AGFarnsburgerstrasse 8, CH-4132 MuttenzTel. 061 467 85 85 / Fax 061 467 85 86E-Mail: [email protected]

Inserate / Régie des annonces

Schwabe AGAriane FurrerAssistentin InserateregieFarnsburgerstrasse 8, CH-4132 MuttenzTel. 061 467 85 88 / Fax 061 467 85 56E-Mail: [email protected]

Abonnemente / Abonnements

Schwabe AG, VerlagsauslieferungFarnsburgerstrasse 8, CH-4132 MuttenzTel. 061 467 85 75 / Fax 061 467 85 76E-Mail: [email protected]

Abonnementspreis / Prix d’abonnement

CHF 40.– (zuzüglich Porto / port en plus)Einzelnummer / Exemplaire uniqueCHF 15.– (zuzüglich Porto / port en plus)

ISSN 1660-0436

erscheint 3-mal jährlichparaît 3 fois par an

NächsteAusgabe:

Proceedings Annual MeetingAugust 2011