TrustX Cabinet Version 3.0

Das IT-System der TrustCenter TrustX Cabinet Version 3.0 Description des interfaces pour les éditeurs de logiciels version du document 1.0 janvier 2011 Résultat de la coopération entre NewIndex, BlueCare et la Caisse des médecins TrustX Management AG Case postale 216 8411 Winterthur trustx@trustx.ch www.trustx.ch

Modifications Version du document Modification Date 1.0 Version 3.0 du TrustX Cabinet 26.01.2011 TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 2 de 37

Table des matières 1 Introduction 5 1.1 Informations générales... 5 1.2 TrustCenter... 5 1.3 Sécurité de HIN... 5 1.4 Interlocuteur... 5 2 TrustX au cabinet médical 6 2.1 Aperçu global du système... 6 2.1.1 L'échange de données avec l'input Gate et le Response Gate du TrustCenter 7 2.1.2 Sécurité et anonymisation... 7 2.1.3 Conditions techniques préalables pour la livraison de données au TrustCenter7 2.2 TrustX-Cabinet... 7 2.2.1 Compatibilité TrustX Cabinet et HIN... 8 2.2.2 Mise à disposition des données: envoi à l'inputgate... 8 2.2.3 Réponses aux factures: réception à partir du Response Gate... 8 2.2.4 Fonctionnement de TrustX-Cabinet... 9 2.2.5 Systèmes d'exploitation pris en charge... 9 2.3 Normes XML prises en charge... 9 3 Produits complémentaires du TrustCenter 10 3.1 Modes de facturation...10 3.1.1 Le principe «aller-chercher» ou pull (Tiers garant)... 10 3.1.2 Le principe «apporter» ou push (Tiers payant)... 10 3.1.3 Dépendances... 11 3.2 Produits complémentaires eda et TX-Print...12 3.3 Gestion des produits complémentaires...13 3.3.1 L'échange électronique des données en tiers garant (eda TG)... 13 3.3.2 eda TP, eda TS et options «Impression & Envoi»... 14 3.3.3 Miroir du cabinet... 14 3.3.4 Résumé... 14 4 Exigences relatives au logiciel médical 15 4.1 Aperçu...15 4.2 Mettre à disposition les factures et les rappels électroniques...15 4.3 Possibilités d'intégration de TrustX-Cabinet...15 4.3.1 Pas d'intégration... 15 4.3.2 Appel de TrustX-Cabinet à partir du logiciel médical... 15 4.3.3 Intégration totale... 16 4.4 Token unique (identificateur de document) pour eda TG...16 4.5 Remarques concernant la gestion des produits complémentaires...16 4.5.1 Option Impression de facture TG... 17 4.5.2 eda TP et TS... 17 4.6 Factures en double / Rappels en double...17 4.6.1 Détection des factures en double dans TrustX-Cabinet... 17 4.6.2 Détection des factures en double dans la base de données des statistiques. 18 4.6.3 Détection des rappels en double dans TrustX-Cabinet... 19 4.6.4 Structure de trustx.log... 20 4.7 Annulation...20 4.7.1 Annulation dans XML 3.0 / 4.0... 20 4.7.2 Annulation dans XML 4.0 pour les factures TP... 20 4.8 XML 4.0...21 4.9 Remarques concernant le NPA dans les factures XML...21 4.10 Nouveau numéro d'avs...21 TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 3 de 37

4.11 Collecte de données pour le miroir du cabinet et l'échange électronique des données via un intermédiaire...21 4.12 Tests et certification...22 4.12.1 TrustCenter «TC test»... 22 4.12.2 Certification... 22 4.12.3 Documentation et téléchargements... 22 5 Description des fonctions de TrustX-Cabinet 23 5.1 Onglet <Aperçu>...24 5.1.1 Variante «Auto»... 24 5.1.2 Variante «Step by Step»... 24 5.1.3 Représentation de l'avancement... 24 5.2 Onglet <Détails>...25 5.3 Onglet <Configuration>...26 5.4 Onglet <Info>...27 5.5 Utilisateurs dans TrustX-Cabinet...27 6 Interface avec TrustX-Cabinet 28 6.1 Introduction...28 6.2 Définitions des interfaces...28 6.3 Événements...29 6.3.1 Classification des événements... 30 6.3.2 Interface pour la réception des événements... 30 6.3.3 Messages (Code)... 31 6.4 Intégrer TrustX...32 6.5 Nom des fichiers...32 6.6 Structure des répertoires...32 6.7 Fichiers importants de TrustX-Cabinet...34 6.7.1 Fichiers programme... 34 6.7.2 Fichiers de configuration et fichiers journaux... 34 7 Annexes 35 Annexe 1: la ligne BVR en tant qu'identificateur de document (Token)...35 7.1.1 Spécification de la ligne BVR en tant qu'identificateur de document (Token). 35 7.1.2 Codage du TrustCenter préfixe du Token... 36 Annexe 2: exemple d'événement TrustX (VB6)...37 TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 4 de 37

1 Introduction 1.1 Informations générales Les TrustCenter initiés par NewIndex ont été créés selon un concept commun. Ils fonctionnent tous avec le même système informatique TrustX, développé spécialement pour les TrustCenter dans le cadre d'une joint-venture entre BlueCare et la Caisse des médecins. Le présent document résume les spécifications des interfaces entre le système de logiciel médical et TrustX. Il sert à l'information et à la documentation des fournisseurs de logiciels médicaux qui souhaitent permettre à leurs clients le raccordement technique à leurs TrustCenters. 1.2 TrustCenter Les TrustCenters ont été créés en vue de collecter et d analyser les données de facturation en provenance des cabinets médicaux. Pour plus d informations à ce sujet, rendez-vous sur www.newindex.ch ou auprès des différents TrustCenters. Vous trouverez également une liste de tous les TrustCenters travaillant avec TrustX sous www.trustx.ch. Les TrustCenter proposent également une solution technique pour l'échange électronique de données de facturation avec les assureurs, basée sur le principe «pull» pour le Tiers garant et «push» pour le Tiers payant. 1.3 Sécurité de HIN TrustX utilise la sécurité de HIN 1. Vous trouverez des informations complémentaires sous www.hin.ch. 1.4 Interlocuteur L'interlocuteur pour les questions techniques et les produits complémentaires est notre assistance. Vous pouvez la joindre pendant les horaires de bureau normaux en appelant le 052 234 70 00 ou par e-mail à l'adresse support@trustx.ch. 1 Health Info Net TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 5 de 37

2 TrustX au cabinet médical 2.1 Aperçu global du système Le système informatique TrustX comprend un grand nombre de modules et de fonctions. L'aperçu ciaprès représente schématiquement la structure logique du système. Datennutzung des Utilisation Données KÄG, SCM, FG, FG, CH CH Centre Nationale de Konsolidierungs Consolidation -stelle (NaKo) (CC) NaKo-Tools TX Security BackBone Anonymisation Arztpraxen supplémentaire de anonymisiert toutes les données de Médecins Arztpraxis Cabinet logiciel du Praxis-SW cabinet TX Cabinet Praxis Miroir Praxisspiegel du Cabinet ROKO Erhebung Enquête Input Gate TrustCenter TX Analyzer TX Admin Print eda Gate Patient Versicherer Assureurs TX Tracer TX Storage Ce document se concentre sur les interfaces entre le cabinet médical et l'inputgate de TrustX, ainsi que sur les processus associés. Vous y trouverez entre autres quelques explications concernant les produits complémentaires de TrustCenter et les exigences relatives aux logiciels de cabinet médical. Outre l'échange électronique des données, le cabinet médical bénéficie également du Miroir du cabinet. Le Miroir du cabinet permet au cabinet médical d'établir une comparaison avec d'autres cabinets médicaux de même type (ensemble de référence). TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 6 de 37

2.1.1 L'échange de données avec l'input Gate et le Response Gate du TrustCenter TrustX-Cabinet transfère de manière électronique par Internet les factures et les rappels au format XML provenant du cabinet médical à l'inputgate du TrustCenter choisi par le médecin. Lors de la réception des données, ce dernier vérifie l'identité de l'émetteur (authentification HIN) et confirme au cabinet la réception des données. Lors de la transmission des rappels, il vérifie également en temps réel que la facture XML associée est connue du système. Avec TrustX-Cabinet, il est également possible de recevoir les réponses aux factures dans le cabinet médical (uniquement pour le Tiers payant) envoyées par le Response Gate du TrustCenter. Les données de facturation transmises sont utilisées d'une part pour l'analyse statistique, et sont d'autre part mises à disposition dans l'eda Gate pour l'échange électronique des données (eda) avec les assureurs. Miroir du cabinet Cabinet Response Gate TrustCenter Input Gate eda Gate Assureurs Centre de calcul avec des données de facturation 2.1.2 Sécurité et anonymisation Pour garantir la sécurité sur Internet (cryptage et authentification de l'émetteur de données) et pour le cryptage des informations relatives aux patients, le système s'appuie sur la sécurité de HIN. Les factures et les rappels sont enregistrés sous forme cryptée et anonymisée dans TrustX. Le décryptage de la facture ou du rappel est exclusivement réalisé dans les deux cas suivants: impression de la facture par un centre de traitement Envoi (eda) à l'assureur 2.1.3 Conditions techniques préalables pour la livraison de données au TrustCenter Les conditions techniques préalables suivantes sont nécessaires pour pouvoir livrer des données en provenance du cabinet médical au TrustCenter: un logiciel médical prenant en charge TrustX TrustX-Cabinet (www.trustx.ch) un accès Internet avec un Client HIN à jour (abonnement HIN, www.hin.ch) 2.2 TrustX-Cabinet TrustX-Cabinet assure l'échange de données entre le cabinet médical et l'inputgate ainsi que le Response Gate du TrustCenter. TrustX-Cabinet est un module logiciel qui dispose de sa propre interface utilisateur et d'une interface qui lui permet d'être directement géré à partir du logiciel médical et peut ainsi y être complètement intégré. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 7 de 37

Cabinet TrustCenter logiciel du cabinet TX Cabinet Response Gate Input Gate Vous trouverez de plus amples informations dans: le chapitre 4.3 «Possibilités d'intégration de TrustX-Cabinet» le chapitre 5 «Description des fonctions de TrustX-Cabinet» le chapitre 6 «Interface avec TrustX-Cabinet» 2.2.1 Compatibilité TrustX Cabinet et HIN Le client HIN impose l utilisation de TrustX Cabinet Version 3 ou supérieure. Les anciennes versions de TX Cabinet ne sont pas compatibles avec le client HIN. Client ASAS Client HIN TrustX-Cabinet Version 2.4.x OUI NON TrustX-Cabinet Version 3 OUI OUI 2.2.2 Mise à disposition des données: envoi à l'inputgate En principe, il convient de transmettre TOUTES les données de facturation au TrustCenter, IMMEDIATEMENT après la facturation au cabinet, et pas seulement celles relatives à la LaMal. Ces conditions sont importantes pour les raisons suivantes: la fourniture de toutes les données de facturation pour les statistiques améliore de manière significative la qualité du collectif de facturation (statistiques), plus la facturation est livrée tôt, plus tôt le Miroir du cabinet sera disponible, En tiers garant il est important que les factures XML soient déjà disponibles dans le TrustCenter si l'assureur souhaite les récupérer au moyen du Token (identificateur de document). C'est pourquoi les factures doivent être transmises immédiatement au TrustCenter, dès la facturation au cabinet. Les factures/rappels XML doivent être mis à disposition dans un répertoire défini par l'utilisateur afin que TrustX-Cabinet les transmette à l'inputgate du TrustCenters correspondant. 2.2.3 Réponses aux factures: réception à partir du Response Gate TrustX-Cabinet prend complètement en charge le tiers payant. Les réponses aux factures sont automatiquement reçues après le transfert de la facture/du rappel et enregistrées dans le répertoire prédéfini. Pour cela, la configuration doit être correcte. Voir aussi les chapitres 5.3 «Onglet <Configuration>» et 6.2 «Définitions des interfaces». TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 8 de 37

Remarque: la réception des réponses aux factures n'est justifiée que si le cabinet médical envoie les factures TP à l'assurance par l'intermédiaire du TrustCenter! 2.2.4 Fonctionnement de TrustX-Cabinet TrustX-Cabinet anonymise les informations relatives aux patients et transmet les factures électroniques cryptées à l'inputgate du TrustCenter. Le Client ASAS HIN est utilisé pour les fonctions de cryptage. TrustX-Cabinet se charge concrètement des tâches suivantes: lecture des données de facturation dans le répertoire défini, vérification formelle des formats de fichier des factures mises à disposition, détermination de l'identificateur personnel 2, cryptage et anonymisation des données personnelles, transfert des données du cabinet médical au TrustCenter (http-put, sécurisé par ASAS), récupération des réponses aux factures. 2.2.5 Systèmes d'exploitation pris en charge TrustX-Cabinet a été testé sous les systèmes d'exploitation suivants 3 : Windows XP / Vista / 7, Windows Server 2008 / 2008 R2 Mac OS X 10. 4. 11 et supérieur Vous pouvez trouver la liste à jour de tous les systèmes d'exploitation pris en charge par HIN sous www.hin.ch. 2.3 Normes XML prises en charge TrustX-Cabinet prend en charge les formats XML suivants: facture du médecin (mdinvoicerequest 4.0) réponse à une facture du médecin (mdinvoiceresponse 4.0) facture du pharmacien (PharmacyInvoiceRequest 4.0) réponse à une facture du pharmacien (PharmacyInvoiceResponse 4.0) rappel de facture (InvoiceReminderRequest 4.0) réponse à un rappel de facture (InvoiceReminderResponse 4.0) facture standard (generalinvoicerequest 4.1) réponse à la facture standard (generalinvoiceresponse 4.1) XML 4.3 est en préparation. Vous trouverez la documentation complète sur les normes XML sur le site Web du Forum Datenaustausch à l'adresse (http://www.forum-datenaustausch.ch/fr/index.htm) À partir du 1 er juillet 2005, la norme XML 4.0 devient obligatoire pour le transfert des données de facturation. TrustX Management AG a arrêté de prendre en charge le format de facture 3.0 fin 2007. Les factures au format XML 3.0 sont rejetées par l'inputgate! 2 Un hashcode (code de hachage) es construit à partir des informations relatives au patient, puis enregistré dans le fichier XML à des fins statistiques. 3 état: janvier 2011. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 9 de 37

3 Produits complémentaires du TrustCenter Le TrustCenter propose, outre le Miroir du cabinet, différents produits complémentaires liés à eda. Ce chapitre présente les modes de facturation, les produits complémentaires, ainsi que les possibilités de commandes qui y sont liées dans le logiciel médical. 3.1 Modes de facturation 3.1.1 Le principe «aller-chercher» ou pull (Tiers garant) Le principe «aller-chercher» ou pull a été introduit pour permettre l implémentation de l'échange électronique de données en Tiers garant. Pour cela, un identificateur de document unique (= Token) est imprimé sur le justificatif de remboursement. Lorsque le patient transmet son justificatif de remboursement à son assureur, celui-ci peut récupérer la copie électronique de la facture dans le TrustCenter correspondant, grâce à cet identificateur de document. 3.1.2 Le principe «apporter» ou push (Tiers payant) Le TrustCenter intervient vis-àvis du médecin et de l'assureur comme intermédiaire de transfert des données électroniques de facturation. Les relations avec le patient disparaissent dans le cas du Tiers soldant. Le TC intervient comme intermédiaire entre le médecin et l'assureur LAA. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 10 de 37

3.1.3 Dépendances Les divers modes de facturation sont soumis à différentes exigences et dépendances. Celles-ci sont rassemblées dans le tableau suivant: Tiers garant (TG) Tiers payant (TP) Tiers soldant (TS) Facture originale remise au patient transmise à l'assureur transmise à l'assureur Réponse à la facture non pris en charge pris en charge pris en charge Rappel techniquement possible mais pas pris en charge pour l'instant pris en charge pour les factures électr. et papier pris en charge pour les factures électr. et papier Format de la facture originale libre erf 4.0 4 erf 4.0 Copie de la facture justificatif de remboursement copie pour le patient (prescrite par LAMal) --- Format de la copie de facture erf 4.0 libre --- Token l identificateur ne doit être imprimé sur le justificatif de remboursement que si une copie électronique de la facture est transmise au TrustCenter et si le médecin participe à eda TG! --- --- BVR --- oui, selon erf 4.0 sur la facture originale oui, selon erf 4.0 sur la facture originale Lois LAMal, LCA, (LAA/AM/AI) LAMal, (LCA) LAA/AM/AI Principe eda principe du aller-chercher (procédé Pull) procédé Push procédé Push 4 erf: elektronisches Rechnungsformular (formulaire électronique de facturation) TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Seite 11 von 37

3.2 Produits complémentaires eda et TX-Print Outre le Miroir du cabinet, les TrustCenters proposent aux cabinets médicaux des produits complémentaires en matière d'échange électronique des données (eda) et d'impression de factures. N ID Produit/opt ion complémen -taire Nom du produit Description / Remarque Loi A1.1 Produit complémen taire eda TG Mise à disposition de factures électroniques TG. (eda TG) toutes les lois A1.2 Option de A1.1 Impression de factures TG Impression et envoi du paquet de factures TG. Le Token est toujours imprimé. (TX-Print TG) toutes les lois A2.1 Produit complémen taire eda TP Livraison des factures électroniques et des rappels TP. (eda TP Push) Livraison des factures/rappels TP eda sur papier. Uniquement si l'assurance ne prend pas en charge eda. (eda TP Print) LAMal, (LCA) A2.2 Option de A2.1 Copie TP pour le patient (copie obligatoire de la facture) TX-Print de la copie obligatoire de la facture TP au patient. (TX-Print TP) LAMal A3 Produit complémen taire eda TS Livraison des factures électroniques et des rappels TS. (eda TS Push) Livraison des factures/rappels TS eda sur papier. Uniquement si l'assurance ne prend pas en charge eda. (eda TS Print) LAA/AM/AI Le produit complémentaire «eda TG» est proposé depuis 2004 et est utilisé par la plupart des cabinets médicaux. Les factures TG représentent plus de 90 % de toutes les factures des médecins. L'«Impression et l'envoi» (D&V) est disponible uniquement en tant qu'option des produits complémentaires «eda TG» et «eda TP». La commande d'un produit complémentaire, sa configuration et son administration sont réalisées via le TrustCenter (TC). Toutes les indications nécessaires sont enregistrées dans TX-Administration sous forme de contrat ou de contrat complémentaire. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 12 de 37

3.3 Gestion des produits complémentaires Les produits complémentaires sont gérés au moyen du flag resend 5 (original/copie). Le tableau suivant présente les différentes possibilités contractuelles (médecin avec/sans TC) et les différentes possibilités de gestion (original/copie) associées. Les informations sur l implémentation dans le logiciel de cabinet sont données au chapitre «4.5 Remarques concernant la gestion des produits complémentaires». Médecin sans TC Médecin avec TC Produits complémentaires eda TG Option Impression de facture TG eda TP Option Copie du patient TP eda TS (A1.1) (A1.2) (A2.1) (A2.2) (A3) Influence du flag Original - N'est pas pris en compte Impression et envoi (D&V) de la facture par le TrustCenter. Transmission de la facture/du rappel à l'assureur Impression et envoi par le TrustCenter. Transmission de la facture/du rappel à l'assureur D&V de rappels n'est pas pris en charge pour l'instant Influence du flag Copie - N'est pas pris en compte La facture/le rappel n'est pas imprimé(e) La facture/le rappel n'est pas transmis(e) à l'assureur Aucune copie pour le patient n'est créée La facture/le rappel n'est pas transmis(e) à l'assureur Imprimer le Token? NON OUI 6 OUI - - - Indépendamment des attributs éventuels de gestion des produits complémentaires, toutes les factures des cabinets médicaux reliés à un TrustCenter sont envoyées dans le Miroir du cabinet. Vous pouvez trouver des informations complémentaires dans les chapitres suivants. 3.3.1 L'échange électronique des données en tiers garant (eda TG) Pour permettre le fonctionnement de l eda TG, le cabinet doit: valider le produit complémentaire «eda TG» vis-à-vis du TrustCenter (contrat), imprimer le Token sur le justificatif de remboursement, envoyer la facture électronique au TrustCenter immédiatement après la facturation. Si l'eda TG n'est pas validé vis-à-vis du TrustCenter ou si les factures ne sont pas transmises électroniquement au TrustCenter, il ne faut imprimer aucun Token sur le justificatif de remboursement. Le Token imprimé sur le justificatif de remboursement constitue pour l'assureur l'information-clé qui signifie que la facture TG correspondante est disponible et peut être récupérée dans le TrustCenter correspondant. Si les factures ne sont pas trouvées dans le TrustCenter, cela représente un travail supplémentaire important pour l'assureur. 5 Sous le nom de flag resend, il faut comprendre l'élément resend (10170) du fichier XML. Original: resend = false, copie: resend = true. 6 Uniquement si le médecin prend part à l'eda avec l'assureur! TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 13 de 37

3.3.2 eda TP, eda TS et options «Impression & Envoi» Les critères suivants doivent être satisfaits pour permettre l'utilisation des produits complémentaires Échange électronique des données en tiers payant (eda TP) et Échange électronique des données en tiers soldant (eda TS), ainsi que des options Impression de facture TG et Copie patient TP: le cabinet médical doit conclure un contrat avec le TrustCenter pour les produits complémentaires ou les options correspondants, la gestion fine des produits et options complémentaires figurant dans le contrat est réalisée à l'aide du flag resend. seules les factures originales (resend=false) sont traitées. Si une facture TG est transmise par erreur deux fois sous forme de facture originale au TrustCenter, elle sera imprimée et transmise deux fois. Si des factures sont transmises au TrustCenter sous forme de facture originale, sans que les produits complémentaires évoqués ci-dessus aient été commandés par le cabinet médical au TrustCenter, les prestations complémentaires ne seront pas fournies. Si un cabinet sélectionne l'eda TP ou l'eda TS, toutes les factures originales décrites ci-dessus sont transmises par le TrustCenter. Si la communication électronique n'est pas possible avec certains assureurs, la facture est automatiquement imprimée et envoyée par la poste. Cette méthode assure que toutes les factures originales arrivent chez l'assureur correspondant, indépendamment du moyen de transport. Le traitement des rappels est uniquement effectué lorsque les conditions suivantes sont remplies: un contrat doit avoir été établi entre le cabinet médical et le TrustCenter pour les produits complémentaires eda TP et/ou eda TS, la facture XML associée au rappel XML doit exister dans le système TrustX, il doit s'agir de l'original pour le rappel XML (resend = false). 3.3.3 Miroir du cabinet La gestion par le logiciel médical n'est PAS nécessaire pour le Miroir du cabinet. Par principe, toutes les factures sont envoyées au Miroir du cabinet. Les factures transmises éventuellement en double sont éliminées au niveau statistique. Le flag resend n'est pas pris en compte. 3.3.4 Résumé Outre la condition de base que représente le contrat entre le cabinet et le TrustCenter, les éléments suivants déterminent la gestion: eda TG: Token sur le justificatif de remboursement. eda TP, eda TS, Impression & Envoi des factures TG ou copies patient TP: seules les factures originales sont traitées. Miroir du cabinet: il n'y a pas de gestion, le Token, la facture originale et le flag resend sont sans importance. Les factures livrées en double sont éliminées de statistiques. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 14 de 37

4 Exigences relatives au logiciel médical 4.1 Aperçu Tous les fichiers de factures XML sont transférés par le logiciel de cabinet via un répertoire dans TrustX Cabinet. TrustX-Cabinet peut être utilisé soit avec sa propre interface utilisateur (chapitre 5 «Description des fonctions de TrustX-Cabinet» ), soit par l'intermédiaire d'une interface, directement à partir du logiciel médical (chapitre 6 «Interface avec TrustX-Cabinet») et y est ainsi totalement intégré (chapitre 4.3 «Possibilités d'intégration de TrustX-Cabinet»). Il convient de veiller particulièrement aux éléments suivants: le Token (=identificateur de document) ne doit être imprimé sur le justificatif de remboursement (TG) que si le médecin est relié à un TrustCenter, le médecin prend part à eda TG (cas général), le Token doit être unique pour chaque facture (même pour les factures corrigées). il existe des possibilités de gestion des produits complémentaires. Cela signifie en particulier que le flag resend (original/copie) peut être positionné de manière différenciée pour la gestion fine. les annulations doivent être codées correctement. Dans les chapitres suivants, vous trouverez des explications complémentaires relatives à ces points, ainsi qu'à d'autres éléments concernant la connexion de TrustX-Cabinet. 4.2 Mettre à disposition les factures et les rappels électroniques Les copies électroniques de facture, les annulations, ainsi que les rappels doivent être mises à disposition dans le répertoire correspondant sous les formats pris en charge (voir chapitre «2.2.1 Compatibilité TrustX Cabinet et HIN»). Aucune modification des factures électroniques n'est ainsi nécessaire pour qu'elles puissent être transmises par TrustX-Cabinet au TrustCenter. Les factures doivent simplement être enregistrées dans un répertoire. L'anonymisation, le cryptage et la transmission à l'inputgate sont réalisés par TrustX-Cabinet. 4.3 Possibilités d'intégration de TrustX-Cabinet TrustX-Cabinet peut être intégré à différents degrés dans un logiciel médical: 4.3.1 Pas d'intégration En principe, aucune intégration de TrustX-Cabinet dans le logiciel médical n'est nécessaire. Il suffit d'imprimer le justificatif de remboursement avec son identificateur de document et de mettre les fichiers de facture électroniques dans un répertoire pour des traitements ultérieurs (lecture, contrôle, anonymisation, envoi) dans un répertoire. TrustX-Cabinet peut être lancé indépendamment du logiciel médical afin de réaliser les étapes suivantes, et même sur un autre ordinateur. 4.3.2 Appel de TrustX-Cabinet à partir du logiciel médical Pour faciliter au médecin l'échange de données avec le TrustCenter, il est possible d'appeler TrustX- Cabinet à partir du logiciel médical. L'utilisateur peut ensuite utiliser l'interface de TrustX-Cabinet pour travailler. Aucune autre interaction entre le logiciel médical et TrustX-Cabinet n'est nécessaire. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 15 de 37

Du point de vue technique, il existe deux possibilités pour une telle intégration: appel de TrustX-Cabinet à partir de la ligne de commande configuration via l'interface (voir 6.2 «Définitions des interfaces»). Ceci permet en outre de configurer dans TrustX-Cabinet d'autres paramètres de configuration connus par le logiciel médical, par exemple le répertoire des factures. Ensuite, appel de TrustX-Cabinet à partir de la ligne de commande. 4.3.3 Intégration totale TrustX-Cabinet peut être géré intégralement à partir du logiciel médical: l'interface de TrustX-Cabinet demeure invisible, les messages envoyés par TrustX-Cabinet à votre logiciel médical sont traités directement par ce dernier. Cette variante présente l'avantage qu'il est possible de réagir aux messages d'erreur envoyés par TrustX-Cabinet directement à partir du logiciel médical. De plus, le logiciel médical peut proposer les fonctionnalités de TrustX-Cabinet à partir de sa propre interface. Ceci permet d'offrir un grand confort à l'utilisateur, mais demande un plus grand effort de développement de la part du fournisseur du système de logiciel médical. L affichage correct des messages ainsi que la mise à jour du logiciel sont de la responsabilité du fabricant du logiciel de cabinet lors de l intégration complète. Vous trouverez des informations complémentaires sur l interface au chapitre «6 Interface avec TrustX-Cabinet». 4.4 Token unique (identificateur de document) pour eda TG Les justificatifs de remboursement (TG) doivent être dotés d'un Token (identificateur de document) si l'on doit offrir à l'assureur la possibilité de récupérer les factures par le procédé Pull dans le TrustCenter. La ligne BVR de la facture constitue la base de cet identificateur de document. Le système exige que l'identificateur de document soit unique pour chaque facture. Ceci est facile à obtenir grâce au numéro BVR, puisque celui-ci est établi hiérarchiquement. Les différents participants BVR sont identifiés de manière unique. L'attribution de numéros BVR uniques relève donc de la responsabilité du cabinet. Pour que l'échange de données fonctionne sans problème, il est nécessaire que les factures corrigées soient également munies de nouveaux numéros BVR. Ceci est possible grâce à des numéros de facture uniques, par exemple. Pour créer un Token, la ligne BVR est modifiée de sorte que le TrustCenter soit codé à la place du type de justificatif (premier et deuxième chiffre). Le chiffre de contrôle en position 13 doit être adapté en conséquence. Voir les détails dans «l Annexes» à ce sujet. Le Token ne doit être imprimé qu'aux conditions suivantes: uniquement en mode de facturation TG, uniquement si le médecin est relié à un TrustCenter, uniquement si le médecin prend part à l'eda avec l'assureur. 4.5 Remarques concernant la gestion des produits complémentaires Le mécanisme de gestion des produits complémentaires est décrit en détail dans le chapitre 3.3 «Gestion des produits complémentaires». Vous trouverez ci-après quelques remarques indiquant les conséquences pour l'implémentation dans le logiciel médical. Il s'agit essentiellement de pouvoir déterminer via le logiciel médical, au niveau de chaque facture, si celle-ci doit être transmise comme original ou comme copie au TrustCenter, et si la facture doit être imprimée ou non dans le cabinet dans le cadre de sa facturation. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 16 de 37

4.5.1 Option Impression de facture TG Si le cabinet médical décide d'imprimer les factures au TrustCenter, il est important de ne pas transmettre de facture/justificatif de remboursement en double au patient. Ce risque existe si une facture est remise au patient sous forme de «Facture immédiate» juste après la consultation. Dans ce cas, la facture doit être transmise comme copie (resend=true) au TrustCenter. Des factures en double sont également envoyées aux patients si la même facture est transmise plusieurs fois comme original au TrustCenter. 4.5.2 eda TP et TS Lorsque l'échange électronique de données est réalisé selon le principe Push (eda TP et eda TS), il peut être intéressant de pouvoir désigner une facture en tant qu'«original/copie» avec «Impression au cabinet Oui/Non», mais également de pouvoir le faire pour différents assureurs et lois. Le médecin peut ainsi distinguer/gérer les cas suivants: un contrat eda existe entre l'assureur X et le TC: envoyer les factures en tant que documents originaux. Les factures sont ainsi transmises à l'assureur par le TC en mode push (par voie électronique). pas de contrat eda entre l'assureur Y et le TC: envoyer les factures en tant que copies au TC et les imprimer soi-même. 4.6 Factures en double / Rappels en double Les factures ou les rappels XML en double sont détectés par TrustX à deux endroits. TrustX-Cabinet détecte tout d'abord les doublons sur la base de différents critères avant même leur envoi à l'inputgate. Après leur envoi, une détection des doublons est également réalisée au moment du processus d'écriture dans la base de données des statistiques. La norme XML 4.0 exige qu'une facture/qu'un rappel soit identifié de manière unique par ces trois champs: Facture Rappel Biller_EAN (11402) Biller_EAN (11402) Invoice_ID (10153) Reminder_ID (10186) Invoice_TimeStamp (10152) Reminder_TimeStamp (10185) 4.6.1 Détection des factures en double dans TrustX-Cabinet Afin de détecter les factures en double, différentes informations de la facture sont enregistrées dans trustx.log au cours de l'envoi de cette dernière. Ce sont (en bleu = en plus par rapport à XML 4.0): Information de la facture Remarque Biller_EAN (11402) selon XML 4.0 Invoice_ID (10153) selon XML 4.0 Invoice_TimeStamp (10152) selon XML 4.0 TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 17 de 37

Provider RCC (11803) Amount (10330) Invoice / tierspayant / purpose (11265) Représente l'identification unique d'un client du TrustCenter dans le système TrustX en conjonction avec l'indication du TrustCenter. Sert à distinguer la facture de l'annulation (dans le fichier journal). Indication de l'objet de la facture dans le cas d une annulation TP pour distinguer la facture de l'annulation (dans le fichier journal). Ces six valeurs doivent identifier une facture de manière unique. Si une valeur diffère, il ne s'agit alors plus d'un doublon et le fichier XML peut être envoyé à l'inputgate du TrustCenter. Si le fichier journal trustx.log ou l'une de ses entrées est supprimée, il est possible d'éviter la détection des doublons. Cela n'est toutefois pas recommandé et doit uniquement être fait dans certains cas particuliers, lorsqu'une facture doit être réimprimée dans le TrustCenter par exemple. 4.6.2 Détection des factures en double dans la base de données des statistiques Il arrive régulièrement que des factures soient transmises plusieurs fois au TrustCenter par erreur. Le mécanisme utilisé lors du processus d'écriture dans la base de données des statistiques détecte également les factures en double et les marque afin qu'elles ne soient pas prises en compte dans les statistiques. Les factures en double sont détectées selon les critères suivants (jaune = vérification supplémentaire par rapport à TrustX-Cabinet): Information de la facture Remarque Biller_EAN (11402) selon XML 4.0 Invoice_ID (10153) selon XML 4.0 Invoice_TimeStamp (10152) selon XML 4.0 Provider RCC (11803) Amount (10330) Invoice / tiers_payant / purpose (11265) TrustCenter Biller ZSR (11403) Patient-Id (16720) Représente l'identification unique d'un client du TrustCenter dans le système TrustX en conjonction avec l'indication du TrustCenter. Sert à distinguer la facture de l'annulation. Indication de l'objet de la facture en cas d'une annulation TP pour distinguer la facture de l'annulation. Représente l'identification unique d'un client du TrustCenter dans le système TrustX en conjonction avec l'indication du Provider RCC. Toutes les parties impliquées dans la facturation sont prises en compte Similaire au Biller RCC. Les factures en double sont indiquées dans TX Tracer avec le Q-Index 4 et le message «Facture en double» IMPORTANT: Les factures envoyées plusieurs fois à l'inputgate sont uniquement éliminées dans la base de données des statistiques. Elles sont quand même traitées plusieurs fois lors des traitements ultérieurs (eda TG et eda TP/TS)! TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 18 de 37

4.6.3 Détection des rappels en double dans TrustX-Cabinet Les rappels en double sont détectés de manière analogue aux factures en double. Pour ce faire, les informations de rappel suivantes sont enregistrées dans trustx.log: Information de la facture Remarque Biller_EAN (11402) selon XML 4.0 Reminder_ID (10186) selon XML 4.0 Reminder_TimeStamp (10185) selon XML 4.0 Amount (10330) Sert à distinguer la facture de l'annulation (dans le fichier journal). Comme les rappels ne sont pas importés dans la base de données des statistiques, il n'est pas nécessaire d'y effectuer une détection des doublons. IMPORTANT: les rappels envoyés plusieurs fois à l'inputgate sont traités plusieurs fois! TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 19 de 37

4.6.4 Structure de trustx.log Le fichier journal trustx.log permet de détecter les doublons en local et possède la structure suivante: N de facture (Invoice_ID) / Montan t TimeStamp «Envoyer» Provider RCC Biller EAN Invoice_ TimeStamp / tp purpose N de rappel (Reminder_ID) Reminder_ TimeStamp 0016997-00574/17 0016997-00574/17 0016997-00574/17 469.60 1179811727 L123488 7601000030108 1173139917 0 1) -469.60 1179819677 L123488 7601000030108 1173139917 0 2) 469.60 117981967 L123488 7601000030108 1173139917 1 3) REM - 574/17 469.60 1179814541 7601000030108 1173164799 0 4) 1) Facture 2) Annulation variante 1 (montants négatifs, possible pour les factures TG et TP) 3) Annulation variante 2 (tp purpose, uniquement pour les factures TP) 4) Rappel A partir de la version 2.3 de TrustX-Cabinet, l'écriture dans trustx.log à lieu dès que la facture est transmise (auparavant, après la session). La fiabilité est ainsi améliorée en cas d'interruption de la transmission. 4.7 Annulation 4.7.1 Annulation dans XML 3.0 / 4.0 Les annulations sont à transmettre accompagnées du même numéro BVR avec toutes les zones de montant multipliées par -1. Tous les autres champs restent inchangés. Dans la définition de la facture XML-Invoice, les champs <Acompte> (10335) et <Montant net arrondi de la facture> (10340), sans importance pour les statistiques, doivent être nuls ou positifs. Ceux-ci seront mis à zéro plutôt qu'à une valeur négative. Cette méthode permet de procéder à une correction statistique. 4.7.2 Annulation dans XML 4.0 pour les factures TP Dans la norme XML 4.0, une facture TP avec le champ 11265 (XML 4.0) = «annulment» (request / invoice / tiers_payant / purpose) est également reconnue comme une annulation. Les versions Windows 2.1.14 et MAC 2.1.15 (ou antérieures) de TrustX-Cabinet ne peuvent toutefois pas traiter le champ purpose (11265). C'est pourquoi il a été nécessaire de réaliser un workaround en mettant le <Montant total> (10330) à une valeur négative. A partir de la version 2.2 de TrustX-Cabinet, le champ purpose (11265) est également exploité et une annulation indiquée de cette manière peut donc être reconnue. Il n'est donc plus de mettre le montant total à une valeur négative dans la mesure où «annulment» est défini pour request / invoice / tiers_payant / purpose. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 20 de 37

4.8 XML 4.0 À partir du 1 er juillet 2005, la norme XML 4.0 devient obligatoire pour le transfert des données de facturation. TrustX Management AG a arrêté de prendre en charge le format de facture 3.0 fin 2007. Les factures au format XML 3.0 sont rejetées par l'inputgate. XML 4 prend désormais explicitement en charge le principe «aller chercher» (procédé Pull) dans le Tiers garant (champs 11151-11153). Il est ainsi possible d'enregistrer également le Token imprimé sur le justificatif de remboursement dans le fichier XML. Dans le cas des factures TG, ces champs sont remplis comme suit: tc_demand_id (11151) = 0 tc_demand_id est défini par le TrustCenter lors de l'envoi de la facture. Ce champ est cependant obligatoire, c'est pourquoi la valeur 0 y est inscrite. tc_token (11152) = Token Exemple: 5000001570507>332435000001111122222333337+ 010033018> insurance_demand_date (11153) = Date de traitement au cabinet médical La date sera également définie correctement par le TrustCenter. Ce champs est cependant obligatoire, c'est pourquoi la date de facturation doit être indiquée. Nous vous offrons la possibilité de faire certifier vos logiciels avec XML 4. Vous trouverez des informations complémentaires concernant la certification au chapitre «0 Le permet de gérer les données de test transmises. L'authentification par le Client des données de test peut y accéder. L'URL d'accès». 4.9 Remarques concernant le NPA dans les factures XML La norme XML définit le champ destiné au NPA (Element postal/zip) comme String (9). Jusqu'à la version 2.1, TrustX-Cabinet a calculé un ID-patient valide uniquement pour les numéros postaux d'acheminement (NPA) suisses composés de quatre chiffres. Pour les autres NPA (les NPA étrangers), une erreur d'id-patient était générée et les factures XML n'étaient prises en compte que de manière partielle dans les statistiques. A partir de la version 2.3, TrustX-Cabinet prend également en charge les numéros postaux d'acheminement étrangers. IMPORTANT: il est essentiel que les NPA soient saisis selon les directives du pays en question, c'està-dire sous la forme d'un nombre à 4 chiffres pour la Suisse, afin que l'exploitation statistique puisse être réalisée. Pour les adresses à l'étranger, la norme XML impose que le pays (élément postal/zip/countrycode=) soit explicitement indiqué (si ce n'est pas le cas, le pays par défaut est CH) 4.10 Nouveau numéro d'avs Le nouveau numéro d'avs à 13 chiffres est également autorisé selon le schéma XML (de manière analogue au numéro à 11 chiffres). Les éléments ssn autorisent la structure suivante: "[1-9][0-9]{10}") [1-9][0-9]{12}". 4.11 Collecte de données pour le miroir du cabinet et l'échange électronique des données via un intermédiaire En général, l'échange électronique des données et la collecte des données pour le Miroir du cabinet sont réalisés par le TrustCenter. Le TrustCenter (numéro EAN) est alors inscrit comme intermédiaire sur la facture XML (champ 10052). Si les factures XML pour l'eda sont transmises à un assureur par un autre moyen, par exemple via MediData ou H-Net, les factures peuvent néanmoins être transmises au TrustCenter à des fins statistiques. Il faut pour cela respecter les conditions suivantes: laisser comme intermédiaire le numéro EAN du transporteur (champ 10052), la facture doit être une copie. C'est pourquoi il faut indiquer que la facture est une copie (resend = true, champ 10170). TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 21 de 37

Le risque de voir une facture arriver deux fois chez l'assureur n'existe pas, même si une facture est transmise par un transporteur sous forme d'original au TrustCenter à des fins statistiques, car une facture n'est transmise que si le cabinet médical a explicitement souscrit les produits complémentaires eda TP ou eda TS auprès du TrustCenter. Dans le cas d'eda TG, le risque n'existe pas, car l'impression du Token sur le justificatif de remboursement indique où la facture peut être récupérée. 4.12 Tests et certification 4.12.1 TrustCenter «TC test» Un TrustCenter de test, «TC test», est disponible pour réaliser des tests. Nous vous prions d'utiliser EXCLUSIVEMENT «TC test» pour les tests. Veuillez n'exécuter AUCUN test avec des TrustCenter en production, car les factures de test seront sinon intégrées aux statistiques du TrustCenter. Pour les envois de test avec «TC test», vous devez avoir démarré votre Client HIN ASAS. L'inscription auprès de «TC test» n'est pas nécessaire. Le TrustX Data Monitor (TDM) est disponible pour l'inputgate de «TC test». Il permet de gérer les données de test transmises. L'authentification par le Client ASA HIN garantit que seul l'expéditeur des données de test peut y accéder. L'URL d'accès est la suivante: http://test.trustx.hin.ch/cgibin/sitemgr.pl. Les clients du TrustCenter ont en outre la possibilité de consulter les données envoyées au moyen de l InputGate LogViewer. Le logiciel InputGate LogViewer fournit des indications supplémentaires concernant la qualité des factures. 4.12.2 Certification Tout éditeur de logiciel médical peut faire certifier ce dernier. L'objectif de la certification consiste à garantir que les produits complémentaires sont pris en charge et la qualité des factures XML. L'éditeur, ainsi que l'utilisateur, obtiennent ainsi l'assurance que la qualité des factures répond aux différentes exigences des assureurs et de TMA. Vous trouverez une description détaillée du processus de certification à l'adresse http://www.trustx.ch/f/system_datenanlieferung_4.asp 4.12.3 Documentation et téléchargements Vous trouverez des informations concernant TrustX à l'adresse www.trustx.ch. Toutes les informations spécifiques concernant TrustX-Cabinet, comme ce document, figurent à l'adresse www.trustx.ch/trustx-praxis. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 22 de 37

5 Description des fonctions de TrustX-Cabinet TrustX-Cabinet est un composant logiciel doté de sa propre interface utilisateur et d'une interface qui permet de le gérer directement à partir du système logiciel médical. (Voir chapitre 6 «Interface avec TrustX-Cabinet»). TrustX-Cabinet dispose d'une fonction de mise à jour automatique par Internet. A partir de la version 2.2, il est également possible de gérer les mises à jour directement via l'interface. Il est ainsi possible de conserver une version à jour de TrustX-Cabinet de manière très simple. Si l'utilisateur est d'accord, le programme d'installation est chargé sur l'ordinateur de l'utilisateur suite à la transmission des données vers le TrustCenter. L'interface d'utilisation de TrustX-Cabinet affiche en haut le TrustCenter choisi et son login ASAS. Elle est structurée en quatre onglets: <Aperçu> <Détails> <Configuration> <Info> exemple) Contient toutes les fonctions de commande importantes Permet de visualiser les différents répertoires et les fichiers journaux Permet de configurer TrustX-Cabinet Donne des informations sur TrustX-Cabinet (version actuelle, par En bas à gauche se trouve un bouton qui permet d'ouvrir l'inputgate Log Viewer et de consulter les factures transmises en ligne. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 23 de 37

5.1 Onglet <Aperçu> L'onglet <Aperçu> comprend toutes les informations essentielles pour le traitement et l'envoi des données de facturation vers l'inputgate de votre TrustCenter. TrustX-Cabinet peut être utilisé suivant deux variantes: 5.1.1 Variante «Auto» La touche <Auto> permet de traiter automatiquement toutes les étapes avec les paramètres de configuration présélectionnés. La barre bleue indique l'avancement du traitement. 5.1.2 Variante «Step by Step» La variante «Step by Step» permet de procéder pas à pas. Les différentes étapes sont lancées en appuyant sur les touches correspondantes. Ici, ce sont également les paramètres de configuration présélectionnés qui sont utilisés. <Lire> <Vérifier> <Anonymiser> <Envoyer/Recevoir> <Collecter> Les données du «répertoire des factures» (défini dans l'onglet <Configuration>) sont lues puis supprimées de celui-ci. Vérification de l exactitude syntaxique des données. Les données sont cryptées et anonymisées. 5.1.3 Représentation de l'avancement Les données sont envoyées à l'inputgate du TrustCenter (factures) ou reçues à partir du Response Gate (rappels) La connexion Internet est établie et coupée par TrustX-Cabinet en fonction des réglages d'internet Explorer, le cas échéant. Les données sont déplacées dans le répertoire des réponses (défini dans l'onglet <Configuration>). Un résumé des fichiers traités apparaît dans la partie blanche. Les erreurs éventuelles sont affichées pour chaque facture en fonction de l'étape concernée. Un double-clic sur la facture incorrecte permet d'afficher la facture et le détail des entrées correspondantes du fichier journal. Voir aussi 5.2 «Onglet <Détails>», page 25. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 24 de 37

5.2 Onglet <Détails> L'onglet <Détails> affiche différents détails. Les champs de sélection (en haut) permettent d'afficher les listes correspondantes dans la fenêtre située en dessous. <Pas encore envoyé> <Archives> La liste des factures disponibles (pas encore traitées) et pas encore envoyées se trouvant dans le «répertoire des factures» est affichée. La liste des factures envoyées avec succès est affichée. < Erreurs> La liste des fichiers de factures erronés des étapes 2 <Vérifier> et 3 <Anonymiser> est affichée. <Logs> Cette liste reprend les journaux existants, triés par date. Un double-clic sur un élément de la liste permet d'afficher la facture correspondante et le détail des entrées correspondantes du fichier journal. Exemple d'une facture avec les entrées correspondantes du fichier journal. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 25 de 37

5.3 Onglet <Configuration> L'onglet «Configuration» permet de saisir tous les paramètres nécessaires au traitement et à l'envoi des données de facturation. <TrustCenter> <Répert. des factures> <Répertoire des réponses> <Répertoire de base> <Recevoir les réponses aux factures pour les numéros RCC suivants> <Archiver> <login ASAS> Choisissez votre TrustCenter dans la liste. Pour les tests, utilisez «TC test». Les factures sont déplacées du <répertoire des factures> au répertoire «input» (voir étape «Lire»). Le répertoire «input» est prédéfini de manière fixe dans TrustX-Cabinet et se trouve dans le répertoire de base. Les réponses aux factures sont déplacées du répertoire «responses» au <Répertoire des réponses> (voir étape «Collecter»). Le répertoire «responses» est prédéfini de manière fixe dans TrustX-Cabinet et se trouve dans le répertoire de base. Le «Répertoire de base» représente le répertoire où TrustX-Cabinet crée différents sous-répertoires nécessaires à son fonctionnement. Voir «Les fichiers de facture peuvent porter des noms quelconques.» (page 32). Indiquez ici le ou les numéros RCC pour lesquels vous souhaitez recevoir les réponses aux factures. vide: aucune réponse n'est recherchée «*»: toutes les réponses pour le login ASAS configuré sont recherchées RCC1, RCC2 : liste de numéros RCC séparés par des virgules. toutes les réponses correspondant aux numéros RCC indiqués pour le login ASAS en cours sont recherchées L'option «Archiver» détermine si les fichiers de facture envoyés avec succès sont archivés ou supprimés. Les fichiers de facture sont archivés sous la même forme que celle sous laquelle ils ont été envoyés, c est-à-dire anonymisés et cryptés. Ce champ détermine le login ASAS utilisé par TrustX-Cabinet pour crypter et transférer les données. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 26 de 37

5.4 Onglet <Info> L'onglet <Info> indique le numéro de la version de TrustX- Cabinet et du Client ASAS HIN, ainsi que d'autres informations. 5.5 Utilisateurs dans TrustX-Cabinet A partir de la version 2.2, TrustX-Cabinet est multi-utilisateurs. Toutes les données (factures, réponses aux factures, fichiers journaux, paramètres) sont ainsi enregistrées dans le profil utilisateur correspondant. Cette fonction est particulièrement intéressante dans le cas où TrustX-Cabinet doit être utilisé avec sa propre interface utilisateur. Il n'est alors pas nécessaire de le reconfigurer si chaque utilisateur travaille avec son propre profil. En cas de besoin, les intermédiaires peuvent travailler avec leur propre répertoire de base par mandant / TrustCenter. Ce dernier peut être défini au moyen de l'interface. L'utilisation de répertoires propres aux utilisateurs présente par exemple l'avantage que les factures erronées et que les fichiers journaux sont enregistrés séparément. Le traitement ultérieur en est ainsi simplifié. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 27 de 37

6 Interface avec TrustX-Cabinet 6.1 Introduction TrustX-Cabinet peut être géré à partir d'applications via une interface. Ceci est défini dans le «OMG IDL» (voir 0 «Fehler! Ungültiger Eigenverweis auf Textmarke.»). Les définitions des interfaces pour les différents systèmes d'exploitation et technologies sont générées à partir de cette définition. Il s'agit de «COM» pour Windows et d'«apple Events» pour Mac OS X. TrustX-Cabinet génère des messages détaillés qui sont renvoyés à l'application appelante (voir 6.3 «Événements»). 6.2 Définitions des interfaces Remarques: les modifications par rapport à TrustX-Cabinet version 2.4 sont surlignées en jaune Pour une meilleure compréhension, voir aussi le chapitre 0 «Vous trouverez des informations concernant l'adresse www.trustx.ch. Toutes les informations spécifiques concernant TrustX- Cabinet, comme». Définitions des interfaces Remarque // $Id: trustx.idl,v 1.6 2007/03/26 07:46:18 franco Exp $ #include "client.idl" module Trustx { interface ITrustx { typedef sequence<string> strings; readonly attribute string trustxversion readonly attribute strings trustcenters attribute string trustcenter attribute string inputdirectory attribute string workdirectory attribute boolean withpdf; attribute boolean witharchive; readonly attribute string BVR; readonly attribute string esrpdf; Version de TrustX-Cabinet Liste de tous les TrustCenters Sélectionner un TrustCenter Chemin d'accès au répertoire des factures Chemin d'accès au répertoire de base ou de travail Option copie électronique de facture et fichier PDF Option d'archivage des factures envoyées Lire le code du TrustCenter pour «identificateur de document sans PDF», dépend du TrustCenter choisi Lire le code du TrustCenter pour «Identificateur de document avec PDF» readonly attribute string session; La date est utilisée pour désigner la session (ex. 2003-08-29). Utilisé pour construire le nom des sous-.répertoires et des fichiers. (ex:...\{répertoire de base}\logs\<session>.log readonly attribute string asasversion; Lire la version du Client ASAS readonly attribute strings asaslogins; Afficher la liste des logins ASAS disponibles attribute string asaslogin; Attribuer un login ASAS à TrustX-Cabinet attribute boolean activategui; attribute boolean debug; void Auto(); void Read(); Pas implémenté pour l'instant, voir chapitre «Appel de TrustX-Cabinet à partir du logiciel médical», page 15. Générer des messages de débogage oui/non Traitement et envoi automatiques des fichiers de facture, comme avec le bouton <Auto> Déplacement des fichiers de facture de..\{répertoire des TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 28 de 37

Définitions des interfaces void Check(); void Anonymize(); void Send(); void Cancel(); void Write(); // Added in V2.1 readonly attribute string ean; readonly attribute string tctel; // Added in V2.2 attribute string outputdirectory; readonly attribute string iglog; attribute boolean autoupdate; readonly attribute updateavailable; attribute boolean responsemessagesenabled; attribute string zsrdownfilter; Remarque factures}\.. au..\{répertoire de base}\input, comme avec le bouton <Lire> Vérification de l'exactitude syntaxique des données. Les données sont lues dans..\{répertoire de base}\input et écrites dans..\{répertoire de base}\valid, si elles sont correctes ou dans..\{répertoire de base}\err dans le cas contraire. Anonymisation (Modul mopanonymizer) et cryptage (Modul mopencrypter) des fichiers de facture. Lecture dans..\{répertoire de base}\valid. Écriture dans..\{répertoire de base}\output ou dans..\{répertoire de base}\err en cas d'erreur. Les données de facturation sont envoyées à l'inputgate du TrustCenter à partir de..\{répertoire de base}\output. Lorsque les données de facturation et les images sont présentes, elles sont envoyées ensemble, de sorte que soit les deux sont envoyés avec succès soit aucune des deux. Il y a néanmoins un message par fichier. Le traitement est interrompu. Les réponses aux factures sont copiées du répertoire..\{basisverzeichnis}\responses au répertoire des réponses défini (outputdirectory). (depuis la version 2.2) Lire le numéro EAN du TrustCenter, dépend du TrustCenter choisi Lire le numéro de téléphone du TrustCenter, dépend du TrustCenter choisi (pour les demandes d'assistance) Chemin d'accès au répertoire des réponses aux factures Lien vers l'inputgate Log Viewer Indique si trustx.dll gère les mises à jour logicielles luimême. La valeur par défaut est «true» Indique si une mise à jour logicielle existe. Indique si les messages liés aux réponses aux factures sont générés. La valeur par défaut est «false» Filtre pour la recherche des réponses aux factures. Indique les numéros RCC pour lesquels les réponses aux factures doivent être reçues. Valeurs possibles: vide aucune réponse n'est recherchée * toutes les réponses pour le login ASAS en cours sont recherchées }; }; // Added in V3 readonly attribute string getupdatemsg; RCC1,RCC2 liste de numéros RCC séparés par des virgules. Toutes les réponses correspondant aux numéros RCC indiqués pour le login ASAS en cours sont recherchées Edite le message de mise à jour qui est enregistré sur le serveur. 6.3 Événements Chaque module TrustX génère des messages qui sont renvoyés à l'application appelante pour chaque fichier traité. Les messages sont classés en fonction du niveau, de la classe et de l'origine et concernent, en règle générale, un fichier donné. Ceci permet un suivi précis de l'état d'avancement du traitement par module et par fichier. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 29 de 37

Au début et à la fin d'un module, un message correspondant au niveau de message mlinfo est émis. Pendant le traitement, au moins un message explicite par fichier avec le niveau de message «mlinfo & MessageOrigin» du module, ainsi que le code correspondant pour OK ou un message d'erreur sont envoyés. La classification des événements est la suivante: 6.3.1 Classification des événements Classification enum MsgLevel { mldebug = 0, }; mlinfo = 1, mlwarning = 2, mlerror = 3, mlfatal = 4, Remarque Message Level (niveau du message) Durant l'exploitation normale, ces messages peuvent être ignorés. Ils servent à la recherche et à l'analyse des erreurs. Ces messages renseignent sur l'état actuel d'avancement du traitement (par exemple transmission des données démarrée ou OK) Ces messages décrivent les «écarts par rapport au «cas normal» prévu. Il ne s'agit pas d'erreurs, mais ces écarts pourraient générer des erreurs et doivent être éclaircis (par exemple pas de fichier dans le répertoire). Ces messages concernent des erreurs auxquelles il faut remédier pour poursuivre le traitement (par exemple modem éteint). Ces messages ne devraient jamais apparaître. Ils concernent /décrivent des erreurs rendant le traitement impossible (par exemple DLL manquante). Classification enum MsgClass { mcsystem = 0, mcasas = 1, mcmodule = 2, mccount = 3, }; Classification enum MsgOrigin { mopreader = 0, mopchecker = 1, mopanonymizer = 2, mopencrypter = 3, mopsender = 4, moigreceiver = 5, moigchecker = 6, mopdownloader = 7, mopwriter = 8, }; Remarque Message Class (Classe du message) Message en provenance du système d'exploitation (par exemple erreur d'écriture), <code> est repris du système d'exploitation Message en provenance de l'infrastructure ASAS (par exemple certificat non trouvé); (uniquement les modules mopencrypter, mopsender) Message provenant d'un module TrustX (par exemple lancement de l'anonymisation) Une fois par module aussitôt après le démarrage (nombre de fichiers dans le code) Remarque Message Origin (Origine du message) Message en provenance du module Reader de TrustX-Cabinet Message en provenance du module Checker de TrustX-Cabinet Message en provenance du module Anonymizer de TrustX-Cabinet Message en provenance du module Encrypter de TrustX-Cabinet Message en provenance du module Sender de TrustX-Cabinet Message en provenance du module Receiver de TrustX-InputGate Message en provenance du module Checker de TrustX-InputGate Message en provenance du module Downloader de TrustX-Cabinet Message en provenance du module de collecte 6.3.2 Interface pour la réception des événements Pour recevoir les messages d'événements de la part de TrustX-Cabinet, l'application doit implémenter une seule interface comme suit: Réception des événements // $Id: client.idl,v 1.3 2003/09/01 06:26:26 franco Exp $ #include "enums.idl" Remarque TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 30 de 37

module TrustxClient { interface TrustxEvents { oneway void trustxevent(in MsgLevel level, in MsgClass mclass, in MsgOrigin origin, in long code, }; }; in string filename, in string msg); Message Level (niveau du message) Message Class (Classe du message) Message Origin (Origine du message) Code, doit être interprété conjointement avec la classe du message. «Code d'erreur» au sens propre du terme Indique le fichier auquel se réfère le message, peut être vide si le message se rapporte au module dans son ensemble Description du code d'erreur avec texte Si level=mlerror et mclass=mcmodule, le fichier concerné est transféré dans le répertoire d'erreurs (problème dû au contenu du fichier). Pour toutes les autres combinaisons d'erreurs, le fichier reste dans le répertoire de travail (l'erreur n'est pas due au fichier). Après avoir remédié à l'origine de l'erreur, le traitement peut être redémarré sans qu'il y ait besoin d'établir à nouveau la facture. Exemple: modem éteint. Le message d'erreur correspondant est indiqué par MessageClass=mcASAS. 6.3.3 Messages (Code) Les codes sont différents pour chaque classe de message: mcsystem: le code contient le code d'erreur du système d'exploitation mcasas: le code d'erreur est toujours -1, car ASAS ne connaît pas de code d'erreur. Le message d'erreur réel est écrit dans le string msg mccount: contient dans le code le nombre de fichiers à traiter mcmodule: les codes suivants sont valables: Classification enum Msgs { INFO_MODULE_START = 0, INFO_MODULE_DONE = 1, INFO_MOVED = 2, WARN_NOT_MOVED = 3, WARN_NO_FILES = 4, WARN_MODULE_USERBREAK = 5, ERR_CONF_INPUTDIR = 6, ERR_CONF_WORKDIR = 7, ERR_CONF_ASASLOGIN = 8, ERR_CONF_TRUSTCENTER = 9, ERR_UNKNOWN_FILE_FORMAT = 10, ERR_MISSING_DATA = 11, ERR_DUPLICATE_INVOICE = 12, ERR_PDF_MISSING = 13, ERR_PDF_UNREF = 14, Remarque Messages (Code) Décrit le lancement d'un module Décrit la fin du module Fichier traité avec succès et transféré dans le répertoire suivant Fichier traité avec succès, mais n'a pas pu être transféré dans le répertoire Aucun fichier trouvé dans le «répertoire d'entrée» du module Module interrompu par l'utilisateur, le code 1 suit en complément Configuration: répertoire des factures non trouvé Configuration: répertoire de base non trouvé Configuration: login ASAS non trouvé Configuration: TrustCenter non trouvé Format de fichier inconnu (Checker de TrustX-Cabinet et Inputgate) Format connu, mais données manquantes ou non conformes Facture en double (Checker) Seulement quand option PDF=oui, PDF manquant Seulement quand option PDF=oui, PDF en trop TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 31 de 37

Classification ERR_ANONENC_FAILED = 15, ERR_CONNECTION_FAILED = 16, ERR_SEND_FAILED = 17 FATAL_ASAS_NOT_FOUND = 18, FATAL_MODULE_LOAD_FAILED = 19, ERR_SCHEMA = 20, ERR_ZSR_EAN = 21, ERR_ENC_SEND_TC_MISSMATCH = 22, ERR_CONF_OUTPUTDIR = 23, }; Remarque Erreur durant l'anonymisation ou le cryptage Erreur de connexion Internet Échec de l envoi Pas d'accès au Client ASAS Le module de TrustX n'a pas pu être chargé La facture XML n'est pas conforme au schéma Le numéro RCC n'est pas valide (Invoice rejected, no ZSR/EAN found) La facture a déjà été cryptée pour un autre TrustCenter Configuration: répertoire des réponses non trouvé 6.4 Intégrer TrustX Tous les modules («processus») (Auto, Read, etc.) sont traités de manière asynchrone. Cela signifie que le programme appelant reçoit immédiatement un événement avec le code «INFO_MODULE_START» du module correspondant, ce qui indique le lancement du module. Le déroulement formel est toujours le suivant: 1. événement qui confirme le lancement du module (Code = INFO_MODULE_START). 2. un seul événement de la classe Count suit ensuite. le code contient le nombre de fichiers à traiter. 3. pour chaque fichier, il y a un événement avec le code INFO_MOVED ou un ou plusieurs événements avec un avertissement ou un message d'erreur. 4. le module se termine toujours avec l'événement dont le code est INFO_MODULE_DONE. La progression du traitement des fichiers peut être suivie via les messages de TrustX-Event. Il faut absolument noter que le concept d'«événements» de Windows n'autorise pas l'envoi de commandes à l'écran (par exemple des barres de progression) directement à partir des événements (voir exemple page 28). Si un module est interrompu par l'utilisateur, le fichier en cours de traitement est traité jusqu'au bout. Le module s arrête ensuite. 6.5 Nom des fichiers Les fichiers de facture peuvent porter des noms quelconques. 6.6 Structure des répertoires Un répertoire de base {rb} peut être défini pour TrustX-Cabinet. Les répertoires suivants y sont créés pour les besoins internes de TrustX:..\{rb}\input..\{rb}\responses..\{rb}\valid Dans l'étape <Lire>, les fichiers de facture à traiter sont déplacés d'un répertoire quelconque dans ce répertoire. Le processus de traitement proprement dit de TrustX-Cabinet débute dans ce répertoire. La méthode check() lit depuis ce répertoire. Les réponses aux factures reçues par TrustX arrivent dans ce répertoire. La méthode write() lit les données depuis ce répertoire et les stocke dans le répertoire des réponses aux factures qui été défini. Tous les fichiers traités avec succès par Check() arrivent dans ce répertoire. La TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 32 de 37

méthode Anonymize() lit les données dans ce répertoire...\{rb}\output..\{rb}\archive..\{rb}\responsesarchive..\{rb}\logs..\{rb}\err Tous les fichiers traités avec succès par Anonymize() arrivent dans ce répertoire. La méthode Send() lit les données depuis ce répertoire. Toutes les factures envoyées avec succès à l'inputgate sont enregistrées dans ce répertoire, à condition que l'option Archiver ait été sélectionnée dans l'onglet <Configuration>. Toutes les réponses aux factures reçues sont enregistrées dans ce répertoire, à condition que l'option Archiver ait été sélectionnée dans l'onglet <Configuration>. Contient les fichiers journaux. Tous les fichiers traités par Check() ou Anonymize() et contenant une erreur arrivent dans ce répertoire de sorte que le fichier concerné ne peut pas être traité et doit être recréé. Il faut distinguer le répertoire de base de celui des factures et des réponses. Il est possible de définir ces derniers indépendamment du répertoire de base. TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 33 de 37

6.7 Fichiers importants de TrustX-Cabinet 6.7.1 Fichiers programme trustxui.exe mscvcp71.dll mscvcr71.dll trustx.dll Application TrustX-Cabinet / fichier exe (Windows) fichiers dll de TrustX-Cabinet TrustX-Cabinet Application TrustX-Cabinet / fichier exécutable UNIX (Mac) 6.7.2 Fichiers de configuration et fichiers journaux TrustX-Cabinet crée différents fichiers afin d'y enregistrer les configurations et les données des journaux. Nom du fichier Contenu Par Mandant Chemin d'accès trustx.log Informations de la facture nécessaires à la détection des doublons Oui À la racine du répertoire de base défini en général. Windows: C:\Documents and Settings\MON-PROFIL\Mes documents\trustx-cabinet\ Mac: /Users/MY_USER/Documents/TrustX-Cabinet YYYY-MM-DD.log Informations détaillées du journal pour chaque étape du traitement Oui Dans le répertoire «logs» sous le répertoire de base défini, par ex.: Windows: C:\Documents and Settings\MON-PROFIL\Mes documents\trustx-cabinet\logs Mac: /Users/MY_USER/Documents/TrustX-Cabinet/logs trustx.ini ch.trustx.praxis.fmw k.plist Paramètres de configuration Oui Windows: C:\Documents and Settings\MON- PROFIL\Application Data\Arpage\TrustX-Cabinet Mac: /Users/MY_USER/Library/Preferences/ch.trustx. praxis.fmwk.plist trustx.xml Informations sur le TrustCenter Répertoire créér au moment d installation Non Windows: C:\Programme\Arpage\TrustX Praxis Mac: /Applications/trustx- Praxis.app/Contents/SharedFrameworks/trustx.f rameworks/versions/a/resources/trustx.xml trustx.xml Informations sur le TrustCenter Oui Windows: C:\Dokumente und Einstellungen\MEIN- PROFIL\Anwendungsdaten\Arpage\trustx-Praxis Répertoire créér au moment de la transmission à l'inputgate Mac: /Users/MY_USER/Library/Application Support/trustx-Praxis/trustx.xml TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 34 de 37

7 Annexes Annexe 1: la ligne BVR en tant qu'identificateur de document (Token) Une ligne BVR dérivée de la ligne BVR de la facture (procédure esr9 avec nº de référence BVR à 27 chiffres et montant) est utilisée en tant qu'identificateur de document (Token). À la place du type de justificatif (les deux premiers caractères (A)), c'est le TrustCenter qui est codé. Le chiffre de contrôle (C) doit également être adapté. Le Token est imprimé sur le justificatif de remboursement. Le Token sert de nom de fichier pour l'image électronique de la facture (remplacer les caractères de commande par «_» et supprimer les espaces vides). 7.1.1 Spécification de la ligne BVR en tant qu'identificateur de document (Token) La ligne BVR utilisée en tant qu'identificateur de document correspond aux directives de SWIFT pour BVR (police OCR-B, position, etc.). Cela signifie en particulier que: l'identificateur de document (ou Token) doit toujours être unique. Les factures corrigées doivent avoir un numéro BVR différent de la première facture. Ceci est possible grâce à des numéros de facture uniques comme l'exige également la norme XML. Sur le justificatif de remboursement du patient envoyé à l'assurance pour le remboursement, l'identificateur de document doit être imprimé au même endroit que sur le bulletin de versement. Ceci permet à l'assureur de lire l'identificateur de document à l'aide d'un lecteur classique. Veuillez respecter les règles de la Poste en ce qui concerne la position. 50 0000157050 6 > 332435 00000111112222233333 1 + 010033018 > A B C D E F G H I J A = TrustCenter 2 caractères B = Montant en centimes, justifié à droite, complété par des zéros 10 caractères C = Chiffre de contrôle des champs A et B (modulo 10 récursif) 1 caractère D = Caractère de commande 1 caractère E+F = Numéro de référence à 26 caractères (données de charge) (unique!!!) 26 caractères G = Chiffre de contrôle des champs E et F 1 caractère H = Caractère de commande et espace vide 2 caractères I = Numéro de client BVR 9 caractères J = Caractère de commande 1 caractère TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 35 de 37

7.1.2 Codage du TrustCenter préfixe du Token Le Token imprimé sur le justificatif de remboursement est codé à l'aide d'un préfixe. Ci-dessous la liste de tous les TrustCenters. TrustCenter Préfixe du Token Ctésias 51 GallOnet 52 hawatrust 53 medkey 54 PonteNova 55 syndata 56 TC Aargau 57 thurcare 58 TC Ticino 59 TC züridoc 60 trustmed 61 GTS 7 62 Physiotrust 63 TC Test 69 7 General Transport Service TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 36 de 37

Annexe 2: exemple d'événement TrustX (VB6) Le statut INFO_MODULE_DONE est toujours le dernier message dans le déroulement des événements. Ce message relatif au statut apparaît aussi en cas d'erreur. Const INFO_MODULE_START = 0 Const INFO_MODULE_DONE = 1 Const INFO_MOVED = 2 Const WARN_NOT_MOVED = 3 Const WARN_NO_FILES = 4 Const WARN_MODULE_USERBREAK = 5 Private Sub trustx_trustxevent(byval level As trustx.tagmsglevel, _ ByVal mclass As trustx.tagmsgclass, _ ByVal origin As trustx.tagmsgorigin, _ ByVal code As Long, _ ByVal filename As String, ByVal msg As String) log.additem (msg) log.listindex = log.newindex If mclass = mcmodule Then If code = INFO_MODULE_START Then running = True curmod = origin If origin = mopreader Then action.text = "Einlesen" ElseIf origin = mopchecker Then action.text = "Überprüfen" ElseIf origin = mopanonymizer Then action.text = "Anonymisieren" ElseIf origin = mopsender Then action.text = "Senden" End If ElseIf code = INFO_MODULE_DONE Then If waitfor = origin Then running = False action.text = "Fertig" End If ElseIf (code <> WARN_NO_FILES) And _ (origin = mopreader Or origin = mopchecker Or _ origin = mopanonymizer Or origin = mopsender) Then curtot = curtot + 1 counter.text = curtot & "/" & curmax End If End If If mclass = mccount Then curtot = 0 curmax = code counter.text = curtot & "/" & curmax End If End Sub TrustX Cabinet Version 3.0 - Description des interfaces pour les éditeurs de logiciels Page 37 de 37