SIMPHONIE-ROC Guide implémentation Editeurs SIH 170301 v1.0 · 7.4.9 les exigences relatives au service clc 95 7.5 processus del 95 /-

PROJET ROC - Remboursements des Organismes Complémentaires GUIDE D’IMPLEMENTATION A DESTINATION DES EDITEURS HOSPITALIERS

Avant-propos 1/103

PROJET ROC REMBOURSEMENT DES ORGANISMES COMPLEMENTAIRES

GUIDE D’IMPLÉMENTATION À DESTINATION DES ÉDITEURS HOSPITALIERS

Version 1.0.0 – Mars 2017


Avant-propos 2/103

1 AVANT-PROPOS 8

1.1 RAPPELS GENERAUX SUR LE PROJET ROC 8 1.1.1 CONTEXTE DU PROJET 8 1.1.2 OBJECTIFS DU PROJET ROC 9 1.1.3 PRINCIPES DE FONCTIONNEMENT – SERVICES CIBLES 9 1.2 PRESENTATION DU GUIDE D’IMPLEMENTATION 11 1.2.1 OBJECTIF DU GUIDE D’IMPLEMENTATION 11 1.2.2 ARTICULATION DU GUIDE D’IMPLEMENTATION 12 1.3 REFERENCES DOCUMENTAIRES 13

2 PRESENTATION DES OUTILS 16

2.1 BPM (BUSINESS PROCESS MODEL) 16 2.2 DIAGRAMME DE CLASSE (UML) 16

3 MODELE DE DONNEES 17

3.1 LES REFERENTIELS 19 3.1.1 REFENTITEJURIDIQUE 19 3.1.2 REFENTITEGEOGRAPHIQUE 19 3.1.3 REFDEBITEUR 19 3.1.4 REFERREURAMC 19 3.1.5 REFGROUPEERREUR 19 3.1.6 REFRESEAUCONV 19 3.2 LES CLASSES METIERS 19 3.2.1 PATIENTBENEFICIAIRE 19 3.2.2 DOSSIERADMINISTRATIF 19 3.2.3 MOUVEMENT 20 3.2.4 VENUE 20 3.2.5 EPISODE 20 3.2.6 PERIODE 20 3.2.7 ASSUREAMO 21 3.2.8 ATTESTATION 21 3.2.9 COUVERTURE 21 3.2.10 CONTACT 22 3.2.11 DEVIS 22 3.2.12 FACTURE 22 3.2.13 LIGNE 23 3.2.14 PRESTATION 23 3.2.15 CONSIGNE 23 3.2.16 ACTE 23 3.2.17 IDB 23 3.2.18 SIM 23 3.2.19 CLC 23 3.2.20 MESSAGE 24

4 PROCESSUS SOUS-JACENT – CAPTURE DES DONNEES AMC ET EVOLUTION DES STATUTS AMC/RAC 25

4.1 COLLECTE DES DONNEES AMC 27 4.1.1 RECUEIL AMC PAR DATAMATRIX 27 4.1.2 REUTILISATION DES DONNEES 28 4.2 EVOLUTION DU STATUT_AMC ET DU STATUT_RAC. 28 4.3 SUIVI OPERATIONNEL DU STATUT_AMC ET DU STATUT_RAC 29 4.3.1 INFORMATIONS AMC SUR LA VENUE 29


Avant-propos 3/103

4.3.2 LISTES DE TRAVAIL 30 4.3.3 INFORMATIONS DU PATIENT 32

5 PROCESSUS METIER ACE 33

5.1 EN PREADMISSION ACE 33 5.1.1 LA CREATION D’UNE VENUE PREVISIONNELLE 35 5.1.2 LE COMPLEMENT VENUE ET LA COLLECTE DES DONNEES AMO/AMC 35 5.1.3 GESTION DE L’INDICATEUR STATUT_AMC. 36 5.1.4 LE SUIVI OPERATIONNEL DU STATUT_AMC : L’INFORMATION DU PATIENT SUR LA NON

COMPLETUDE DE SA VENUE 36 5.1.5 L’APPEL AU PROCESSUS ANNUAIRE SERVICE IDB 37 5.1.6 GESTION DE L’INDICATEUR STATUT_RAC 38 5.1.7 SUIVI OPERATIONNEL DU STATUT_RAC. 38 5.2 EN ADMISSION ACE 39 5.2.1 L’IDENTIFICATION DU PATIENT 41 5.2.2 CREATION / VALIDATION DE L’IDENTITE 41 5.2.3 L’IDENTIFICATION DE LA VENUE CONCERNEE 41 5.2.4 LA CREATION DE LA VENUE 42 5.2.5 LA REALISATION DU MOUVEMENT D’ENTREE 42 5.2.6 LE COMPLEMENT VENUE ET LA COLLECTE DES DONNEES AMO/AMC 42 5.2.7 LA GESTION DE L’INDICATEUR STATUT_AMC. 43 5.2.8 LE SUIVI OPERATIONNEL DU STATUT_AMC : L’INFORMATION AU PATIENT SUR LA NON

COMPLETUDE DE LA VENUE 43 5.2.9 L’APPEL AU PROCESSUS ANNUAIRE SERVICE IDB 43 5.2.10 GESTION DE L’INDICATEUR STATUT_RAC 44 5.2.11 LE SUIVI OPERATIONNEL DU STATUT_RAC 44 5.3 EN FACTURATION ACE 45 5.3.1 LA VALIDATION DE LA FACTURE-TIERS AMO 47 5.3.2 L’EMISSION DE LA FACTURE-TIERS AMO 47 5.3.3 LA RECEPTION DU RETOUR AMO. 47 5.3.4 LE RETRAITEMENT DE LA VENUE 47 5.3.5 L’ANALYSE DES COUVERTURES DE LA VENUE 47 5.3.6 LE PROCESSUS DE CALCUL 48 5.3.7 LA GESTION DE L’INDICATEUR STATUT_RAC 48 5.3.8 LA VALIDATION DE LA FACTURE-TIERS PATIENT 49 5.3.9 L’EMISSION DE LA FACTURE-TIERS PATIENT 49 5.3.10 LA DEMANDE D’ENCAISSEMENT DE LA FACTURE-TIERS PATIENT 49 5.3.11 LA VALIDATION DE LA FACTURE-TIERS AMC (DRE-ES) 49 5.3.12 L’EMISSION DE LA FACTURE-TIERS AMC (DRE-ES) 49 5.3.13 LA RECEPTION DU RETOUR AMC. 50 5.3.14 LE RETRAITEMENT DE LA VENUE 50

6 PROCESSUS METIER SEJOURS 51

6.1 EN PREADMISSION SEJOURS 51 6.1.1 LA CREATION D’UNE VENUE PREVISIONNELLE 54 6.1.2 LE COMPLEMENT VENUE ET LA COLLECTE DES DONNEES AMO/AMC 54 6.1.3 GESTION DE L’INDICATEUR STATUT_AMC. 54 6.1.4 LA DEMANDE DE PRISE EN CHARGE 54 6.1.5 LE SUIVI OPERATIONNEL DU STATUT_AMC. 54 6.1.6 L’APPEL AU PROCESSUS ANNUAIRE SERVICE IDB 54 6.1.7 APPEL PROCESSUS ANNUAIRE SERVICE SIM 55 6.1.8 GESTION DE L’INDICATEUR STATUT_RAC 55 6.1.9 SUIVI OPERATIONNEL DU STATUT_RAC 56 6.1.10 RECUEIL DU CONSENTEMENT DU PATIENT 56


Avant-propos 4/103

6.2 EN ADMISSION SEJOURS 56 6.2.1 L’IDENTIFICATION DU PATIENT 59 6.2.2 CREATION / VALIDATION DE L’IDENTITE 59 6.2.3 L’IDENTIFICATION DE LA VENUE CONCERNEE 59 6.2.4 LA CREATION DE LA VENUE 59 6.2.5 LA REALISATION DU MOUVEMENT D’ENTREE 59 6.2.6 LE COMPLEMENT VENUE ET LA COLLECTE DES DONNEES AMO/AMC 59 6.2.7 LA GESTION DE L’INDICATEUR STATUT_AMC. 59 6.2.8 LA DEMANDE DE PRISE EN CHARGE 59 6.2.9 LE SUIVI OPERATIONNEL DU STATUT AMC : L’INFORMATION AU PATIENT SUR LA NON

COMPLETUDE DE LA VENUE 59 6.2.10 L’APPEL AU PROCESSUS ANNUAIRE SERVICE IDB 59 6.2.11 L’APPEL AU PROCESSUS ANNUAIRE SERVICE SIM 59 6.2.12 LA GESTION DE L’INDICATEUR STATUT_RAC 59 6.2.13 LE SUIVI OPERATIONNEL DU STATUT RAC 59 6.2.14 LE RECUEIL DU CONSENTEMENT DU PATIENT 60 6.3 LORS DE LA VENUE 60 6.3.1 SAISIE DES PRESTATIONS HORS SOINS 62 6.3.2 MUTATION (AVEC CHANGEMENT DE TJP) 62 6.3.3 MISE A JOUR DU DOSSIER ADMINISTRATIF – CHANGEMENT D’EXONERATION DU TICKET

MODERATEUR 62 6.3.4 SAISIE DE LA NOUVELLE DATE PREVISIONNELLE DE SORTIE 63 6.3.5 APPEL PROCESSUS ANNUAIRE SERVICE SIM 63 6.3.6 GESTION DE L’INDICATEUR STATUT_RAC 63 6.3.7 SUIVI OPERATIONNEL DU STATUT_RAC : DOCUMENT D’INFORMATION AU PATIENT 63 6.3.8 MISE A JOUR DE LA VENUE / STOCKAGE SIM 64 6.4 LORS DE LA VENUE – CAS PARTICULIER D’UNE MODIFICATION DE L’AMC EN COURS DE

SEJOUR 64 6.4.1 COMPLEMENT DU DOSSIER ADMINISTRATIF 66 6.4.2 APPEL PROCESSUS ANNUAIRE SERVICE IDB 66 6.4.3 APPEL AU PROCESSUS ANNUAIRE SERVICE SIM 66 6.4.4 GESTION DE L’INDICATEUR STATUT_RAC 66 6.4.5 LE SUIVI OPERATIONNEL DE LA VENUE : INFORMATION DU PATIENT 67 6.5 EN FACTURATION SEJOURS 67 6.5.1 COLLECTE DES DONNEES DE FACTURATION. 69 6.5.2 ANALYSE DE CHAQUE COUVERTURE 69 6.5.3 APPEL ANNUAIRE SERVICE SIM 69 6.5.4 GESTION DE L’INDICATEUR STATUT_RAC 69 6.5.5 SUIVI OPERATIONNEL DU STATUT_RAC : INFORMATION PATIENT 70 6.5.6 APPEL DU SERVICE ANNUAIRE CLC 70 6.5.7 GESTION DE L’INDICATEUR STATUT_RAC 70 6.5.8 VALIDATION DE LA FACTURE-TIERS PATIENT 70 6.5.9 EMISSION DE LA FACTURE-TIERS PATIENT 70 6.5.10 DEMANDE D’ENCAISSEMENT AU PATIENT 70 6.5.11 VALIDATION DE LA FACTURE-TIERS AMC 71 6.5.12 EMISSION DE LA FACTURE-TIERS AMC (DRE-ES) 71 6.5.13 RECEPTION DES RETOURS AMC 71 6.5.14 RETRAITEMENT DE LA VENUE 71

7 PROCESSUS COMMUNS 72

7.1 APPEL PROCESSUS ANNUAIRE (SERVICE ANNUAIRE AMC ET CACHE DES ADRESSES) 72 7.1.1 RECHERCHE DE L’ADRESSE DU SERVICE AMC DANS LE CACHE 74 7.1.2 APPEL DU PROCESSUS ANNUAIRE AMC 74 7.1.3 APPEL DU SERVICE AMC (IDB/SIM/CLC) 75 7.1.4 STOCKAGE DE L’ADRESSE DU SERVICE AMC DANS LE CACHE. 75


Avant-propos 5/103

7.1.5 GESTION DES ERREURS ANNUAIRE (FONCTIONNELLES ET TECHNIQUES) 76 7.1.6 EXIGENCES RELATIVES AU SERVICE ANNUAIRE 76 7.2 PROCESSUS IDB 76 7.2.1 L’APPEL DU SERVICE IDB 78 7.2.2 LA MISE A JOUR DE L’INDICATEUR STATUT_RAC A PAS_RAC 78 7.2.3 LA CONSERVATION DE L’INDICATEUR STATUT_RAC A RAC 79 7.2.4 LA CONSERVATION DE L’INDICATEUR STATUT_RAC A RAC 79 7.2.5 LE STOCKAGE DES DONNEES IDB 79 7.2.6 L’ALIMENTATION DE LA LISTE ERREURS FONCTIONNELLES 79 7.2.7 L’ALIMENTATION DE LA LISTE ERREURS TECHNIQUES 80 7.2.8 L’ALIMENTATION DE LA LISTE INFORMATIONS PATIENTS 81 7.2.9 LES EXIGENCES RELATIVES AU SERVICE IDB 81 7.2.10 LES DONNEES EN ENTREE NECESSAIRES A L’APPEL DU SERVICE IDB 81 7.3 PROCESSUS SIM 84 7.3.1 APPEL AU SERVICE SIM 86 7.3.2 LA MISE A JOUR DE L’INDICATEUR STATUT_RAC A PAS_RAC 86 7.3.3 LA CONSERVATION DE L’INDICATEUR STATUT_RAC A RAC 87 7.3.4 LA CONSERVATION DE L’INDICATEUR STATUT_RAC A RAC 87 7.3.5 LE STOCKAGE DES DONNEES SIM 87 7.3.6 L’ALIMENTATION DE LA LISTE ERREURS FONCTIONNELLES 87 7.3.7 L’ALIMENTATION DE LA LISTE ERREURS TECHNIQUES 88 7.3.8 L’ALIMENTATION DE LA LISTE INFORMATIONS PATIENTS 89 7.3.9 LES EXIGENCES RELATIVES AU SERVICE SIM 89 7.4 PROCESSUS CLC 90 7.4.1 APPEL DU SERVICE CLC 92 7.4.2 LA MISE A JOUR DE L’INDICATEUR STATUT_RAC A PAS_RAC 92 7.4.3 LA CONSERVATION DE L’INDICATEUR STATUT_RAC A RAC 92 7.4.4 LA CONSERVATION DE L’INDICATEUR STATUT_RAC A RAC 92 7.4.5 LE STOCKAGE DES DONNEES CLC 93 7.4.6 L’ALIMENTATION DE LA LISTE ERREURS FONCTIONNELLES 93 7.4.7 L’ALIMENTATION DE LA LISTE ERREURS TECHNIQUES 94 7.4.8 L’ALIMENTATION DE LA LISTE INFORMATIONS PATIENTS 95 7.4.9 LES EXIGENCES RELATIVES AU SERVICE CLC 95 7.5 PROCESSUS DEL 95 7.5.1 LES EXIGENCES RELATIVES AU SERVICE DEL 95

8 FONCTIONNALITES TRANSVERSALES 96

8.1 ARCHIVAGE DES ECHANGES 96 8.2 ALERTES / INFORMATIONS CONTEXTUELLES 96 8.3 PRODUCTION DE FACTURES-TIERS NORMALISEES AVEC AMC HORS ROC 96 8.4 TRAITEMENTS BATCH 97 8.4.1 REALISATION DU TRAITEMENT AUTOMATIQUE 99 8.4.2 GENERATION DE LA LISTE DES VENUES EN COURS AVEC DATE DE FIN DE CONTRAT PROCHE

DURANT LE SEJOUR 99 8.4.3 GENERATION DE LA LISTE DES VENUES EN COURS DONT LA DATE D’ECHEANCE DE

RENOUVELLEMENT EST LA DATE DU JOUR 99 8.4.4 INCREMENTATION DE L’OCCURRENCE 99 8.4.5 APPEL DU PROCESSUS ANNUAIRE SERVICE IDB 100 8.4.6 MISE A JOUR DES INFORMATIONS IDB 100 8.4.7 APPEL DU PROCESSUS ANNUAIRE SERVICE SIM 100 8.4.8 GENERATION DE LA LISTE DES VENUES EN COURS A LA DATE DE CLOTURE D’EXERCICE

COMPTABLE 100 8.4.9 INCREMENTATION DE L’OCCURRENCE 100 8.4.10 APPEL DU PROCESSUS ANNUAIRE SERVICE CLC. 101 8.4.11 GENERATION DE LA LISTE DES VENUES PREVISIONNELLES DU JOUR. 101


Avant-propos 6/103

8.4.12 APPEL DU PROCESSUS ANNUAIRE SERVICE IDB 101 8.4.13 GENERATION DE LA LISTE DES VENUES PREVISIONNELLES A J-N 101 8.4.14 APPEL DU PROCESSUS ANNUAIRE SERVICE IDB 102 8.4.15 GENERATION DE LA LISTE DES VENUES AUX URGENCES POUR LESQUELLES LE PATIENT

EST ENTRE LA VEILLE ET EST TOUJOURS PRESENT A MINUIT. 102 8.4.16 INCREMENTATION DE L’OCCURRENCE 102 8.4.17 APPEL DU PROCESSUS ANNUAIRE SERVICE IDB 102


Avant-propos 7/103

Figure 1: Présentation synthétique des échanges ROC (établissements PNL) ........ 10 Figure 2: Présentation synthétique des échanges ROC (établissements publics) .... 11

Figure 3: Documentation du projet ROC................................................................... 14 Figure 4: Exemple de diagramme de classe ............................................................. 16

Figure 5: Modèle de classes UML ............................................................................ 18 Figure 6: Capture des données AMC, évolution des statuts AMC/RAC et suivi

opérationnel de la venue ................................................................................... 26 Figure 7: Exemple de recueil des données AMC par datamatrix .............................. 27 Figure 8: Exemple d'écran permettant de visualiser les données AMC d’une venue 29

Figure 9: Liste des couvertures avec RAC ............................................................... 31 Figure 10: Traitement des retours AMC.................................................................... 32 Figure 11: Préadmission dans le contexte ACE ....................................................... 34 Figure 12: Admission dans le contexte ACE ............................................................. 40 Figure 13: Facturation dans le contexte ACE ........................................................... 46

Figure 14: Préadmission dans le contexte Séjours ................................................... 53 Figure 15: Admission dans le contexte Séjours ........................................................ 58

Figure 16: Evénement en cours de séjours dans le contexte Séjours ...................... 61 Figure 17: Modification de l’AMC en cours de séjour dans le contexte Séjours ....... 65 Figure 18: Facturation dans le contexte Séjours ...................................................... 68 Figure 19: Processus annuaire ................................................................................. 73

Figure 20: Processus annuaire service IDB .............................................................. 77 Figure 21: Processus annuaire service SIM ............................................................. 85

Figure 22: Processus annuaire service CLC ............................................................ 91 Figure 23: BPM Traitement Batch ............................................................................ 98

Historique du document

Version Date Commentaires

v1.0.0 Mars 2017 Première version publiée


Avant-propos 8/103

1 Avant-propos

1.1 Rappels généraux sur le projet ROC

1.1.1 Contexte du projet

Dans le cadre de la mise en œuvre du plan triennal et dans un contexte global de recherche d’efficience, la sécurisation du recouvrement des recettes constitue un élément clé de l’amélioration de la situation financière des hôpitaux. D’autre part, le parcours du patient à l’hôpital et en particulier son circuit administratif présente encore des marges d’optimisation, d’automatisation et de simplification.

En réponse à ces enjeux, le programme SIMPHONIE (SIMplification du Parcours administratif HOspitalier du patient et Numérisation des Informations Echangées) a été conçu. Porté par la DGOS, avec l’appui du SGMAP, de la DSS, de la DGFiP et de l’ANAP, SIMPHONIE vise :

à fortement simplifier le parcours administratif hospitalier du patient, depuis l’accueil du patient jusqu’à la facturation et le recouvrement, grâce à une simplification des organisations et des processus ;

à dématérialiser tous les échanges (flux de données, documents…) liés à ce parcours entre les différents acteurs : l’usager, l’établissement de santé, le comptable public hospitalier, l’assurance maladie obligatoire (AMO) et l’assurance maladie complémentaire (AMC) ;

du fait de la simplification, de la dématérialisation et de l’optimisation de la chaîne de facturation-recouvrement, à automatiser tous les processus qui peuvent l’être et à concentrer les moyens hospitaliers sur les actions à plus forte valeur ajoutée au service des usagers (informations sur le reste à charge du patient tout au long du parcours de soins…) ;

à sécuriser les recettes de l’établissement grâce à des processus de recouvrement plus efficients et à contribuer ainsi aux objectifs d’efficience des établissements ;

à améliorer la transparence du processus et l’information fournie aux patients : SIMPHONIE permettra aux établissements de santé de remettre aux patients, avant leur sortie de l’hôpital, un document indiquant le montant total facturé au titre de la prise en charge, en distinguant ce qui revient à l’assurance maladie obligatoire, la part prise en charge par une éventuelle complémentaire, et enfin le reste à charge patient, conformément à l’article 94 de la loi de modernisation de notre système de santé.

Le projet Remboursement des Organismes Complémentaires (ROC), dont le déploiement constitue un chantier du programme SIMPHONIE, vise la mise en place d’échanges dématérialisés entre les établissements de santé, les AMC, et la DGFiP, s’agissant des établissements publics de santé.

Il a pour objet de normaliser, d’optimiser et d’industrialiser l’ensemble de ces échanges par la mise en place d’une solution unique et opposable à l’ensemble des acteurs par le biais d’un accord cadre national.

Les travaux relatifs au projet ROC sont réalisés sous l’égide du ministère de la santé, de la Direction Générale des Finances Publiques (DGFiP), de l’Union nationale des organismes d'assurance maladie complémentaire (UNOCAM), de la Fédération


Avant-propos 9/103

Nationale de la Mutualité Française (FNMF), de la Fédération Française de l’Assurance (FFA) et du Centre Technique des Institutions de Prévoyance (CTIP).

1.1.2 Objectifs du projet ROC

Pour les établissements de santé, les objectifs du projet ROC sont :

Faciliter, grâce à de nouveaux web services, le recueil des informations relatives à la couverture AMC du patient.

Connaître en temps réel, grâce à ces nouveaux web services, la part prise en charge par l’AMC et ainsi pouvoir informer le patient de l’existence d’un éventuel reste à charge en amont ou lors sa venue et facturer ce reste à charge avant sa sortie.

Faciliter la facturation et le recouvrement de la part AMC, sur la base d’échanges dématérialisés.

Le projet ROC a ainsi vocation à simplifier l’application du Tiers-Payant dans les établissements de santé et donc favoriser l’accès aux soins pour les patients.

1.1.3 Principes de fonctionnement – services cibles

Le projet ROC se propose d’automatiser les échanges entre les Établissements de Santé (ETS) et les Organismes d’Assurances Maladie Complémentaires (AMC), en fonction du parcours administratif d’un patient, et ce depuis sa préadmission et son accueil jusqu’à sa sortie, pour donner aux trois acteurs (patient, établissements de santé et AMC) une vision cohérente et juste des conditions de prise en charge d’un éventuel reste à charge. Le dispositif d’échanges ROC fait appel à des services d’échanges établissements de santé / AMC.

Cinq web services (WS) : o Un service d’annuaire centralisé qui fournit les adresses des services

dématérialisés proposés par chaque AMC. o Des services synchrones développés par chaque AMC :

Un service d’identification des droits du bénéficiaire → IDB = « Information Droits Bénéficiaire » ;

Un service de simulation du niveau de prise en charge de la part AMC des prestations hospitalières restant à la charge du patient → SIM = « Simulation part AMC » ;

Un service de calcul de la part complémentaire prise en charge par l’AMC avec engagement de paiement → CLC = « Calcul » avec engagement de paiement ;

Un service d’annulation de calcul de la part complémentaire prise en charge par l’AMC → DEL = « Annulation CLC ».

Un service de facturation asynchrone o Facturation dématérialisée de la part AMC (Norme DRE-ES,

acheminement via les frontaux SESAM-Vitale) ; o Recouvrement dématérialisé de la part AMC (Norme Retour Noémie).

Les deux schémas ci-dessous illustrent les échanges ROC, dans le cas des établissements PNL d’une part et dans le cas des établissements publics d’autre part.


Avant-propos 10/103

Figure 1: Présentation synthétique des échanges ROC (établissements PNL)


Avant-propos 11/103

Figure 2: Présentation synthétique des échanges ROC (établissements publics)

1.2 Présentation du guide d’implémentation

1.2.1 Objectif du guide d’implémentation Ce document s’adresse aux éditeurs de logiciel de Gestion Administrative du Malade (GAM) ou du Patient (GAP) et a pour objet de définir les modalités d’implémentation dans ces logiciels des web services ROC et les fonctions attendues en lien avec ces nouveaux services. L’élaboration d’un tel document, en complément des documents relatifs à l’offre de service des AMC, est apparue nécessaire car il s’agit de nouveaux services qui doivent être intégrés dans les SIH des établissements et qui permettent d’envisager de nouvelles organisations liées au processus de prise en charge des patients. Il s’agit donc de fournir aux éditeurs de GAP/GAM un premier niveau d’étude sur les possibilités offertes par ces nouveaux services et les évolutions des processus rendues possibles. L’élaboration du document s’appuie sur l’expertise de l’ASIP Santé acquise au travers de sa mission d’appui aux AMC à la conception de services en ligne pour les établissements de santé. Un groupe de travail constitué d’établissements de santé a permis de bénéficier de l’expérience d’établissements


Avant-propos 12/103

représentatifs de la diversité des problématiques rencontrées et de valider les fonctionnalités et les processus envisagés. Lors de leurs développements, les éditeurs devront exploiter, dans un premier temps, les informations et règles de gestion issues du cahier des charges de la norme HospiAMC qui régit le dispositif de manière conjointe pour les sphères AMC et établissements. Dans un second temps, ils pourront utiliser le présent guide d’implémentation comme document de référence d’encapsulation des web services au sein des processus de prise en charge médico-administrative des établissements de santé. Bien que ce guide d’implémentation présente un certain nombre d'axes d'évolution possibles des services rendus par les outils de GAM/GAP à l’appui des services en ligne proposés dans le cadre de ROC, il ne saurait être exhaustif sur toutes les fonctionnalités et innovations pouvant être proposées aux établissements de santé. Ce guide constitue donc un socle minimal de développements attendus avant mise à disposition des EPS et PNL.

1.2.2 Articulation du guide d’implémentation Le présent guide d’implémentation est articulé de la manière suivante :

o Le chapitre 2 présente les outils utilisés dans le guide pour faciliter la compréhension des processus ROC.

o Le chapitre 3 décrit le modèle conceptuel de données ROC qui s’appuie sur les concepts clés de « Venue », « Episode de facturation » et « Période de facturation » définis plus globalement dans le cadre du programme SIMPHONIE et partagés par les autres briques qui le composent (cahier des charges pilotage de la chaîne Accueil – Facturation - Recouvrement, spécifications techniques et fonctionnelles du dispositif d’encaissement automatique par débit carte).

o Le chapitre 4 présente un processus sous-jacent à l’ensemble des processus ROC : capture des données AMC, mise à jour des indicateurs et suivi opérationnel des venues.

o Le chapitre 5 présente la façon dont le processus métier ACE des établissements de santé peut être transformé en tenant compte des nouvelles fonctionnalités offertes par ROC.

o Le chapitre 6 présente la façon dont le processus métier Séjours des établissements de santé peut être transformé en tenant compte des nouvelles fonctionnalités offertes par ROC.

o Le chapitre 7 présente les processus inhérents à chaque web services ROC (Annuaire, IDB, SIM, CLC, DEL).

o Le chapitre 8 est une description des fonctionnalités transversales attendues dans le SIH de manière à respecter des exigences et la bonne gestion des services AMC.

Pour faciliter la lecture et l’appropriation du document, il est préconisé de lire la description des différents processus en conservant un accès au schéma BPM associé (impression, double écran).


Avant-propos 13/103

1.3 Références documentaires

Le tableau ci-dessous liste l’ensemble des documents qui peuvent être utiles dans le cadre du projet ROC.

Nom du document Contenu du document

Corpus documentaire constituant le cahier des charges ROC

ROC cible - Présentation des principes généraux relatifs aux échanges préparatoires à la facturation hospitalière vers les AMC

Présentation des principes généraux du projet ROC

Cahier des charges HOSPIAMC Cahier des charges décrivant les échanges et règles de gestion du dispositif ROC

Cadre d'interopérabilité technique des services AMC

Description des aspects techniques et sécuritaires à mettre en œuvre lors de l’interrogation des web services offerts par les assurances maladies complémentaires (AMC).

Cahier des charges « Facturation paiement et rejets »

Description des échanges relatifs à la facturation des AMC par les établissements de santé et des retours des AMC vers les établissements de santé et le cas échéant la DGFiP, qui sont à mettre en œuvre dans le cadre du dispositif ROC (dont définition de la norme DRE-ES et NOEMIE 578R / 908R)

Annuaire des services AMC - Guide d'utilisation du web service par les éditeurs

Guide d’utilisation du web service de l’annuaire AMC, guidant les éditeurs pour l’intégration de ce web service dans leurs solutions applicatives.

Documentation autre

Guide d’implémentation à destination des éditeurs de SIH pour l’intégration des services HospiAMC

Guide indiquant aux éditeurs les modalités d’implémentation des web services ROC et les fonctions attendues en lien avec ces nouveaux services.

CDC Harmonisation des attestations de tiers payant AMC

Cahier des charges décrivant les zones harmonisées des attestations de TP AMC

SFG – Lire le code Datamatrix AMC Spécifications pour la lecture du Datamatrix AMC

Codifications rejets Liste des codes rejets des services AMC

Fichiers techniques WSDL des services Web AMC


Avant-propos 14/103

Le présent document est une des composantes du cahier des charges ROC comme l'indique le schéma ci-dessous :

Figure 3: Documentation du projet ROC

Les ambitions, enjeux et principes du dispositif ROC sont décrits dans le document de principes généraux « Présentation des principes généraux relatifs aux échanges préparatoires à la facturation hospitalière vers les AMC » qui est le socle du cahier des charges. Ce document chapeau est complété par le cahier des charges de la norme HospiAMC. Ce document définit les règles de gestion pour l’usage de l’offre de services en ligne des AMC. Le cadre d’interopérabilité décrit, pour les AMC et les établissements de santé, les modalités techniques de la mise en œuvre de ces services en ligne. Le cahier des charges facturation paiement et rejets couvre les flux de facturation dématérialisés des établissements de santé vers les AMC (évolution de la norme DRE pour le dispositif ROC) et les flux de paiement et rejets (normes NOEMIE 578R/908R spécifiques au dispositif ROC) des AMC vers les établissements de santé et la DGFiP dans le cas des établissements publics de santé.


Avant-propos 15/103

La documentation de l’annuaire AMC et notamment le guide d’utilisation du web service par les éditeurs fournit les modalités de recueil des adresses de routage des services AMC pour les établissements de santé. La documentation de l’annuaire établissements de santé fournit aux AMC les modalités d’accès à l’annuaire notamment pour récupérer les coordonnées bancaires des établissements de santé à utiliser pour les paiements.


Présentation des outils 16/103

2 Présentation des outils

2.1 BPM (Business Process Model)

Un BPM (Gestion de Processus Métier) est un modèle qui décrit un enchainement d’actions métier pour la réalisation d’un processus. Le BPM permet de décrire précisément les actions et les conditions à réaliser dans le cadre d’un processus métier. Le BPM permet d’avoir une vue d’ensemble sur les processus métiers d’une organisation afin d’optimiser et d’automatiser autant que possible ces derniers. La réalisation d’un BPM facilite à l’éditeur la compréhension du fonctionnement attendu et des différentes tâches à mettre en œuvre dans le logiciel. Il permet également de retranscrire plus rapidement les actions en traitement.

2.2 Diagramme de classe (UML)

Le diagramme de classe permet de décrire les différents éléments qui interviennent dans le processus ROC et de modéliser les relations entre ces éléments. Les classes permettent de représenter les données (attributs) qui sont liées ensemble par un même champ sémantique.

Figure 4: Exemple de diagramme de classe

Le schéma ci-dessus présente un diagramme de classe. Il est composé de plusieurs éléments :

Package : C’est un regroupement de classe donnant un sens fonctionnel au schéma. (ex : le package facturation contient l’ensemble des classes en rapport avec la facturation) ;

Classe : C’est un ensemble d’attribut décrivant un concept (ex : Facture, Devis, Personne…) ;

Attribut : C’est une propriété de la classe. Par exemple, pour une classe facture, le numéro de facturation ;

Relation : Elle décrit la relation qui existe entre deux classes. Une relation a un rôle et des cardinalités. Elle se lit de la façon suivante : Pour une instance de Classe1, il y a 0 à n instance de Classe2. Pour une instance de Classe2, il y a une seule instance de Classe1. Par exemple : un patient (instance de classe Patient) peut avoir 0 à n dossier administratif (instance de classe DossierAdministratif). Un dossier administratif, quant à lui, ne concerne qu’un seul patient;

Méthode : Une méthode décrit les opérations que le système peut réaliser sur l’instance de la classe. Par exemple pour une facture, télétransmettre la facture.


Modèle de données 17/103

3 Modèle de données L’objectif de ce chapitre est de présenter un modèle de données afin de bien comprendre la relation entre les objets manipulés dans les processus ROC. Il permet également d’identifier comment aborder les concepts nécessaires au fonctionnement des échanges ROC en s’appuyant sur les concepts clés de « Venue », « Episode de facturation » et « Période de facturation » promus dans le cadre du programme SIMPHONIE (et en particulier, dans le cahier des charges du pilotage de la chaîne Accueil – Facturation - Recouvrement). Il n’a pas pour objectif d’être implémenté sous cette forme mais a vocation à accompagner l’éditeur dans sa réflexion sur les évolutions à apporter à son propre modèle conceptuel de données. Il présente également les données issues des messages AMC et réparties dans l’ensemble du modèle. Le modèle de données présenté fait référence à des classes existantes dans le SI et complète le modèle pour le processus de facturation des AMC. Certaines classes peuvent porter le même nom que celles déjà connues dans le contexte admission mais n’ont pas le même sens métier (ex : Venue). Les classes de type référentiel sont préfixées par Ref.



Figure 5: Modèle de classes UML



3.1 Les référentiels

3.1.1 RefEntiteJuridique Référentiel d’entité juridique auquel est rattaché l’entité géographique (établissement, FINESS géographique). La modélisation de ces entités est nécessaire car l’appel des services AMC nécessite de transmettre les FINESS des établissements dans les échanges.

3.1.2 RefEntiteGeographique Référentiel des établissements géographiques rattachés à une entité juridique. Une entité juridique peut avoir plusieurs entités géographiques. Une entité géographique est dans une seule entité juridique.

3.1.3 RefDebiteur Référentiel des organismes complémentaires. Il doit être alimenté par la liste des AMC du dispositif ROC. L’alimentation peut-être automatique à partir des données de l’attestation de tiers payant AMC et de l’appel au web service de l’annuaire.

3.1.4 RefErreurAMC Il s’agit du référentiel des erreurs des services et de l’annuaire AMC. Ce référentiel est alimenté par les codes erreurs des AMC ROC et peut être enrichi avec des explications sur le code erreur et le traitement à réaliser.

3.1.5 RefGroupeErreur Chaque erreur est classée dans un groupe

Information patient

Erreur fonctionnelle

Erreur technique Ces groupes permettront de classifier par la suite les retours des services AMC et de constituer les listes de travail (cf. chapitre 4.3.2).

3.1.6 RefReseauConv La classe RefReseauConv permet à l’établissement d’indiquer avec quel réseau il a contractualisé et permettra de sélectionner automatiquement le réseau correspondant.

3.2 Les classes métiers

Les classes métiers représentent les données manipulées et créées par le système dans les processus d’admission, de mouvement et de sortie des patients mais également impactant le fonctionnement de la facturation.

3.2.1 PatientBeneficiaire Le patient bénéficiaire est à la fois le patient dans la GAP/GAM et le bénéficiaire reconnu par l’AMC. Le bénéficiaire n’est pas toujours l’assuré. L’identification du patient est réalisée dans le système en s’appuyant sur les règles d’identito-vigilance.

3.2.2 DossierAdministratif Le dossier administratif représente un élément pivot dans le SIH. Il se trouve porteur de réalités autres que la facturation (une prise en charge médicale, une venue, une occurrence de dossier médical …).



3.2.3 Mouvement Le mouvement correspond à une période d’une venue dans une même unité de responsabilité médicale / hébergement d’une même entité juridique. Le mouvement sert à identifier les modifications sur une venue qui nécessitent un nouveau calcul SIM pendant un séjour ou à la sortie du patient pour le CLC. A noter qu’on évitera de réaliser un mouvement pour répondre à une demande d’information du patient sur la part prise en charge par sa complémentaire santé pour les prestations hors soins afin de ne pas déclencher des messages vers des applications tierces tant qu’il n’y a pas une validation du patient.

3.2.4 Venue

La notion de venue correspond à la totalité de la période de prise en charge du patient entre son admission dans l’établissement et sa sortie (vers un autre ES ou à domicile). Attention, la venue dans le contexte du programme SIMPHONIE n’a pas le même sens que dans le contexte admission décrit dans IHE PAM FR. La venue est avant tout un regroupement d’un ou plusieurs mouvements dans un ou plusieurs établissements géographiques (EG) d’une même entité juridique (EJ) : par exemple, une entrée en MCOO puis mutation en SSR constitue une seule venue La venue est composée d’un ou plusieurs épisodes de facturation (cf. définition ci-dessous). A noter : il n’y a pas de bijection entre le dossier administratif et la venue.

3.2.5 Episode

L’épisode de facturation désigne une séquence de soins facturée dans son ensemble selon une modalité de facturation et une seule. Il s’agit du découpage en sous-ensemble selon les modalités de facturation (MCOO, HAD, SSR, PSY) : - Un premier exemple est celui d’un patient qui bénéficie de soins MCOO, suivi de

soins en HAD lors d’une même venue. Il y aura deux épisodes de facturation correspondant aux modalités de facturations différentes en MCOO et HAD ;

- Un deuxième exemple est celui d’un patient hospitalisé en MCOO suivi de SSR, il y aura également deux épisodes successifs pour la même venue.

L’épisode de facturation est composé d’une ou plusieurs périodes de facturation (cf. définition ci-dessous).

3.2.6 Période

Une période de facturation correspond à un processus d’évaluation financière de tout ou partie d’un épisode de facturation. Elle correspond à une facture-tiers AMO et une seule. Il y a donc autant de périodes de facturation que de factures-tiers AMO différentes dans un épisode de facturation.



Par exemple dans le cadre d’une venue externe MCOO, il y aura deux périodes de facturation distinctes lorsque la venue couvre des prestations associées à des contextes de parcours de soins coordonnés différents.

Ainsi, la période de facturation est amenée à changer notamment dès lors que l’un de ces attributs est différent : - Les dates de début et de fin de la période de facturation ; - Le taux de prise en charge, qui est lui-même impacté par l’existence de motifs

d’exonération ou par le contexte de parcours de soins coordonné ; - La nature d’assurance ; - La date d’accident du travail ; - Le mode de traitement ; - …

3.2.7 AssureAMO La classe AssureAMO contient l’ensemble des informations issues des données AMO et qui seront ensuite utilisées dans les échanges AMC. A noter que les informations issues de cette classe doivent déjà exister dans le système.

3.2.8 Attestation La classe Attestation correspond aux informations recueillies sur l’attestation de tiers payant AMC de l’assuré. A noter que les informations recueillies sont associées à une provenance (saisie, dataMatrix) qui peut donner une information qualité sur les données. Le type de convention associé au domaine conventionnel EXTE (Soins externes hospitaliers) est reporté sur typeConvEXT et le type de convention associé au domaine conventionnel HOSP (Séjour hospitalier) est reporté sur typeConvHOSP. Dans le cas où l’AMC n’utilise qu’un seul type de convention pour l’ensemble des domaines, le type de convention est reporté sur typeConvEXT et typeConvHOSP (cf. CDC Harmonisation des Attestation AMC). L’attestation de tiers payant AMC peut être utilisée dans plusieurs venues et sur plusieurs couvertures. L’attestation de tiers payant AMC peut également être définie par défaut pour qu’elle soit sélectionnée automatiquement lors de la création d’une venue notamment lors de venues multiples. Dans le cas où l’établissement contractualise avec un réseau et que l’AMC fait partie de ce réseau, le domaine conventionnel HOSP ou EXT peut changer, la classe RefReseauConv permet à l’établissement d’indiquer qu’il contractualise avec un réseau. Dans ce cas précis, il peut y avoir plusieurs types de conventions sur l’attestation de tiers payant AMC du patient (cf. Harmonisation des attestations de tiers payant AMC). La sélection dépendra de la contractualisation de l’établissement avec le réseau.

3.2.9 Couverture La couverture constitue le lien entre la venue, l’épisode, la période de facturation et un organisme AMC. Il s’agit de la couverture AMC valable sur une venue pour une période de facturation auprès d’un AMC. L’absence de couverture est une instance



de couverture. Dès que les données AMC ont été collectées, l’objet couverture est complété. Les couvertures peuvent être multiples pour une période de facturation notamment lorsque l’AMC change en cours de séjour. Dans ce cas, l’occurrence de la période de facturation sera incrémentée. Une couverture peut donner lieu à la production de plusieurs factures-tiers (patient, AMC). Pour une couverture, il pourra y avoir également plusieurs prestations associées. Lors de la réponse du service IDB, le système vient compléter la couverture avec les informations sur l’absence ou non d’un RAC, les dates de couverture, d’engagement et d’échéance de renouvellement. Ces dates devront être suivies afin de relancer automatiquement le service IDB. Le contact AMC doit également être complété. L’attribut isActif est à 1. S’il s’agit de vérifier à la date d’échéance la couverture de l’assuré, l’appel IDB alimentera une nouvelle instance de couverture mais avec l’attribut isActif à 0. Cette instance servira uniquement dans le cadre de la traçabilité.

3.2.10 Contact La classe Contact représente le contact de l’AMC dans le cadre des échanges. Cela permet à l’établissement de contacter une personne en cas de problème sur une couverture. Ces données doivent être accessibles sur les IHM à l’utilisateur dans le cas d’un problème sur une couverture.

3.2.11 Devis La classe Devis est alimentée lorsque le système appelle le service SIM notamment pour fournir l’information au patient sur les montants pris en charge par sa complémentaire santé. Le devis est associé à une couverture. Un devis sera produit pour le patient sur une couverture. Il sera mis à jour à chaque appel SIM sur la couverture. La production d’un devis doit être découplée de l’admission car il doit être possible de fournir une information au patient sur les montants pris en charge par sa complémentaire santé sans pour autant générer de modifications sur la venue tant que le patient n’a pas donné son accord. Dans le cas où un patient aurait plusieurs AMC durant le séjour, plusieurs devis seront réalisés pour le séjour mais le document d’information standardisé remis au patient devra fournir une vision agrégée.

3.2.12 Facture La classe Facture est alimentée lorsque le système appelle le service CLC ou que le calcul est effectué en local. Plusieurs factures-tiers peuvent être établies pour une même couverture durant un séjour. Elle peut contenir les factures-tiers à destination des AMC et du patient. La facture-tiers peut avoir un statut pour gérer les étapes de production jusqu’à son envoi et son recouvrement (cf. cahier des charges pilotage de la chaîne Accueil – Facturation - Recouvrement »).



3.2.13 Ligne La classe ligne contient les informations sur une ligne de facture ou de devis (quantité, prix unitaire, code acte…). Elle est alimentée avec les prestations et actes qui peuvent être répartis sur plusieurs lignes de différentes factures-tiers (AMO, AMC, Patient). Les nomenclatures référencées dans le projet ROC (Annexe 10 B2, NGAP, Regroupement CCAM, …) doivent être utilisées pour décrire les prestations et actes codés dans la classe Ligne.

3.2.14 Prestation La prestation est présente dans tous les échanges. Sur un IDB, elle se définit par une date de début et de fin d’une période facturation. Sur un SIM ou un CLC, elle regroupe des actes exécutés dans un même service, rattachés à une même DMT lorsque cette notion existe (pour les séjours aujourd’hui). Elle est unique sur un échange de préadmission ou d’admission, elle correspond à la DMT d’admission et à la durée du séjour prévu. Elle peut être multiple en cours de séjour, lorsque le patient change de service.

3.2.15 Consigne La classe Consigne est utilisée en consultation externe. L’AMC indique lors de l’appel au service IDB si le calcul est local. Dans ce cas, les règles à appliquer pour le calcul sont spécifiées dans la classe Consigne.

3.2.16 Acte Il s’agit des actes au sens de la facturation DRE, ils sont matérialisés par un code acte. Les actes sont rattachés à une prestation, et les dates de début et de fin de l’acte doivent être incluses dans la période définie pour la prestation. Ils peuvent cependant en différer (par exemple lorsque le patient a bénéficié d’une chambre particulière pendant une partie de la période seulement). L’acte sera repris dans une ou plusieurs lignes de factures-tiers (AMC, AMO, Patient) ;

3.2.17 IDB La classe IDB contient les éléments essentiels issus du message retour IDB pour piloter les échanges avec l’AMC au travers des IHM définis dans le chapitre 4.3.2. La réponse du message IDB doit permettre d’alimenter les classes IDB, Couverture, Prestation, Contact. La classe IDB contient également les paramètres à utiliser pour les appels aux services AMC suivants (Elément NextService de la réponse IDB).

3.2.18 SIM La classe SIM contient les éléments essentiels issus du message retour SIM pour piloter les échanges avec l’AMC au travers des IHM définis dans le chapitre 4.3.2. La réponse du message SIM doit permettre de compléter les attributs des classes Devis, Ligne, Couverture, Prestation, Acte. Une instance de SIM pourra être remplacée par une autre, la relation entre les deux est matérialisée.

3.2.19 CLC La classe CLC contient les éléments essentiels issus du message retour CLC pour piloter les échanges avec l’AMC au travers des IHM définis dans le chapitre 4.3.2. La réponse du message CLC doit permettre de compléter les attributs des classes



Facture, Ligne, Couverture, Prestation, Acte. Une instance de CLC pourra être remplacée par une autre, la relation entre les deux est matérialisée.

3.2.20 Message La classe Message contient les informations de traçabilité du message AMC transmis et de la réponse associée. Cette classe permet en cas de litiges de retrouver les messages échangés. Elle peut également contenir les informations permettant d’identifier l’émetteur et le destinataire (adresse) ainsi que le délai de réponse.


Processus sous-jacent – Capture des données AMC et évolution des statuts AMC/RAC 25/103

4 Processus sous-jacent – Capture des données AMC et évolution des statuts AMC/RAC

Quel que soit le processus (ACE / Séjours), la collecte exhaustive des données AMC est le préalable au lancement des différents services ROC. Différentes modalités sont possibles pour collecter ces données : elles sont présentées dans ce chapitre. La complétude de ces données AMC collectées doit être suivie à toutes les étapes du processus ACE ou Séjours. Pour cela, un premier indicateur a été défini: il s’agit de l’indicateur STATUT_AMC. Un second indicateur a été défini pour identifier, suite au lancement des services ROC, l’absence ou non de reste à charge (RAC) : il s’agit de l’indicateur STATUT_RAC. Ces indicateurs permettent d’une part de visualiser le statut associé à la venue en cours. Grâce à l’indicateur STATUT_AMC, une alerte peut être remontée au patient sur l’absence de certaines données ou sur un potentiel reste à charge, grâce à l’indicateur STATUT_RAC. Ces indicateurs permettent d’autre part à l’établissement de constituer des listes de travail, permettant de traiter en masse des venues nécessitant une action particulière. L’objectif de ce chapitre est ainsi de présenter ce processus sous-jacent « capture des données AMC et mise à jour des statuts AMC/RAC », qui inclut :

la collecte des données AMC ;

la mise à jour du statut AMC et du statut RAC (reste à charge) ;

le suivi opérationnel de ces statuts AMC et RAC.



Figure 6: Capture des données AMC, évolution des statuts AMC/RAC et suivi opérationnel de la venue



4.1 Collecte des données AMC

Cette étape doit permettre de mettre en œuvre un système de capture (lecture, stockage) des données AMC. L’éditeur prendra soin de s’assurer que le système mis en place permet une capture rapide et performante des données afin de gagner en efficacité notamment lors des phases d’admission des patients. Cette capture doit, si possible être automatisée : en effet, une saisie des données par un opérateur augmente le risque d’erreur. Cette capture des données AMC doit permettre de récupérer, via l’attestation de tiers payant :

le numéro de la complémentaire santé du patient ;

le numéro d’adhérent à la complémentaire santé du patient (lorsque ce numéro est présent sur l’attestation de tiers payant) ;

le code « type de convention » ;

le critère secondaire de routage. Lors de la capture, le système doit indiquer les données obligatoires pour l’appel des services ROC sans pour autant interdire l’enregistrement des données si celles-ci sont incomplètes. Cette capture de donnée doit être horodatée dans le système. Le système doit permettre de visualiser l’historique des données AMC d’un patient. Plusieurs modes de capture des données AMC sont possibles (saisie manuelle, recueil du datamatrix, réutilisation des données stockées dans le SI…). Dans tous les cas, le système doit tracer la façon dont les données AMC ont été capturées.

4.1.1 Recueil AMC par Datamatrix La dernière version du cahier des charges « Harmonisation des attestations AMC » (http://www.complementairesante.fr/Contenu/Attestation-TP/Telechargements) publié en 2016 ajoute (par rapport à la version 2015) la normalisation des datamatrix sur les attestations de tiers payant AMC. A partir de 2017, les premières attestations de tiers payant avec datamatrix sont en circulation. Celui-ci permettra de recueillir les informations AMC du patient de manière fiable et performante. La maquette ci-dessous présente un exemple d’écran de recueil des données AMC.

Figure 7: Exemple de recueil des données AMC par datamatrix



Dans cette maquette, les données AMC sont automatiquement complétées dans la venue mais également vérifiées grâce à l’appel des services annuaire et IDB. L’établissement sait donc instantanément si la couverture AMC est reconnue. Le type de convention peut être différent selon le domaine et un domaine donné peut correspondre à plusieurs types de convention Dans le cas où à un domaine donné sont associés plusieurs types de convention, notamment dans la cas des réseaux, les conventions lues sont choisies et appliquées sur la couverture. La classe RefReseauConv permet de gérer les informations de conventionnement de l’établissement avec un réseau.

4.1.2 Réutilisation des données Il s’agit de permettre le recyclage / la réutilisation des données AMC d’une venue précédente. La validité de la couverture AMC est vérifiée automatiquement (grâce au service IDB) à partir des données AMC stockées déjà fournies lors des précédentes venues au moment de la phase de préadmission ou à l’admission (s’il n’y a pas eu de préadmission). Le système présente alors la liste des AMC valides à la date. Le patient effectue ensuite un choix dans la liste des AMC présentées. Il peut également en présenter une autre. Si une seule AMC est connue et valide, le système utilise automatiquement celle-ci et informe le patient de l’utilisation de l’AMC. Les AMC qui ne sont plus valides peuvent être marquées avec un statut « désactivé » pour éviter de revérifier toutes les AMC à chaque venue. S’il y a plusieurs AMC possibles (celle du conjoint notamment), le patient doit valider le choix de l’AMC pour cette venue (dans le contexte séjour, la réalisation d’un appel au service SIM permettra de fournir les informations nécessaires au choix du patient). Le patient peut demander qu’une AMC soit définie par défaut et soit utilisée automatiquement pour les prochaines venues. Le système doit permettre d’informer le patient de la réutilisation des informations AMC d’une venue précédente.

4.2 Evolution du STATUT_AMC et du STATUT_RAC.

En fonction des données recueillies tout au long des processus ACE et Séjours, le système doit faire évoluer les deux indicateurs STATUT_AMC et STATUT_RAC. L’indicateur STATUT_AMC peut prendre 4 valeurs :

Initialement, il est positionné à NON_RECUEILLI.

Lorsque le patient indique explicitement qu’il n’a pas de couverture AMC, cet indicateur passe à PAS_DONNEES_AMC. Le système doit donc permettre la capture explicite de l’information indiquant que le patient ne dispose pas de couverture AMC.

Lorsque le patient dispose d’une couverture AMC : o Si l’AMC appartient à la liste ROC, l’indicateur passe à AMC_ROC.



o Si l’AMC n’appartient pas à la liste ROC, l’indicateur passe à AMC_HORS_ROC.

L’indicateur STATUT_RAC peut prendre 2 valeurs :

Initialement, il est positionné à RAC. Cela signifie qu’il peut y avoir un reste à charge pour le patient.

Lorsque l’appel aux services indique une prise en charge totale des prestations par l’AMC, il est positionné à PAS_RAC. Cela signifie qu’il n’y aura pas de reste à charge pour le patient, de façon certaine.

Le statut RAC indique une possibilité de reste à charge tandis que le statut PAS_RAC indique une certitude d’absence de reste à charge. A noter : l’indicateur STATUT_RAC n’est volontairement pas défini dans ce guide lorsque l’indicateur STATUT_AMC est AMC_HORS_ROC. En effet, lorsque l’AMC est hors ROC, les établissements peuvent souhaiter positionner par défaut l’indicateur STATUT_RAC à RAC ou PAS_RAC. Ces statuts permettront de suivre l’état des couvertures dans la perspective du suivi opérationnel décrit ci-après.

4.3 Suivi opérationnel du STATUT_AMC et du STATUT_RAC

Les indicateurs STATUT_AMC et STATUT_RAC définis précédemment servent de point de départ au suivi des venues. Ce suivi peut se faire venue par venue ou en masse.

4.3.1 Informations AMC sur la venue Le système doit permettre de visualiser les données AMC associées à une venue et ainsi de s’assurer de la complétude des éléments recueillis mais également d’identifier s’il y a un reste à charge (RAC). La maquette ci-dessous est un exemple du type d’écran que le système doit mettre à disposition. Le symbole € permet d’identifier un RAC patient. Le point d’exclamation indique un élément nécessitant une vigilance.

Figure 8: Exemple d'écran permettant de visualiser les données AMC d’une venue



4.3.2 Listes de travail Les listes de travail sont des outils pour traiter en masse et rapidement des cas particuliers. Ces listes doivent notamment permettre d’extraire (liste non exhaustive) :

les venues pour lesquelles les données AMC n’ont pas été recueillies ;

les venues pour lesquelles un reste à charge potentiel est identifié ;

les venues pour lesquelles les services ROC retournent une erreur nécessitant un traitement de la part de l’établissement ;

les couvertures à échéance de renouvellement qui vont nécessiter d’avertir le patient qu’il doit fournir de nouvelles pièces justificatives pour la couverture AMC ;

la liste des couvertures en cours avec une date de fin de contrat durant le séjour qui vont nécessiter de demander au patient une nouvelle attestation de tiers payant AMC ou l’informer du reste à charge sans AMC ;

la liste des couvertures en cours à date de changement d’exercice comptable afin d’automatiser la préparation de la facturation des prestations hors soins ;

la liste des entrées prévisionnelles du jour classée selon la complétude des données qui permet d’identifier les admissions qui peuvent être simplifiées et donc plus rapides ;

… Des processus automatiques doivent être implémentés à partir de ces listes et sont décrits dans le chapitre 8. Nous avons ici décrit deux exemples de listes de travail qui peuvent être mis en œuvre afin de faciliter le travail des établissements dans le traitement des erreurs et la facturation AMC ROC.

4.3.2.1 Liste des couvertures AMC ROC avec reste à charge La liste des couvertures AMC ROC avec reste à charge permet à l’établissement de faciliter le traitement des venues impliquant une couverture AMC ROC avec RAC avant la sortie du patient. Il affiche les venues des patients admis en consultation ou hospitalisation et dont l’indicateur STATUT_RAC est RAC. La maquette présente un certain nombre de fonctionnalités qui permettront de faciliter la gestion des venues.

o Le filtre sur les dates d’entrée et de sortie permet de limiter les venues sur une période.

o Les colonnes peuvent être triées notamment par le montant du RAC afin de prioriser la facturation sur les montants les plus importants.

o Le service et l’unité en cours permettent, si la venue est en erreur, de contacter le service afin de valider avec lui et le patient les données.

o Le numéro de dossier administratif qui permet de revenir dans le dossier pour rajouter d’éventuels compléments d’informations.



Figure 9: Liste des couvertures avec RAC

4.3.2.2 Gestion des retours AMC L’objectif de cet écran est de gérer les retours KO des services AMC. Cet écran ne présente que le dernier statut d’un service AMC. Par exemple, si le service IDB est appelé plusieurs fois, une fois en erreur puis ensuite sans erreur, l’appel n’apparaitra pas dans la liste car il n’est plus en erreur. Cette liste de travail doit intégrer le code et le motif de rejets (sur la base des codes rejets définis dans le cahier des charges HospiAMC) ainsi que la famille de rejets. Trois familles de rejets ont été identifiées : une proposition de répartition des rejets dans ces trois familles est proposée dans ce document, à titre informatif. Le système doit permettre à l’établissement de définir sa propre répartition des rejets dans les trois familles ci-dessous, ainsi que les actions correctives associées à ces rejets.

Couvertures en erreur fonctionnelle : codes retours classifiés comme erreur fonctionnelle sur lesquels l’établissement pourra intervenir.

Couvertures en erreur technique : codes retours classifiés comme erreur technique dont seul un administrateur ou l’éditeur pourra intervenir.

Couvertures en information patient : ce sont les couvertures pour lesquelles une information du patient est nécessaire.

Le système doit proposer des assistants permettant d’accompagner l’utilisateur dans la correction des erreurs :

Le système doit restituer aux utilisateurs les informations « Code retour », « Motif de rejet technique », « Motif de rejet fonctionnel » et « Message » (cf. spécification du web service IDB).

Le système doit mettre à disposition des utilisateurs les coordonnées de la personne du service de l’AMC à contacter, en exploitant les données contact AMC fournies dans la réponse IDB.

Le système doit ainsi permettre de rejouer automatiquement les couvertures signalées en erreurs techniques lors de la reprise.



Figure 10: Traitement des retours AMC

4.3.2.2.1 Filtrage des dates La zone en haut à gauche permet de filtrer sur les venues en cours entre deux dates. Ceci permet de limiter aux dossiers d’une période limitée pour plus de lisibilité.

4.3.2.2.2 Listes des états AMC La liste des états AMC est constituée à partir des codes erreurs en les regroupant par famille :

- erreurs fonctionnelles ; - erreurs techniques ; - informations patients.

Le tableau des codes erreurs permet d’identifier les codes retour et la classification dont ils font partie. Le nombre affiché à côté de l’état correspond au nombre de couvertures dans l’état.

4.3.2.2.3 Filtrage entête de colonne Les filtres en entête de colonne permettent de limiter le nombre de résultats et de traiter les retours identiques en même temps.

4.3.2.2.4 Action Dans cette maquette, l’action permet d’accéder au dossier administratif afin de prendre en compte les retours AMC.

4.3.2.2.5 Révision La colonne Révision permet à un utilisateur de laisser un message par rapport à un retour AMC. Par exemple si l’utilisateur est en train de traiter le retour AMC, il peut indiquer par un message qu’il est en train de le faire. Ceci permet d’éviter de retraiter plusieurs fois le même message.

4.3.3 Informations du patient Les indicateurs STATUT_AMC et STATUT_RAC doivent permettre à l’établissement d’informer le patient du statut de sa couverture. Les modalités d’information du patient sont à définir avec l’établissement de santé. Des modèles-types de documents d’information seront proposés dans le cadre du programme SIMPHONIE.


Processus métier ACE 33/103

5 Processus métier ACE L’objectif de ce chapitre est de présenter la façon dont le processus métier ACE des établissements de santé peut être transformé en intégrant les services ROC, afin de leur apporter le maximum de valeur ajoutée. Le processus métier ACE décrit dans ce chapitre est donc un modèle que les éditeurs peuvent appliquer dans le fonctionnement de leurs systèmes. Le processus métier ACE a été découpé en trois phases :

La phase de préadmission. Cette phase débute avec la prise de rendez-vous et se termine avec l’admission. Elle permet en particulier d’évaluer la couverture AMC du patient en amont de sa venue, grâce au service IDB.

La phase d’admission. Cette phase débute avec l’admission le jour de l’arrivée du patient et se termine à la sortie du patient. Elle permet en particulier de vérifier la couverture du patient le jour J, grâce au service IDB.

La phase de facturation. Elle permet en particulier d’évaluer précisément la part prise en charge par l’AMC et d’obtenir un engagement de paiement de sa part ainsi que de facturer le patient en cas de reste à charge, grâce au service CLC.

5.1 En préadmission ACE

La préadmission correspond à la préparation de la venue du patient dans l’établissement. L’objectif de cette phase de préadmission est d’anticiper le recueil des informations administratives en amont de la venue du patient pour ensuite fluidifier sa prise en charge administrative lors de l’admission. En recueillant le maximum d’informations sur le patient (identité, droits AMO / AMC…) dès cette étape, l’établissement peut identifier les patients qui peuvent bénéficier d’un accueil administratif simplifié (lorsque les données sont complètes) et ceux qui doivent bénéficier d’un accueil administratif plus poussé (lorsque les données sont incomplètes). Cette démarche peut ainsi permettre de limiter les flux à l’accueil, et donc le temps d’attente du patient à son arrivée dans l’établissement. L’établissement peut également informer le patient sur la nécessité de compléter ses données avant sa venue, et ainsi de le rendre acteur de sa prise en charge administrative. Le service IDB offre cette possibilité en phase de préadmission, pour les données AMC. Il permet en effet à l'établissement de réaliser une demande IDB en amont de la venue effective du patient. De plus, l’appel de ce service assure, le jour de la venue, l’existence d’une couverture par l’AMC, contrairement au dispositif actuel qui s’appuie sur une présomption de couverture.



Figure 11: Préadmission dans le contexte ACE



5.1.1 La création d’une venue prévisionnelle Cette étape permet la création d’une venue prévisionnelle, à partir de la prise de rendez-vous. Le prérequis pour que les exigences exposées dans cette phase soient applicables est que le système gère les venues prévisionnelles. La gestion des venues prévisionnelles signifie la capacité du système à identifier et capturer les venues prévisionnelles (statut de la venue permettant de distinguer une venue prévisionnelle d’une venue réelle). Lors de la création de la venue prévisionnelle, plusieurs cas peuvent se présenter :

Les traits d’identité collectés lors de la prise de rendez-vous permettent d’associer cette venue prévisionnelle à une identité existante du système.

Les traits d’identité collectés lors de la prise de rendez-vous ne permettent pas d’associer la venue prévisionnelle à une identité existante du système. Deux cas sont possibles :

o une pièce d’identité est fournie lors de la prise de rendez-vous, il est alors possible de créer une nouvelle identité au statut « Valide » dans le système ;

o sinon, une identité au statut « Provisoire » est créée dans le système. L’identité reste au statut « Provisoire » jusqu’à ce qu’une pièce d’identité soit présentée.

5.1.1.1 Prédécesseur

Le patient prend rendez-vous pour une venue dans l’établissement. Ce rendez-vous est souvent pris plusieurs mois avant la date de la venue. La prise de rendez-vous peut être réalisée selon plusieurs modalités : par téléphone, par un contact physique, par le patient sur un outil de prise de rendez-vous en ligne ou une borne de préadmission / prise de rendez-vous.

5.1.1.2 Successeur

Le système permet de compléter la venue prévisionnelle et de collecter les données AMO/AMC relatives à cette venue prévisionnelle (cas nominal).

5.1.2 Le complément venue et la collecte des données AMO/AMC Lors de la préadmission, le système doit permettre d’intégrer tout complément survenu sur la venue susceptible de modifier cette venue prévisionnelle (changement de date…). Le système doit également permettre de collecter l’ensemble des informations nécessaires à l’appel des services AMO/AMC afin de valider les couvertures AMO et AMC du patient et de l’informer sur celles-ci le plus en amont de son arrivée. Les données AMC peuvent être collectées de différentes façons et à différents moments :

réutilisation des données AMC déjà présentes dans le dossier administratif du patient ;

saisies des informations transmises par le patient lors de la prise de rendez-vous ;



récupération des éléments transmis par le patient, par exemple, lorsque celui-ci complète son dossier administratif en ligne, via un formulaire ou un portail patient.

5.1.2.1 Prédécesseurs

Le système a créé la venue prévisionnelle.

La venue prévisionnelle a été modifiée (date de la venue, AMO, AMC…)

La venue prévisionnelle a été modifiée suite au suivi opérationnel mené sur le STATUT_AMC. Ce cas correspond à la transmission par le patient des données de sa couverture AMC, lorsque celle-ci n’était pas disponible à la création de la venue prévisionnelle.

La venue prévisionnelle a été modifiée suite au suivi opérationnel mené sur le STATUT_RAC. Ce cas correspond à la transmission par le patient d’informations complémentaires sur sa couverture AMC, lorsque celle-ci a fait l’objet d’une erreur IDB.

5.1.2.2 Successeur

Le système bascule vers la gestion de l’indicateur STATUT_AMC sur la base des informations récoltées (cas nominal).

5.1.3 Gestion de l’indicateur STATUT_AMC. Cette étape permet d’analyser le degré de complétude des informations AMC disponibles et ainsi de mettre à jour l’indicateur STATUT_AMC relatif à la venue. En fonction de ce statut, le système pourra ainsi appeler les services annuaire et IDB ou revenir vers le patient pour l’informer du statut de sa couverture. Cette étape est décrite plus en détail dans le chapitre 4.


La venue a été complétée et les données AMO/AMC relatives à cette venue ont été collectées.

5.1.3.2 Successeurs

Si le STATUT_AMC = AMC_ROC, le système procède à l’appel du processus annuaire service IDB (cas nominal).

Si le STATUT_AMC = NON_RECUEILLI, le système met à disposition cette information pour le suivi opérationnel du STATUT_AMC. Le système permet notamment d’alerter le patient de la non complétude de ses données AMC (cas alternatif).

Si le STATUT_AMC = PAS_DONNEES_AMC, le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas alternatif).

Si le STATUT_AMC = AMC hors ROC, le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas alternatif).

5.1.4 Le suivi opérationnel du STATUT_AMC : l’information du patient sur la non complétude de sa venue

Cette étape consiste à informer le patient que les éléments disponibles dans le système (identité, données AMO/AMC) ne permettent pas d’obtenir une information prévisionnelle sur sa couverture AMC. Au-delà des données AMO/AMC, les données relatives à l’identité participe en effet à l’identification du bénéficiaire des soins dans le système AMC.



L’information peut être transmise au patient par plusieurs moyens1 :

SMS ;

Email ;

document (remis en main propre ou envoyé) ;

lien vers un formulaire en ligne à compléter, dont les réponses s’intègrent dans le SI.

Cette information peut être associée à un document rappelant les informations sur le rendez-vous. Au travers des informations fournies au patient en amont de sa venue, celui-ci devient acteur du processus en participant à la complétude de ses données. Néanmoins, selon l’organisation de l’établissement de santé, celui-ci décidera ou non de solliciter le patient dans ce cas de figure.


Le système a identifié que les données AMC disponibles ne permettaient pas d’appeler le processus annuaire service IDB (STATUT_AMC = NON_RECUEILLI).

5.1.4.2 Successeurs

Si le patient retourne des informations complémentaires, celles-ci complètent la venue et alimentent la collecte des données AMO/AMC (cas nominal).

Si le patient ne retourne pas d’information complémentaire, le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas alternatif).

A noter : le système pourra éventuellement permettre de paramétrer un délai au bout duquel, sans réponse du patient, le STATUT_RAC est mis à jour.

5.1.5 L’appel au processus annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB dès que le STATUT_AMC passe à AMC_ROC. Le processus appel annuaire service IDB est décrit plus en détail dans le chapitre 7. A noter : afin d’identifier d’éventuels changements de la couverture AMC, de nouveaux appels au processus annuaire service IDB peuvent être lancés de façon automatique par le système à J-X jours et le jour de l’admission prévisionnelle, à partir de minuit (cf. chapitre 8 – traitement batch)


Le système a mis à jour l’indicateur STATUT_AMC à AMC_ROC.

Le système a déclenché automatiquement l’appel du processus annuaire service IDB à J-X.

Le système a déclenché automatiquement l’appel du processus annuaire service IDB à J, à partir de minuit.

5.1.5.2 Successeur

Le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas nominal).

1 Des modèles-types de documents d’information seront proposés dans le cadre du programme SIMPHONIE



5.1.6 Gestion de l’indicateur STATUT_RAC Cette étape permet de gérer l’information relative au reste à charge du patient (reste à charge possible ou une absence de reste à charge). Cette étape est décrite plus en détail dans le chapitre 4.


Le système a appelé le processus annuaire service IDB.

Le système a fait évoluer l’indicateur STATUT_AMC à PAS_DONNEES_AMC.

Le système a fait évoluer l’indicateur STATUT_AMC à AMC_HORS_ROC.

Le système a conservé l’indicateur STATUT_AMC à NON_RECUEILLI en l’absence d’information complémentaire transmise par le patient.

5.1.6.2 Successeur

Le système met à disposition cette information pour le suivi opérationnel du STATUT_RAC. Le système permet notamment d’alerter le patient de son reste à charge prévisionnel ou de le solliciter suite à une erreur lors de l’appel du processus annuaire service IDB.

5.1.7 Suivi opérationnel du STATUT_RAC. Cette étape permet à l’établissement d’informer le patient de l’existence d’un reste à charge quand cela est utile. Au stade de préadmission, chaque établissement doit définir dans quels cas il est opportun d’informer / solliciter le patient, sachant que les informations transmises par le service IDB avant le jour de la venue sont informatives, puisque la situation de couverture AMC peut changer jusqu’à l’admission.


Le système a mis à jour l’indicateur STATUT_RAC.

5.1.7.2 Successeurs

Le processus prend fin (cas nominal).

Lorsque l’établissement récolte d’autres informations suite au suivi opérationnel du STATUT_RAC, le système bascule vers le complément venue et collecte des données AMO/AMC (cas alternatif).



5.2 En admission ACE

L’admission correspond à l’arrivée du patient dans l’établissement. Le patient peut être admis suite à une préadmission mais également directement, sans préadmission. L’objectif de cette phase est de valider l’ensemble des données nécessaires à la gestion du dossier administratif du patient (identité, droits AMO/AMC…). Le service IDB apporte une réelle évolution aux établissements de santé, en phase d’admission, pour les données relatives aux droits AMC, en assurant, le jour de la venue, l'existence d'une couverture par l'AMC, contrairement au dispositif actuel qui s’appuie sur une présomption de couverture. Cette phase d’admission doit être adaptée à la situation administrative du patient. Ainsi, si les données relatives à sa venue ont été collectées en amont, lors de la phase de préadmission, l’établissement peut proposer des systèmes d’admission innovants s’appuyant notamment sur une borne d’accueil ou sur une application terminaux mobiles afin d’orienter les patients en fonction de la complétude de leurs données à l’admission tout en veillant à la bonne réalisation des contrôles d’identito-vigilance.

La borne d’accueil peut utiliser les données telles que la carte vitale, un identifiant de préadmission, un code barre, la carte AMC du patient, un datamatrix AMC (cf. h

http://www.complementairesante.fr/Contenu/Attestation-TP/Telechargements ) pour identifier le patient.

http://www.complementairesante.fr/Contenu/Attestation-TP/Telechargements



Figure 12: Admission dans le contexte ACE



5.2.1 L’identification du patient Cette étape permet d’identifier le patient lors de son arrivée dans l’établissement, en respectant les règles d’identito-vigilance. L’objectif est de rechercher le patient dans le système à partir d’informations : traits stricts d’identité, numéro d’identification… A l’issue de cette recherche, trois cas peuvent se présenter :

soit le patient est déjà connu de l'établissement (venues précédentes) ; soit le patient n'est pas connu, il est nécessaire de créer l’identité dans le

système en respectant les règles d’identito-vigilance ; soit le patient est connu mais sous une identité provisoire qui a donc besoin

d’être validée (identité provisoire créée lors de la prise de rendez-vous, de la préadmission ou d’admission via les urgences sans vérification de l’identité…).


Il s’agit de l’arrivée du patient dans l’établissement. Toutefois dans certains cas, le patient peut être identifié après admission (Cas des urgences).

5.2.1.2 Successeurs

Si l’identité du patient est déjà connue et validée, le système identifie la venue concernée (cas nominal).

Si l’identité du patient n’est pas connue ou si elle est provisoire, le système doit créer ou valider l’identité (cas alternatif).

5.2.2 Création / Validation de l’identité Cette étape permet de créer une identité, dans le cas où celle-ci n’est pas connue ou de valider une identité, dans le cas où celle-ci est provisoire.


Le patient a été identifié comme étant non connu ou a été identifié sous une identité provisoire.

5.2.2.2 Successeurs

Si l’identité existe sous forme provisoire, le système procède à l’identification de la venue une fois l’identité provisoire validée (cas nominal).

Si l’identité n’existe pas, le système procède à la création de la venue du patient, une fois l’identité créée (cas alternatif).

5.2.3 L’identification de la venue concernée Cette étape permet d’identifier si la venue du jour existe dans le système sous forme d’une venue prévisionnelle, et si oui, si celle-ci est complète. La complétude des venues prévisionnelles du jour peut être analysée à l’aide d’un batch « entrée prévisionnelle du jour » décrit au chapitre 8.


Le patient a été identifié comme connu dans le système.

L’identité provisoire sous laquelle le patient était connu dans le système a été validée.



5.2.3.2 Successeurs

Si le système identifie la venue prévisionnelle et que celle-ci a déjà été complétée en amont de l’admission du patient (appel au processus annuaire service IDB réalisé à J, à partir de minuit), le système doit uniquement réaliser le mouvement d’entrée (admission en « circuit court ») (cas nominal).

Si le système identifie la venue prévisionnelle mais que celle-ci est incomplète, l’établissement de santé doit :

o d’une part, compléter la venue et collecter les données AMO/AMC ; o et d’autre part, réaliser le mouvement d’entrée (cas alternatif).

Si le système n’identifie pas de venue prévisionnelle, le système doit créer cette venue (cas alternatif).

5.2.4 La création de la venue Cette étape permet de créer la venue si celle-ci n’existe pas dans le système.


Le système n’a pas identifié de venue prévisionnelle correspondant à la venue du jour, malgré l’existence d’une identité patient connue ou la validation d’une identité patient provisoire.

Le système a créé une identité patient car celui-ci n’était pas connu.

5.2.4.2 Successeurs

Le système réalise le mouvement d’entrée correspondant à la création de la venue ; et

l’établissement procède au complément venue et à la collecte des données AMO/AMC (cas nominal).

5.2.5 La réalisation du mouvement d’entrée Cette étape permet de réaliser le mouvement d’entrée associé à la venue. Ce mouvement peut être fait en validant une venue prévisionnelle ou en créant une nouvelle venue.


La venue a été identifiée comme une venue prévisionnelle.

La venue a été créée.

5.2.6 Le complément venue et la collecte des données AMO/AMC Cette étape permet de compléter la venue (prise en compte de changement dans la venue) et de compléter en particulier les données AMO et AMC nécessaires à l’appel des services.


La venue identifiée correspond à une venue prévisionnelle incomplète.

Une venue a été créée.

Le patient a apporté de nouveaux éléments lors de sa venue.

5.2.6.2 Successeur

Le système bascule vers la gestion de l’indicateur STATUT_AMC sur la base des informations récoltées (cas nominal).



5.2.7 La gestion de l’indicateur STATUT_AMC. Cette étape permet d’analyser le degré de complétude des informations AMC disponibles et ainsi de mettre à jour l’indicateur STATUT_AMC relatif à la venue. En fonction de ce statut, le système pourra ainsi appeler les services annuaire et IDB ou revenir vers le patient pour l’informer du statut de sa couverture. Cette étape est décrite plus en détail dans le chapitre 4.



5.2.7.2 Successeurs




Si le STATUT_AMC = AMC hors ROC, le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas alternatif).

5.2.8 Le suivi opérationnel du STATUT_AMC : l’information au patient sur la non complétude de la venue

Cette étape permet d’informer le patient que les éléments disponibles dans le système ne permettent pas de valider sa couverture AMC. Dans un contexte d’admission, cette information est transmise au patient par l’agent quand le patient bénéficie d’un accueil physique. Quand le patient bénéficie d’un accueil par borne, cette alerte est transmise par le système. Cette information peut également être transmise au patient par2 :

SMS ;

Email ;

document (remis en main propre ou envoyé).


L’indicateur STATUT_AMC est positionné à NON_RECUEILLI.

5.2.8.2 Successeurs

Si le patient retourne des informations complémentaires, celles-ci complètent la venue et alimentent la collecte des données AMO/AMC (cas nominal).

Si le patient ne retourne pas d’information complémentaire, le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas alternatif).

5.2.9 L’appel au processus annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB, dès que le STATUT_AMC passe à AMC_ROC. 2 Des modèles-types de documents d’information seront proposés dans le cadre du programme SIMPHONIE



Le processus appel annuaire service IDB est décrit plus en détail dans le chapitre 7.



5.2.9.2 Successeur

Le système bascule vers la gestion de l’indicateur STATUT_RAC de la venue (cas nominal).

5.2.10 Gestion de l’indicateur STATUT_RAC Cette étape permet de gérer l’information relative au reste à charge du patient (reste à charge possible ou une absence de reste à charge). Cette étape est décrite plus en détail dans le chapitre 4.


Le système a appelé le processus annuaire service IDB.

Le système a fait évoluer l’indicateur STATUT_AMC à PAS_DONNEES_AMC.

Le système a fait évoluer l’indicateur STATUT_AMC à AMC_HORS_ROC.

Le système a conservé l’indicateur STATUT_AMC à NON_RECUEILLI en l’absence d’information complémentaire transmise par le patient.

5.2.10.2 Successeur

Le système met à disposition cette information pour le suivi opérationnel du STATUT_RAC. Le système permet notamment d’alerter le patient de son reste à charge prévisionnel ou de le solliciter suite à une erreur lors de l’appel du processus annuaire service IDB.

5.2.11 Le suivi opérationnel du STATUT_RAC Cette étape permet à l’établissement d’informer le patient de l’existence possible d’un reste à charge quand cela est utile. Au stade de l’admission, chaque établissement doit définir les actions à mener vis-à-vis du patient au regard de son reste à charge prévisionnel. Ainsi, s’il existe un reste à charge prévisionnel, l’établissement peut envisager un paiement via la prise de l’empreinte carte bancaire dans le cadre d’EA-DC.



5.2.11.2 Successeurs

Le processus prend fin (cas nominal).

Lorsque l’établissement récolte d’autres informations suite au suivi opérationnel de la venue, le système bascule vers le complément venue et collecte des données AMO/AMC (cas alternatif).



5.3 En facturation ACE

La phase de facturation correspond à l’analyse des prestations et des couvertures, pour facturation et émission des factures-tiers vers les différents débiteurs. Cette phase a pour objectif de facturer les différents débiteurs associés à la venue, en s’assurant de l’exhaustivité et de la qualité de la facturation pour sécuriser les recettes de l’établissement. Cette phase a aussi pour objectif, quand cela est possible, de facturer le patient lors de sa présence dans l’établissement, pour sécuriser le recouvrement des restes à charge patient. Les services IDB et CLC répondent à ces objectifs en identifiant les patients ayant un reste à charge potentiel, ce qui permet de les facturer avant la sortie de l’établissement et en garantissant la qualité de la facture-tiers produite pour l’AMC, qui s’engage alors à la régler dès la facturation. Cette phase de facturation démarre à partir du moment où la facture-tiers AMO passe au statut validée (cf. programme SIMPHONIE – cahier des charges pilotage de la chaîne Accueil – Facturation - Recouvrement). En effet, le principe est de ventiler par défaut la part non prise en charge par l’AMO sur la facture-tiers AMC puis de déclencher l’appel au service CLC pour mettre à jour la facture-tiers AMC et basculant la part non prise en charge par l’AMC sur une facture-tiers patient. Deux situations peuvent être envisagées, en fonction des cas : facturation immédiate en présence du patient, quand cela est possible ou facturation a posteriori.



Figure 13: Facturation dans le contexte ACE



5.3.1 La validation de la facture-tiers AMO Cette étape permet de valider la facture-tiers AMO. La notion de facture-tiers validée est également décrite dans le programme SIMPHONIE – cahier des charges pilotage de la chaîne Accueil – Facturation – Recouvrement.

5.3.1.1 Successeur

Le système émet la facture-tiers AMO (cas nominal).

5.3.2 L’émission de la facture-tiers AMO Cette étape permet d’émettre la facture-tiers AMO. La notion de facture-tiers émise est également décrite dans le programme SIMPHONIE – cahier des charges pilotage de la chaîne Accueil – Facturation – Recouvrement.


La facture-tiers AMO est validée (cf. programme SIMPHONIE – cahier des charges pilotage de la chaîne Accueil – Facturation - Recouvrement).

5.3.2.2 Successeur

Le système attend le retour AMO et le réceptionne (cas nominal).

5.3.3 La réception du retour AMO. Cette étape permet de réceptionner le retour de l’AMO, qu’il s’agisse d’un paiement (NOEMIE 578) ou d’un rejet (NOEMIE 908).


La facture-tiers AMO est émise.

5.3.3.2 Successeurs

Si l’AMO répond avec un retour NOEMIE 578 (paiement), la facture-tiers AMC (DRE-ES) est émise.

Si l’AMO répond avec un retour NOEMIE 908 (rejet), l’établissement doit traiter l’erreur (cas alternatif) et la facture-tiers AMC (DRE-ES) ne doit pas être émise.

5.3.4 Le retraitement de la venue Cette étape permet de retraiter la venue, quand celle-ci a fait l’objet d’un rejet de la part de l’AMO. Tant que le rejet ne sera pas traité, la facture-tiers AMC (DRE-ES) n’est pas émise.


Le système a enregistré un retour NOEMIE 908 (rejet).

5.3.5 L’analyse des couvertures de la venue Cette étape permet de collecter l’ensemble des informations nécessaires à la validation de la facture. La première étape consiste à identifier les différentes couvertures valides de la venue. Il peut y avoir plusieurs couvertures pour une venue ACE, notamment dans les cas suivants :

Passage aux urgences à cheval sur deux jours : le numéro de période de facturation reste le même mais l’occurrence change.



Plusieurs prestations dans des contextes différents (nature d’assurance / parcours de soins) sur la même venue : le numéro de période de facturation change.

Cette étape peut se dérouler dans des contextes différents.

Si le patient a un reste à charge potentiel et qu’il est présent, il est préférable de procéder à cette étape immédiatement (sans attendre le retour de l’AMO), en présence du patient.

Si le patient est absent et/ou n’a pas de reste à charge, il est préférable d’attendre le retour NOEMIE 578 de l’AMO pour procéder à cette étape. En effet, dans le cas il y a un retour NOEMIE 908 de l’AMO, il pourra être nécessaire de réaliser une nouvelle analyse de la part AMC en fonction des modifications réalisées sur la venue.

La réponse fournie par l’IDB, pour chacune des couvertures, permet d’identifier la façon de procéder au calcul de la répartition de la part non prise en charge par l’AMO entre le patient et l’AMC, pour chacune de ces couvertures.

5.3.5.1 Successeur

Le système procède à l’appel du processus de calcul.

5.3.6 Le processus de calcul Cette étape permet de procéder au calcul de la répartition de la part non prise en charge par l’AMO entre le patient et l’AMC. Ce processus est décrit plus en détail dans le chapitre 7.

Si la réponse du service IDB a retourné un reste à charge possible pour le patient et l’indication de procéder à un calcul local, le système applique la règle de calcul fournie dans la réponse IDB et évalue le reste à charge du patient pour établir la facture-tiers.

Si la réponse du service IDB a retourné un reste à charge possible pour le patient et l’indication de procéder à un calcul en ligne, le système procède à l’appel du processus annuaire service CLC. Le service CLC retourne la part prise en charge par l’AMC et le système peut ensuite calculer la part patient.


Le système a analysé les différentes couvertures associées à la venue.

5.3.6.2 Successeur

Le système bascule vers la gestion de l’indicateur STATUT_RAC en fonction de la réponse fournie par le calcul (cas nominal).

5.3.7 La gestion de l’indicateur STATUT_RAC Cette étape permet de faire évoluer l’indicateur STATUT_RAC en fonction de la réponse fournie par le calcul, qu’il ait été fait en local ou en ligne. L’indicateur STATUT_RAC reste à RAC si le calcul fait état d’un reste à charge pour le patient. Il passe à PAS_RAC si le calcul indique qu’il n’y a pas de reste à charge pour le patient.


Le système a procédé au processus de calcul (en local ou en ligne).



5.3.7.2 Successeur

La facture-tiers AMC et / ou patient sont validées.

5.3.8 La validation de la facture-tiers patient Cette étape permet de valider la facture-tiers patient dans le cas où un reste à charge a été identifié lors du calcul.


Le système restitue l’indicateur STATUT_RAC = RAC.

5.3.8.2 Successeur

Le système émet la facture-tiers patient.

5.3.9 L’émission de la facture-tiers patient Cette étape permet d’émettre la facture-tiers patient dans le cas où un reste à charge a été identifié lors du calcul.


La facture-tiers patient a été validée

5.3.9.2 Successeur

L’établissement informe le patient du reste à charge et l’invite à procéder au règlement, via un encaissement en direct si le patient est présent ou via un encaissement en différé sinon (cas nominal).

5.3.10 La demande d’encaissement de la facture-tiers patient Cette étape permet de demander au patient le règlement de sa facture-tiers. A noter : une facture-tiers acquittée doit être transmise au patient une fois le règlement effectué. Cette facture-tiers acquittée permettra au patient de se faire rembourser auprès de son AMC dans le cas où le tiers-payant n’a pu être réalisé.


Le système a émis la facture-tiers patient.

5.3.11 La validation de la facture-tiers AMC (DRE-ES) Cette étape permet de valider la facture-tiers AMC dans le cas où une prise en charge par l’AMC a été identifiée lors du calcul.


Le système a fait évoluer l’indicateur STATUT_RAC et l’a positionné à PAS_RAC, si la part non prise en charge par l’AMO est intégralement prise en charge par l’AMC ou l’a positionné à RAC, s’il y a un reste à charge patient malgré une prise en charge par l’AMC.

5.3.11.2 Successeur

Le système émet la facture-tiers AMC (DRE-ES) (cas nominal).

5.3.12 L’émission de la facture-tiers AMC (DRE-ES) Cette étape permet d’émettre la facture-tiers AMC (DRE-ES) dans le cas où une prise en charge par l’AMC a été identifiée lors du calcul. Cette étape nécessite toujours d’avoir obtenu un retour NOEMIE 578 de l’AMO pour être réalisée.




La facture-tiers AMC a été validée. et

Le système a reçu un retour NOEMIE 578 de la part de l’AMO.

5.3.12.2 Successeur

Le système attend le retour de l’AMC (paiement ou rejet) et le réceptionne (cas nominal).

5.3.13 La réception du retour AMC. Cette étape permet de réceptionner le retour de AMC, qu’il s’agisse d’un paiement ou d’un rejet.


La facture-tiers AMC (DRE-ES) est émise.


Si l’AMC répond avec un retour paiement, le processus prend fin.

Si l’AMC répond avec un retour rejet, l’établissement doit traiter l’erreur (cas alternatif).

5.3.14 Le retraitement de la venue Cette étape permet de retraiter la venue, quand celle-ci a fait l’objet d’un rejet de la part de l’AMC.


Le système a enregistré un retour rejet de la part de l’AMC.


Processus métier Séjours 51/103

6 Processus métier Séjours L’objectif de ce chapitre est d’identifier comment les services ROC peuvent s’intégrer dans le processus métier Séjours des établissements de santé, afin de leur apporter le maximum de valeur ajoutée. Le processus métier Séjours décrit dans ce chapitre est donc un modèle que les éditeurs peuvent appliquer dans le fonctionnement de leurs systèmes. Le processus métier Séjours a été découpé en quatre phases :

La phase de préadmission. Cette phase débute avec la programmation de l’hospitalisation et se termine avec l’admission. Elle permet en particulier d’évaluer la couverture AMC du patient en amont de sa venue, grâce au service IDB et de simuler la prise en charge par l’AMC, grâce au service SIM.

La phase d’admission. Cette phase correspond à l’admission le jour de l’arrivée du patient. Elle permet en particulier de vérifier la couverture du patient le jour J, grâce au service IDB et de simuler la prise en charge par l’AMC, grâce au service SIM.

La phase de venue. Cette phase comprend l’actualisation des informations administratives au fur et à mesure de l’évolution de la venue (dates du séjour, mutations, exonérations, prestations). Elle permet en particulier d’évaluer l’impact de ces modifications sur la prise en charge des prestations par l’AMC, grâce au service SIM. Dans cette phase de venue, un changement d’AMC peut intervenir en cours de la venue. Ce cas de figure implique l’actualisation des données AMC relatives à la venue et une évaluation de l’impact de ce changement sur la prise en charge des prestations par l’AMC, grâce aux services IDB et SIM.

La phase de facturation. Cette phase débute dès que les informations nécessaires à la facturation AMC/Patient sont disponibles. Elle permet en particulier d’évaluer précisément la part prise en charge par l’AMC et d’obtenir un engagement de paiement de sa part ainsi que de facturer le patient en cas de reste à charge, grâce au service CLC.

6.1 En préadmission Séjours

La préadmission correspond à la préparation de la venue du patient dans l’établissement. L’objectif de cette phase de préadmission est d’anticiper le recueil des informations administratives en amont de la venue du patient pour ensuite fluidifier sa prise en charge administrative lors de l’admission. En recueillant le maximum d’informations sur le patient (identité, droits AMO / AMC…) dès cette étape, l’établissement peut identifier les patients qui peuvent bénéficier d’un accueil administratif simplifié (lorsque leurs données sont complètes) et ceux qui doivent bénéficier d’un accueil administratif plus poussé (lorsque leurs données sont incomplètes). Cette démarche peut ainsi permettre de limiter les flux à l’accueil, et donc le temps d’attente du patient à son arrivée dans l’établissement. L’établissement peut également informer le patient sur la nécessité de compléter ses données avant sa venue, et ainsi de le rendre acteur de sa prise en charge administrative.



Les services IDB et SIM offrent ces possibilités en phase de préadmission, pour les données AMC. Il permet en effet à l'établissement de réaliser une demande IDB en amont de la venue effective du patient. De plus, l’appel de ce service assure, le jour de la venue, l’existence d’une couverture par l’AMC, contrairement au dispositif actuel qui s’appuie sur une présomption de couverture. De même, le service SIM permet d’évaluer le reste à charge du patient en amont de sa venue et ainsi de lui permettre d’opter ou non pour des prestations hors soins (chambre particulière…) en toute connaissance de cause. La phase de préadmission en hospitalisation étant très proche de celle décrite dans le processus fonctionnel ACE, les étapes communes ne sont pas détaillées dans ce chapitre et renvoient vers le chapitre précédent. La principale différence avec le processus fonctionnel ACE consiste en l’appel du processus annuaire service SIM en hospitalisation et à l’émission de la facture AMC indépendamment d’un retour paiement de l’AMO.



Figure 14: Préadmission dans le contexte Séjours



6.1.1 La création d’une venue prévisionnelle Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5. A noter : dans un contexte Séjours, la prise de rendez-vous correspond à la programmation du séjour.

6.1.2 Le complément venue et la collecte des données AMO/AMC Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5. En complément de la description de cette tâche au chapitre 5, les prestations hors soins peuvent être collectées.

6.1.3 Gestion de l’indicateur STATUT_AMC. Cette étape permet d’analyser le degré de complétude des informations AMC disponibles et ainsi de mettre à jour l’indicateur STATUT_AMC relatif à la venue. En fonction de ce statut, le système pourra ainsi appeler les services annuaire et IDB ou revenir vers le patient pour l’informer du statut de sa couverture. Cette étape est décrite plus en détail dans le chapitre 4.



6.1.3.2 Successeurs




Si le STATUT_AMC = AMC hors ROC, le système permet la réalisation d’une demande de prise en charge (cas alternatif).

6.1.4 La demande de prise en charge Cette étape permet de réaliser une demande de prise en charge auprès de l’AMC, quand celle-ci est hors du dispositif ROC.


Le système a mis à jour l’indicateur STATUT_AMC à AMC_HORS_ROC.

6.1.5 Le suivi opérationnel du STATUT_AMC. Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 4.

6.1.6 L’appel au processus annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB dès que le STATUT_AMC passe à AMC_ROC. Le processus appel annuaire service IDB est décrit plus en détail dans le chapitre 7.



A noter : afin d’identifier d’éventuels changements de la couverture AMC, de nouveaux appels au processus annuaire service IDB peuvent être lancés de façon automatique par le système à J-X jours et le jour de l’admission prévisionnelle, à partir de minuit (cf. chapitre 8 – traitement batch).



Le système a déclenché automatiquement l’appel du processus annuaire service IDB à J-X.

Le système a déclenché automatiquement l’appel du processus annuaire service IDB à J, à partir de minuit.

6.1.6.2 Successeurs

Si le service IDB retourne une réponse OK et un reste à charge possible ou si la venue comporte des prestations hors soins, le système procède à l’appel du processus annuaire service SIM (cas nominal).

Si le service IDB retourne une réponse OK et une absence de reste à charge et si la venue ne comporte pas de prestation hors soins, le système bascule vers la gestion de l’indicateur STATUT_RAC (cas alternatif).

Si le service IDB retourne une réponse KO, le système bascule vers la gestion de l’indicateur STATUT_RAC (cas alternatif).

6.1.7 Appel processus annuaire service SIM Cette étape permet, si le service IDB indique un reste à charge possible ou que le patient a demandé une prestation hors soins, d’appeler le processus annuaire service SIM et ainsi d’informer le patient sur le montant prévisionnel du reste à charge. Cette étape est décrite plus en détail dans le chapitre 7.


L’établissement : o a procédé à l’appel du processus annuaire service IDB et

a réceptionné une réponse OK de l’IDB et une information d’un reste à charge potentiel ou

o prévoit l’existence de prestations hors soins dans la venue.

6.1.7.2 Successeur

Le système bascule vers la gestion de l’indicateur STATUT_RAC (cas nominal).

6.1.8 Gestion de l’indicateur STATUT_RAC Cette étape permet de gérer l’information relative au reste à charge du patient (reste à charge possible ou absence de reste à charge). Cette étape est décrite plus en détail dans le chapitre 4.


Le système a appelé le processus annuaire service IDB qui lui a retourné une réponse OK et une information d’absence de reste à charge et il n’existe pas de prestations hors soins dans la venue.

Le système a appelé le processus annuaire service IDB qui lui a retourné une réponse KO.



Le système a appelé le processus annuaire service SIM.

6.1.8.2 Successeur

Les données du suivi opérationnel du STATUT_RAC sont actualisées (cas nominal).

6.1.9 Suivi opérationnel du STATUT_RAC Cette étape permet à l’établissement d’informer le patient de l’existence possible d’un reste à charge quand cela est utile. Au stade de préadmission, chaque établissement doit définir dans quels cas il est opportun d’informer / solliciter le patient, sachant que les informations transmises par le service IDB avant le jour de la venue sont informatives, puisque la situation de couverture AMC peut changer jusqu’à l’admission. Cette étape est décrite plus en détail dans le chapitre 4.


Le système a mis à jour l’indicateur STATUT_RAC en fonction des retours du service IDB ou SIM.

6.1.9.2 Successeurs

Si le patient donne son accord à la simulation effectuée, le processus prend fin (cas nominal).

Si le patient demande à modifier les informations relatives à la venue (ex : refus d’une prestation hors soins), le système procède au complément de la venue et à la collecte des données AMO/AMC (cas alternatif).

6.1.10 Recueil du consentement du patient Cette étape permet à l’établissement de recueillir le consentement du patient, quand celui-ci souhaite bénéficier de prestations hors soins (chambre particulière notamment).


L’établissement a procédé au suivi opérationnel de la venue.


Si le patient donne son accord, le processus prend fin (cas nominal).

Si le patient demande une modification des prestations hors soins, le système déclenche un nouvel appel au processus annuaire service SIM (cas alternatif).

6.2 En admission Séjours

L’admission correspond à l’arrivée dans l’établissement du patient. Le patient peut être admis suite à une préadmission mais également directement, sans préadmission. L’objectif de cette phase est de récupérer et de valider l’ensemble des données nécessaires à la gestion du dossier administratif du patient (identité, droits AMO/AMC…). Le service IDB apporte une réelle évolution aux établissements de santé, en phase d’admission, pour les données relatives aux droits AMC, en assurant, le jour de la



venue, l'existence d'une couverture par l'AMC, contrairement au dispositif actuel qui s’appuie sur une présomption de couverture. Le service SIM permet quant à lui d’estimer le reste à charge du patient et ainsi de lui faire valider les prestations hors soins souhaitées. Cette phase d’admission doit être adaptée à la situation administrative du patient. Ainsi, si les données relatives à sa venue ont été collectées en amont, lors de la phase de préadmission, l’établissement peut proposer des systèmes d’admission innovants s’appuyant notamment sur une borne d’accueil ou sur une application terminaux mobiles afin d’orienter les patients en fonction de la complétude des données à l’admission tout en veillant à la bonne réalisation des contrôles d’identito-vigilance.

La borne d’accueil peut utiliser les données telles que la carte vitale, un identifiant de préadmission, un code barre, la carte AMC du patient, un datamatrix AMC (cf. http://www.complementairesante.fr/Contenu/Attestation-TP/Telechargements) pour identifier le patient. La phase d’admission en hospitalisation étant très proche de celle décrite dans le processus fonctionnel ACE, les étapes communes ne sont pas détaillées dans ce chapitre et renvoient vers le chapitre précédent. La principale différence avec le processus fonctionnel ACE consiste en l’appel du processus annuaire service SIM en hospitalisation.

http://www.complementairesante.fr/Contenu/Attestation-TP/Telechargements



Figure 15: Admission dans le contexte Séjours



6.2.1 L’identification du patient Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.2 Création / Validation de l’identité Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.3 L’identification de la venue concernée Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.4 La création de la venue Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.5 La réalisation du mouvement d’entrée Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.6 Le complément venue et la collecte des données AMO/AMC Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.7 La gestion de l’indicateur STATUT_AMC. Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche dans ce chapitre 6.

6.2.8 La demande de prise en charge Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche dans ce chapitre 6.

6.2.9 Le suivi opérationnel du statut AMC : l’information au patient sur la non complétude de la venue

Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.2.10 L’appel au processus annuaire service IDB Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche au chapitre 5.

6.2.11 L’appel au processus annuaire service SIM Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche dans ce chapitre 6.

6.2.12 La gestion de l’indicateur STATUT_RAC Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche dans ce chapitre 6.

6.2.13 Le suivi opérationnel du statut RAC Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche dans ce chapitre 6.



6.2.14 Le recueil du consentement du patient Cette étape est similaire à celle observée dans le processus fonctionnel préadmission Séjours. Se référer à la description de cette tâche dans ce chapitre 6.

6.3 Lors de la venue

Cette phase correspond au processus mis en œuvre lorsqu’un événement intervient en cours de séjour. Il peut s’agir :

de mutation impliquant un changement de TJP ;

d’une modification de la durée du séjour modifiant la date de sortie prévisionnelle ;

de demande de prestations hors soins (chambre particulière…) ;

d’un accord d’exonération modifiant la couverture AMC. L’objectif de cette phase est d’évaluer l’impact de ces modifications sur la prise en charge par l’AMC et donc d’informer le patient de tout changement sur son éventuel reste à charge. Le système doit ainsi, lorsqu’une modification de cette nature intervient, relancer automatiquement les web services de ROC associés à la phase de prise en charge du patient correspondante.



Figure 16: Evénement en cours de séjours dans le contexte Séjours



6.3.1 Saisie des prestations hors soins Cette étape permet de reporter dans le système les demandes du patient relatives à des prestations hors soins. Ce cas se produit lorsque le patient fait ou modifie en cours de séjours une demande de prestation hors soins (chambre particulière…). Le système doit alors permettre de simuler la demande du patient afin de lui fournir une information sur l’évolution de son reste à charge afin que celui-ci donne son consentement. Tant que la prestation n’est pas acceptée, elle ne modifie pas la venue afin d’éviter les messages d’interfaces vers les autres applications du SIH.


Le patient a formulé une demande de prestation hors soins.

6.3.1.2 Successeur

Le système appelle le processus annuaire service SIM (cas nominal).

6.3.2 Mutation (avec changement de TJP) Cette étape permet de reporter dans le système tout changement dans le TJP. Le changement de TJP peut intervenir lors d’une mutation dans une unité dont la DMT est différente. Le système doit alors permettre de simuler l’impact du changement de TJP afin de fournir au patient une information sur l’évolution de son reste à charge.


Le TJP a été modifié.

6.3.2.2 Successeur


6.3.3 Mise à jour du dossier administratif – Changement d’exonération du ticket modérateur

Cette étape permet de reporter dans le système tout changement d’exonération du ticket modérateur. Une exonération du ticket modérateur peut notamment intervenir suite :

à l’ajout / la suppression d’une exonération de type « ALD », « invalidité », « grossesse »… dans le dossier, suite à des informations obtenues auprès de l’AMO ;

à l’ajout / la suppression d’un acte coûteux au cours du séjour ;

de la décision médicale d’indiquer le séjour comme « en rapport avec une exonération ALD ».

Le système doit alors permettre de simuler l’impact du changement d’exonération afin de fournir au patient une information sur l’évolution de son reste à charge.


L’exonération du ticket modérateur a été modifiée.

6.3.3.2 Successeur




6.3.4 Saisie de la nouvelle date prévisionnelle de sortie Cette étape permet de reporter dans le système toute modification de la durée du séjour. Le système doit alors permettre de simuler l’impact de la modification de la durée du séjour afin de fournir au patient une information sur l’évolution de son reste à charge.


La date de sortie du séjour a été modifiée.

6.3.4.2 Successeur


6.3.5 Appel processus annuaire service SIM Cette étape permet d’appeler le processus annuaire service SIM et ainsi d’estimer l’impact des évolutions précédemment citées sur le reste à charge du patient. Cette étape est décrite plus en détail dans le chapitre 7.


La prestation hors soins complémentaire demandée par le patient a été saisie.

La mutation impliquant un changement de TJP a été réalisée.

Le dossier administratif a été mis à jour avec le changement d’exonération du ticket modérateur.

La nouvelle date prévisionnelle de sortie a été saisie dans le système.

6.3.5.2 Successeur


6.3.6 Gestion de l’indicateur STATUT_RAC Cette étape permet de mettre à jour l’indicateur STATUT_RAC suite à l’appel du service SIM.


Le système a appelé le processus annuaire service SIM et a détecté une évolution du reste à charge patient.

6.3.6.2 Successeur


6.3.7 Suivi opérationnel du STATUT_RAC : document d’information au patient Cette étape permet de produire le document d’information à destination du patient3. En effet, suite à l’évaluation du reste à charge par le processus service SIM, l’établissement doit informer le patient s’il y a un changement sur le reste à charge patient par rapport à l’information précédente. En particulier, quand la modification concerne l’ajout d’une prestation hors soins, l’établissement doit recueillir le consentement du patient.






6.3.7.2 Successeur

La venue est mise à jour et les nouvelles données SIM sont enregistrées (cas nominal).

6.3.8 Mise à jour de la venue / Stockage SIM Cette étape permet l’enregistrement par le système des données de simulation et des nouvelles données, après avoir remis l’information au patient (et avoir obtenu son consentement dans le cas de l’ajout d’une prestation hors soins).


Le système a procédé au suivi opérationnel et a produit le document d’information à destination du patient (et obtenu le consentement dans le cas de l’ajout d’une prestation hors soins).

6.4 Lors de la venue – Cas particulier d’une modification de l’AMC en cours de séjour

Cette phase correspond au processus mis en œuvre lorsque le patient présente une nouvelle attestation de tiers payant AMC en cours de séjour. Soit elle s’applique à l’ensemble du séjour, soit uniquement à partir d’une date durant le séjour. Il est alors nécessaire de rappeler les services IDB et SIM avec les nouvelles informations. L’objectif de cette phase est d’évaluer l’impact de ce changement sur la prise en charge par l’AMC et donc d’informer le patient de toute évolution de son éventuel reste à charge. L’identification de la fin de validité de l’AMC précédente (notamment à l’aide des listes de travail détaillées dans le chapitre 4) permet d’anticiper cet événement et de permettre au patient de présenter sa nouvelle attestation de tiers payant AMC. Il s’agit de créer une nouvelle couverture pour la venue en appliquant les règles suivantes :

Si les périodes de couverture des deux AMC se chevauchent, on utilisera l’AMC précédente jusqu’à sa date de fin de validité. La nouvelle AMC sera utilisée à partir du jour suivant.

Si les périodes de couvertures des deux AMC ne se chevauchent pas, on utilisera l’AMC précédente jusqu’à sa date de fin de validité. La nouvelle AMC sera utilisée à partir de sa propre date de début de validité. Il peut donc y avoir une période non couverte entre les deux AMC.



Figure 17: Modification de l’AMC en cours de séjour dans le contexte Séjours



6.4.1 Complément du dossier administratif Cette étape permet de compléter le dossier administratif avec les données de la nouvelle attestation de tiers payant AMC fournie.


Le patient a fourni une nouvelle attestation de tiers payant AMC.

6.4.1.2 Successeur

Le système procède à l’appel du processus annuaire service IDB (cas nominal).

6.4.2 Appel processus annuaire service IDB Cette étape permet de d’appeler l’annuaire service IDB pour la nouvelle attestation de tiers payant AMC. Le numéro d’occurrence est changé (conformément aux dispositions du cahier des charges HospiAMC). Cette étape est décrite plus en détail dans le chapitre 7.


Le dossier administratif du patient a été complété en intégrant la nouvelle AMC.

6.4.2.2 Successeur

Le système procède à l’appel du processus annuaire service SIM (cas nominal).

6.4.3 Appel au processus annuaire service SIM Cette étape permet d’appeler le processus annuaire service SIM et ainsi d’estimer l’impact de la nouvelle AMC sur le reste à charge du patient. Cette étape est décrite plus en détail dans le chapitre 7.


Le système a procédé à l’appel du processus annuaire service IDB.

6.4.3.2 Successeur


6.4.4 Gestion de l’indicateur STATUT_RAC Cette étape permet de mettre à jour l’indicateur STATUT_RAC sur la base des informations récoltées. Cette étape est décrite plus en détail dans le chapitre 4.


Le système a procédé à l’appel du service SIM.

6.4.4.2 Successeurs




6.4.5 Le suivi opérationnel de la venue : information du patient Cette étape permet d’informer le patient d’une évolution de son reste à charge. Le document d’information à destination du patient est alors produit4.



6.4.5.2 Successeurs

Si le patient ne demande aucune modification (prestations hors soins) de son séjour suite au changement d’AMC, le processus prend fin (cas nominal).

Si le patient demande une modification suite au changement d’AMC (exemple : choix d’abandonner une prestation hors soins qui ne serait plus couverte par la nouvelle AMC), la venue est complétée.

6.5 En facturation Séjours

La phase de facturation correspond à l’analyse des prestations et des couvertures, pour facturation et émission des factures-tiers vers les différents débiteurs. Cette phase a pour objectif de facturer les différents débiteurs associés à la venue, en s’assurant de l’exhaustivité et de la qualité de la facture-tiers pour sécuriser les recettes de l’établissement. Cette phase a aussi pour objectif, quand cela est possible, de facturer le patient lors de sa présence dans l’établissement, pour sécuriser le recouvrement des restes à charge patient. Le service CLC répond à ces objectifs en calculant le reste à charge, ce qui permet de facturer le patient avant la sortie de l’établissement et en garantissant la qualité de la facture-tiers produite pour l’AMC, qui s’engage alors à la régler. Contrairement au processus fonctionnel ACE, la facturation à l’AMC ne nécessite pas d’attendre un retour de l’AMO puisque les bases de calcul des prestations AMO et AMC sont différentes.




Figure 18: Facturation dans le contexte Séjours



6.5.1 Collecte des données de facturation. Cette étape permet de collecter les données nécessaires à la facturation de la part AMC ou patient. Cette collecte se fait à deux niveaux :

La collecte des données relatives au ticket modérateur. Il s’agit notamment de l’interrogation du processus continu de collecte de l’ensemble des éléments de la venue qui participent à l’instruction d’une éventuelle exonération du ticket modérateur.

La collecte des données relatives à d’éventuelles prestations hors soins. A noter que dans le cas d’une impossibilité de recueillir les prestations de type « soins » avant la sortie du patient, une facture-tiers pour les prestations hors soins peut néanmoins être émise à la sortie du patient. Dans ce cas, une autre facture-tiers AMC, relative aux prestations de soins sera émise dès la collecte réalisée.


L’établissement démarre son processus de facturation.

6.5.1.2 Successeur

Le système analyse chaque couverture (cas nominal).

6.5.2 Analyse de chaque couverture Cette étape permet de collecter l’ensemble des informations nécessaires à la validation de la facture.


Le système a collecté les données nécessaires à la facturation.

6.5.2.2 Successeurs

S’il n’y a pas de part AMC ou Patient (exonération TM et FJ et pas de prestations hors soins), le système procède à l’appel du processus annuaire service SIM (cas nominal).

S’il y a une part AMC ou Patient (si TM et/ou FJ et/ou des prestations hors soins), le système procède à l’appel du processus annuaire service CLC (cas alternatif).

6.5.3 Appel annuaire service SIM Cette étape permet de valider l’absence d’une facturation AMC ou patient dans le contexte de sortie. Cette étape est décrite plus en détail dans le chapitre 7.


Le système a analysé les couvertures et identifié une exonération de TM et FJ et l’absence de prestations hors soins.

6.5.3.2 Successeur


6.5.4 Gestion de l’indicateur STATUT_RAC Cette étape permet mettre à jour l’indicateur STATUT_RAC à PAS_RAC, suite à l’appel du service SIM.




Le système a appelé le processus annuaire service SIM et a confirmé l’absence de RAC.

6.5.4.2 Successeur

Les données du suivi opérationnel du STATUT_RAC sont actualisées.

6.5.5 Suivi opérationnel du STATUT_RAC : information patient Cette étape permet d’informer le patient de sa couverture.



6.5.6 Appel du service annuaire CLC Cette étape permet d’appeler le service CLC afin de calculer la part AMC et/ou la part Patient, dans le cas où il y a au moins une prestation hors soins, un TM ou un FJ. Cette étape est décrite plus en détail dans le chapitre 7.


Le système a analysé les couvertures et identifié un TM et/ou un FJ et/ou la présence de prestations hors soins.

6.5.6.2 Successeur


6.5.7 Gestion de l’indicateur STATUT_RAC Cette étape permet mettre à jour l’indicateur STATUT_RAC, suite à l’appel du service CLC. Si le service CLC détecte un reste à charge, l’indicateur STATUT_RAC reste à RAC. S’il ne détecte pas de reste à charge, l’indicateur STATUT_RAC passe à PAS_RAC.


Le système a appelé le service CLC.

6.5.7.2 Successeur

La facture-tiers AMC et / ou patient sont validées.

6.5.8 Validation de la facture-tiers patient Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.5.9 Emission de la facture-tiers patient Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.5.10 Demande d’encaissement au patient Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.



6.5.11 Validation de la facture-tiers AMC Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.

6.5.12 Emission de la facture-tiers AMC (DRE-ES) Cette étape est similaire à celle observée dans le processus fonctionnel ACE si ce n’est que l’émission de la facture-tiers AMC peut se faire indépendamment du retour de l’AMO. Se référer à la description de cette tâche au chapitre 5.

6.5.13 Réception des retours AMC Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5..

6.5.14 Retraitement de la venue Cette étape est similaire à celle observée dans le processus fonctionnel ACE. Se référer à la description de cette tâche au chapitre 5.


Processus communs 72/103

7 Processus communs

7.1 Appel processus annuaire (service annuaire AMC et cache des adresses)

Avant chaque appel aux services web, il faut réaliser, à partir des données issues de l’attestation de tiers payant AMC, un appel au processus annuaire pour identifier l’adresse du service AMC souhaité. Cet appel doit être renouvelé à chaque demande. L’appel au service annuaire ne peut pas être parallélisé pour un même demandeur (établissement). Le service annuaire est disponible 24h/24 et 7j/7. Afin de gagner du temps et/ou de paralléliser les appels sur des adresses distinctes, notamment sur les phases de traitement batch, le système peut vérifier dans son cache d’adresse si le service n’est pas déjà connu pour les paramètres AMC fournis. Le cache adresse des services AMC contient un couple clé / adresse du service concerné. La clé est constituée du numéro de l’AMC, du code type convention, du code CSR et du service AMC. Les données ne sont pas stockées si le service retourne plusieurs AMC. Le code CSR et le type de convention peuvent être vides.

Exemple :

Clé Valeur

Numéro AMC Type convention

Code CSR Service Adresse

123456789 XY 001 IDB HTTPS://adresse1

213243232 IDB HTTPS://adresse2

Le processus annuaire ne peut être appelé qu’à partir du moment où les données AMC ont été recueillies et que l’AMC a été identifiée comme appartenant au dispositif ROC. L’indicateur STATUT_AMC est donc positionné à AMC_ROC lors du lancement du processus annuaire.

https://adresse/



Figure 19: Processus annuaire



7.1.1 Recherche de l’adresse du service AMC dans le cache Cette étape permet de déterminer si l’adresse du service AMC souhaité est déjà connue, ce qui permet, le cas échéant, de contacter directement le service.


Le système a identifié que l’AMC faisait partie de la liste ROC : l’indicateur STATUT_AMC est positionné à AMC_ROC.

7.1.1.2 Successeur

Si le système trouve l’adresse du service AMC dans le cache, il procède directement à l’appel du service AMC (cas nominal).

Si le système n’a pas trouvé l’adresse du service AMC dans le cache, il procède à l’appel de l’annuaire AMC pour trouver l’adresse du service (cas alternatif).

7.1.2 Appel du processus annuaire AMC Cette étape permet d’appeler le processus annuaire.


L’interrogation du cache a indiqué que l’adresse du service AMC n’est pas connue.

L’appel du service à partir de l’adresse stockée dans le cache n’a pu être réalisé (adresse obsolète).

7.1.2.2 Successeurs Lorsqu’on appelle le service annuaire AMC, plusieurs cas peuvent se produire :

Le service répond par l’adresse du service AMC (Cas nominal) Il s’agit du cas nominal, le service AMC a été trouvé, l’adresse du service est enregistrée dans le système pour l’appel du service AMC. Il peut également être stocké dans le cache des adresses pour les appels suivants. A noter : Si le service identifie plusieurs adresses AMC, c’est que les informations fournies lors de l’appel ne sont pas exhaustives. Le service retourne alors au maximum 6 adresses. Toutes les adresses seront testées dans la suite du processus.

Le service ne trouve pas d’adresse du service AMC (cas alternatif) o Le service trouve plus de 6 adresses.

Il est dans ce cas nécessaire de préciser les critères AMC afin de pouvoir identifier précisément le service. Ce cas alimente la liste des erreurs. Comme indiqué précédemment, une répartition des erreurs par famille de rejets – ici fonctionnelle ou technique – est proposée à titre informatif dans ce document mais doit pouvoir être ajustée par l’établissement.

o Le service ne trouve pas l’adresse. Si le service n’identifie pas l’adresse du service AMC, une erreur (fonctionnelle ou technique, comme précisé ci-dessus) doit être retournée par le système afin que les informations soient contrôlées. Le système peut alors prévoir de réessayer avec moins de paramètres en entrée (ex: sans type de convention (TypConv), et critère secondaire de routage (CSR)).

o Le service ne répond pas.



Si le service n’est pas joignable au moment de l’appel, il s’agit alors d’un timeout du service. Le système doit alors réessayer jusqu’à réponse du service. Le délai de réémission sera paramétrable dans le système, la préconisation est de réessayer toutes les minutes pendant cinq minutes puis toutes les heures jusqu’à l’obtention d’une réponse.

A noter : les données en entrée et sortie de l’appel annuaire sont détaillées dans le document « Annuaire AMC – Guide d’utilisation du web service par les éditeurs » du corpus documentaire ROC.

7.1.3 Appel du service AMC (IDB/SIM/CLC) Cette étape permet de contacter le service AMC souhaité. Pour chaque adresse retournée par le service annuaire AMC, le système fait appel au service AMC avec les données attendues (cf. processus IDB, SIM, …). A noter : si l’annuaire a retourné plus d’une adresse et moins de 6, chacune de ces adresses est testée successivement, jusqu’à obtenir une réponse OK du service appelé. Cette réponse OK signifie que le service a pu être appelé et que le bénéficiaire a été reconnu.


Le système a récupéré l’adresse du service stockée dans le cache.

Le système a procédé à l’appel annuaire qui lui a fourni en réponse l’adresse du service.

7.1.3.2 Successeurs

Si le service AMC répond par un OK, le système stocke l’adresse du service dans le cache (cas nominal).

Si le système utilise un cache, il est possible que l’adresse contenue dans le cache soit obsolète. Une nouvelle demande d’adressage doit être réalisée afin de s’assurer que l’adresse du service contenue dans le cache est correcte. L’appel est alors réémis.

Si le service n’est pas joignable au moment de l’appel, il s’agit alors d’un timeout du service. Le système doit alors réessayer jusqu’à réponse du service. Le délai de réémission sera paramétrable dans le système, la préconisation est de réessayer toutes les minutes pendant cinq minutes puis toutes les heures jusqu’à l’obtention d’une réponse.

7.1.4 Stockage de l’adresse du service AMC dans le cache. Cette étape permet de stocker le couple clé / adresse du service dans le cache pour les appels suivants, lorsque le service AMC a retourné un code retour OK. La clé d’identification dans le cache ne doit pas être partielle, elle doit être créée à partir des 3 paramètres (Numéro AMC, Type convention et Code CSR) issus du retour du service annuaire et non à partir de la requête de recherche car celle-ci peut être réalisée avec un seul critère.


L’appel au service AMC a retourné un OK.



7.1.5 Gestion des erreurs annuaire (fonctionnelles et techniques) Dans le cas où le service AMC retourne un code erreur, la gestion des erreurs permet de classifier les erreurs suivant la valeur du code et d’alimenter des listes de travail. Trois familles de rejets ont été identifiées : une proposition de répartition des rejets dans ces trois familles est proposée dans ce document, à titre informatif. Le système doit permettre à l’établissement de définir sa propre répartition des rejets dans les trois familles ci-dessous, ainsi que les actions correctives associées à ces rejets.

Couvertures en erreur fonctionnelle : codes retours classifiés comme erreur fonctionnelle sur lesquels l’établissement pourra intervenir.

Couvertures en erreur technique : codes retours classifiés comme erreur technique sur lesquelles seul un administrateur ou l’éditeur pourra intervenir.

Couvertures en information patient : ce sont les couvertures pour lesquels une information du patient est nécessaire.

Dans le cas du service Annuaire, la famille de rejet information patient ne sera probablement pas utilisée.

7.1.6 Exigences relatives au service Annuaire Les exigences relatives à ce service sont détaillées dans le cahier des charges « HospiAMC ».

7.2 Processus IDB

L’IDB est le service qui permet d’identifier les droits du bénéficiaire. Ce processus décrit l’enchainement d’appels du service annuaire AMC et du service IDB (Information Droit du Bénéficiaire) dans les différents cas rencontrés pour une venue en consultation ou d’hospitalisation.



Figure 20: Processus annuaire service IDB



7.2.1 L’appel du service IDB Cette étape permet d’appeler le service IDB, une fois l’adresse du service obtenue. Le service IDB permet de s’assurer que le patient est bien connu de l’AMC le jour de la demande et d’obtenir des informations sur la validité de la couverture du patient. Le service IDB peut être appelé dans différents contextes d’échanges qui doivent être respectés :

Le patient n’est pas encore arrivé dans l’établissement : le service IDB peut être appelé dans le contexte «1 : préadmission ». Le service IDB dans ce contexte peut être appelé plusieurs fois avant l’arrivée du patient.

Le patient est présent dans l’établissement, son mouvement d’entrée a été réalisé, il est donc admis. Le service IDB doit être appelé dans le contexte «2 : admission ».

Le patient est déjà dans l’établissement, un événement se produit sur la venue et nécessite l’exécution du service IDB. Le service IDB est appelé dans le contexte «3 : en cours de séjour »

Le service IDB est disponible suivant les heures définies dans l’accord-cadre, le système doit donc être en mesure de gérer les plages horaires d’ouverture du service afin de ne pas faire d’appel en dehors des heures définies. Un numéro de demande unique doit être associé à chaque appel IDB. Celui-ci doit être géré par le système appelant. Par défaut, avant appel de l’IDB, on considère que le patient a un reste à charge possible. Par conséquent, avant l’appel de l’IDB, l’indicateur STATUT_RAC est positionné à RAC.


Le service annuaire AMC ou le cache ont fourni l’adresse du service IDB. Cette étape est décrite plus en détail dans le chapitre 7.

7.2.1.2 Successeurs

Si le service IDB répond par OK et pas de reste à charge, le système met à jour l’indicateur STATUT_RAC à PAS_RAC (cas nominal).

Si le service IDB répond par OK et reste à charge possible, le système conserve l’indicateur STATUT_RAC à RAC (cas alternatif).

Si le service IDB répond par KO, le système conserve l’indicateur STATUT_RAC à RAC (cas alternatif).

7.2.2 La mise à jour de l’indicateur STATUT_RAC à PAS_RAC Cette étape permet de faire évoluer l’indicateur STATUT_RAC à PAS_RAC suite à la réponse fournie par l’IDB.


Le service IDB a répondu par OK et pas de reste à charge.

7.2.2.2 Successeurs

Le système stocke la réponse de l’IDB (cas nominal).



7.2.3 La conservation de l’indicateur STATUT_RAC à RAC Cette étape permet de conserver l’indicateur STATUT_RAC à RAC suite à la réponse fournie par l’IDB.


Le service IDB a répondu par OK et reste à charge possible.

7.2.3.2 Successeurs

Le système stocke la réponse de l’IDB (cas nominal).

7.2.4 La conservation de l’indicateur STATUT_RAC à RAC Cette étape permet de conserver l’indicateur STATUT_RAC à RAC suite à la réponse fournie par l’IDB.


Le service IDB a répondu par KO.

7.2.4.2 Successeurs

Si le KO est de type 0001, 0006, 0011, 0012, 0031 ou 0035, le système alimente la liste des erreurs fonctionnelles.

Si le KO est du type 0018, 1001, 1002, 2031, 0101, 0102, 0103, 0104, 0105, 0106, 0107 ou si le service répond par une erreur http 500, le système alimente la liste des erreurs techniques.

Si le KO est de type 0004, 0005 ou 0022, le système alimente la liste des informations patients.

A noter : comme indiqué précédemment, une proposition de répartition des rejets dans ces trois familles est ici proposée, à titre informatif. Le système doit permettre à l’établissement de définir sa propre répartition des rejets dans les trois familles ci-dessus, ainsi que les actions correctives associées à ces rejets.

7.2.5 Le stockage des données IDB Cette étape permet de stocker les données IDB. Ces données d’appel et de réponse du service IDB sont stockées et horodatées dans le système car elles serviront pour l’appel des services suivants (SIM, CLC, IDB). En effet, si le service IDB retourne des informations d’adressage des services SIM/CLC, ces données devront alors être utilisées dans la suite du processus.


Le service IDB a répondu par OK.

7.2.6 L’alimentation de la liste erreurs fonctionnelles Cette étape permet de placer la couverture de la venue dans la liste des erreurs fonctionnelles suite à une réponse KO du service annuaire ou du service IDB, pour les codes ci-dessous (répartition donnée à titre informatif). Cette liste fera l’objet d’un traitement manuel ou semi automatique par la suite. (cf. chapitre 4 – suivi opérationnel).

Code Libellé Description

0001 Pas de prise en charge RO

La prise en charge est conditionnée à la présence d'un remboursement RO pour la prestation

0006 Autre circuit de tiers Le bénéficiaire est bien reconnu mais le circuit de tiers



payant payant utilisé n'est pas le bon

0011 Autre Le motif de refus n'est pas référencé ; le message précise en clair le motif de refus

0012 Bénéficiaire inconnu L'AMC ne connait pas ce bénéficiaire

0031 N° Adhérent absent Le n° d'adhérent ne figure pas dans la demande et celui-ci est indispensable à l'AMC pour identifier le bénéficiaire

0035 Demande hors délai La demande est effectuée en dehors du délai défini par le contrat-cadre pour les préadmissions, les demandes effectuées a posteriori, ou le calcul.

A noter : le code 0012 peut intervenir dans le contexte où l’annuaire a retourné plusieurs adresses (maximum 6). Dans ce cas, ce code ne doit pas alimenter la liste d’erreurs fonctionnelles tant que les appels successifs sur les différentes adresses n’ont pas été réalisés.


Le service IDB a répondu par un KO du type 0001, 006, 0011, 0012, 0031ou 0035.

7.2.7 L’alimentation de la liste erreurs techniques Cette étape permet de placer la couverture de la venue dans la liste des erreurs techniques suite à une réponse KO de l’IDB, pour les codes ci-dessous (répartition donnée à titre informatif). Cette liste fera l’objet d’un traitement manuel par les services informatiques et les éditeurs par la suite.


0018 Donnée incorrecte le système applicatif a détecté une donnée incorrecte ne permettant pas de finaliser l'échange

1001 Erreur technique (PS) Dysfonctionnement détecté dans la transaction envoyée par le PS

1002 Erreur technique ((AMC/OTP)

Dysfonctionnement du service de traitement de la transaction SEL par l'AMC-OTP

2031 Donnée manquante Les informations fournies par le PS sont insuffisantes ou erronées pour permettre le traitement du dossier

0101 Problème de sécurité Jeton Absent

0102 Problème de sécurité Jeton Erreur Certificat

0103 Problème de sécurité Jeton Certificat Revoqué

0104 Problème de sécurité Jeton Methode Erreur



0105 Problème de sécurité Jeton Obsolete

0106 Problème de sécurité Jeton Signature Invalide

0107 Service temporairement inaccessible.

Maintenance

A noter : une erreur HTTP 404 peut intervenir dans le contexte où l’adresse utilisée pour appeler le service est issue du cache et s’avère obsolète. Dans ce cas, ce code ne doit pas alimenter la liste d’erreurs fonctionnelles tant que l’annuaire n’a pas été appelé pour contrôler l’adresse du service.


Le service IDB a répondu par un KO du type 0018, 1001, 1002, 2031, 0101, 0102, 0103, 0104, 0105, 0106, 0107 ou par une erreur HTTP 404.

7.2.8 L’alimentation de la liste informations patients Cette étape permet de placer la couverture de la venue dans la liste des informations patients suite à une réponse KO de l’IDB, pour les codes ci-dessous (répartition donnée à titre informatif). Cette liste comprend les couvertures dont le statut du service IDB est une information de non couverture. Cette liste pourra faire l’objet d’un traitement manuel par la suite si le statut de la couverture n’est pas justifié.

Code Libelle Description

0004 Droits non ouverts

Le bénéficiaire est bien identifié mais n'a pas de droits ouverts

0005 Pas de tiers payant

Prestation non soumise à tiers payant

0022 Le bénéficiaire doit contacter l'AMC

un problème sur le contrat du bénéficiaire, de nature confidentielle, ne permet pas de le mettre en œuvre immédiatement


Le service IDB a répondu par un KO du type 0004, 0005 ou 0022.

7.2.9 Les exigences relatives au service IDB Les exigences relatives à ce service sont détaillées dans le cahier des charges « HospiAMC ».

7.2.10 Les données en entrée nécessaires à l’appel du service IDB Le tableau ci-dessous permet d’identifier les données importantes de l’appel du service IDB. Toutefois elles ne constituent pas l’exhaustivité des données qui sont décrites dans le WSDL. C : Conditionnel dépend du contexte R : Requis O : Optionnel



Type Dossier

Consultation Hospitalisation

Préadmission Admission Préadmission Admission Echéance Renouvellement

Changement AMC Changement d’exercice

Statut Précision Statut Précision Statut Précision Statut Précision Statut Précision Statut Précision Statut Précision

Emetteur R R R R R R R

Date d’admission

R Date prévisionnelle des soins)

R Date des soins

R Date d’admission prévisionnelle)

R Date d’admission




Date de début de prestation

R Date prévisionnelle des soins)

R Date des soins

R Date d’admission prévisionnelle



R Date de fin de contrat de AMC précédente + 1


Date de fin de prestation

R Date de sortie prévisionnelle





N° AMC R R R R R R R

Type convention

O O O O O O O

Critère secondaire de routage

O O O O O O O

Domaine conventionnel

EXTE HOSP

Service IDB

Code norme DROITAMC

Indication parcours de soins

R R

Médecin traitant

R R



Type Dossier

Consultation Hospitalisation

Préadmission Admission Préadmission Admission Echéance Renouvellement

Changement AMC Changement d’exercice

Statut Précision Statut Précision Statut Précision Statut Précision Statut Précision Statut Précision Statut Précision

DMT R DMT prévisionnelle

R DMT de l’admission




Contexte d’échange

R 1 R 2 R 1 R 2 R 3 3 R 3

Identifiant période de facturation

R R R Ne change pas

R R

Numéro d’occurrence

R R Incrémenter le numéro d’occurence

R Incrémenter le numéro d’occurence

R



7.3 Processus SIM

Le SIM est le service qui permet de simuler le reste à charge. Ce processus décrit l’enchainement d’appel du service SIM (simulation) lorsqu’il y a un reste à charge ou une prestation hors soins demandée par le patient. Ce service est appelé uniquement dans le cas d’une hospitalisation. L’appel au service SIM impose d’avoir au préalable effectué un appel au service IDB. De même que pour le service IDB, le service SIM nécessite qu’une date d’entrée et de sortie soit renseignée (que cette date soit une date prévisionnelle ou réelle). Le service SIM peut être appelé en phase de préadmission hospitalisation, d’admission hospitalisation, en cours de séjour ou en sortie. Le résultat de l’appel au service SIM ne constitue pas une garantie de couverture de l’AMC.



Figure 21: Processus annuaire service SIM



7.3.1 Appel au service SIM Cette étape permet d’appeler le service SIM, une fois l’adresse du service obtenue. Le service SIM peut être appelé dans différents contextes d’échanges qui doivent être respectés :

Le patient n’est pas encore hospitalisé dans l’établissement : le service SIM peut être appelé dans le contexte «1 : préadmission ». Le service SIM dans ce contexte peut être appelé plusieurs fois avant l’arrivée du patient.

Le patient est présent dans l’établissement, son mouvement d’entrée a été réalisé, il est donc admis. Le service SIM doit être appelé dans le contexte «2 : admission ».

Le patient est déjà hospitalisé dans l’établissement, un événement se produit sur la venue et nécessite l’exécution du service SIM. Le service SIM est appelé dans le contexte «3 : en cours de séjour »

Dans le cas où la sortie du patient ne génère pas un échange CLC, un échange SIM permet alors à l’ETS d’informer l’AMC de la sortie effective du patient. Le service SIM est appelé dans le contexte «4 : sortie » Les cas donnant lieu à un échange SIM en contexte « 4 : Sortie » sont décrits dans le cahier des charges HospiAMC.

7.3.1.1 Prédécesseurs Afin de pouvoir réaliser l’appel au service SIM, les conditions suivantes doivent être réunies :

Le service annuaire AMC ou le cache ont fourni l’adresse du service SIM. Cette étape est décrite plus en détail dans ce chapitre 7 – service Annuaire.

Il doit s’agir d’un séjour d’hospitalisation.

Le service IDB doit avoir retourné le statut OK.

Le service IDB ne doit pas indiquer une absence de reste à charge ou une prestation hors soins doit exister dans la couverture ou il s’agit d’un cas donnant lieu à un échange SIM en contexte « 4 : Sortie ».

7.3.1.2 Successeurs

Si le service SIM répond par OK et pas de reste à charge, le système met à jour l’indicateur STATUT_RAC à PAS_RAC (cas nominal).

Si le service SIM répond par OK et reste à charge possible, le système conserve l’indicateur STATUT_RAC à RAC (cas alternatif).

Si le service SIM répond par KO, le système conserve l’indicateur STATUT_RAC à RAC (cas alternatif).

7.3.2 La mise à jour de l’indicateur STATUT_RAC à PAS_RAC Cette étape permet de faire évoluer l’indicateur STATUT_RAC à PAS_RAC suite à la réponse fournie par le service SIM.


Le service SIM a répondu par OK et pas de reste à charge.

7.3.2.2 Successeurs

Le système stocke la réponse du service SIM (cas nominal).



7.3.3 La conservation de l’indicateur STATUT_RAC à RAC Cette étape permet de conserver l’indicateur STATUT_RAC à RAC suite à la réponse fournie par le service SIM. Si l’appel au service SIM renvoie un code retour OK et qu’il y a un reste à charge supérieur à 0, l’indicateur RAC reste à RAC.


Le service SIM a répondu par OK et les montants pris en charge par l’AMC retournés dans la réponse mettent en évidence un reste à charge possible.

7.3.3.2 Successeur

Le système stocke la réponse du service SIM (cas nominal).

7.3.4 La conservation de l’indicateur STATUT_RAC à RAC Cette étape permet de conserver l’indicateur STATUT_RAC à RAC suite à la réponse fournie par le service SIM. Si le service SIM répond par un code retour KO, il convient alors de traiter et de classifier l’erreur afin d’automatiser au mieux le traitement des erreurs.


Le service SIM a répondu par KO.

7.3.4.2 Successeurs


Si le KO est de type 0018, 1001, 1002, 2031, 0101, 0102, 0103, 0104, 0105, 0106, 0107 ou si le service répond par une erreur http 500 (non géré) du service SIM.

Si le KO est de type 0003, 0005, 0014, 0022, 0024 au niveau dossier ou prestation, le système alimente la liste des informations patients.

A noter : comme indiqué précédemment, une proposition de répartition des rejets dans ces trois familles est ici proposée, à titre informatif. Le système doit permettre à l’établissement de définir sa propre répartition des rejets dans les trois familles ci-dessus, ainsi que les actions correctives associées à ces rejets

7.3.5 Le stockage des données SIM Cette étape permet de stocker les données SIM.


Le service IDB a répondu par OK.

7.3.6 L’alimentation de la liste erreurs fonctionnelles Cette étape permet de placer la couverture de la venue dans la liste des erreurs fonctionnelles suite à une réponse KO du service annuaire ou du service SIM, pour les codes ci-dessous (répartition donnée à titre informatif).






0002 Pas d'ordonnance La prise en charge est conditionnée à la présence d'une prescription


0023 Convention AMC non respectée (Réseaux)

Convention métier

0035 Demande hors délai La demande est effectuée en dehors du délai défini par le contrat-cadre pour les préadmissions, les demandes effectuées à postériori, ou le calcul.

0037 Echange IDB non effectué

L'AMC reçoit un SIM ou un CLC sans IDB préalable


Le service SIM a répondu par un KO du type 0001, 0002, 0011, 0023, 0035 ou 0037.

7.3.7 L’alimentation de la liste erreurs techniques Cette étape permet de placer la couverture de la venue dans la liste des erreurs techniques suite à une réponse KO du service SIM, pour les codes ci-dessous (répartition donnée à titre informatif). Cette liste fera l’objet d’un traitement manuel par les services informatiques et les éditeurs par la suite.


0018 Donnée incorrecte

Le système applicatif a détecté une donnée incorrecte ne permettant pas de finaliser l'échange

1001 Erreur technique (PS)

Dysfonctionnement détecté dans la transaction envoyée par le PS

1002 Erreur technique (AMC/OTP)


2031 Donnée manquante

Les informations fournies par le PS sont insuffisantes ou erronées pour permettre le traitement du dossier

0101 Problème de sécurité

Jeton Absent


Jeton Erreur Certificat


Jeton Certificat Revoqué


Jeton Methode Erreur




Jeton Obsolete


Jeton Signature Invalide


Maintenance



Le service SIM a répondu par un KO du type 0018, 1001, 1002, 2031, 0101, 0102, 0103, 0104, 0105, 0106, 0107 ou si le service répond par une erreur http 500 (non géré).

7.3.8 L’alimentation de la liste informations patients Cette étape permet de placer la couverture de la venue dans la liste des informations patients suite à une réponse KO du SIM, pour les codes ci-dessous (répartition donnée à titre informatif).


0003 Forfait épuisé / plafond atteint

Le forfait ou le plafond pour cette prestation a été consommé

0005 Pas de tiers payant Prestation non soumise à tiers payant 0014 Prestation non couverte La prestation n'est pas prise en charge par le contrat

du bénéficiaire 0022 Le bénéficiaire doit

contacter l'AMC un problème sur le contrat du bénéficiaire, de nature confidentielle, ne permet pas de le mettre en œuvre immédiatement

0024 Délai de carence en cours

Le contrat présente un délai de carence ne permettant pas de prendre en charge les prestations demandées


Le service SIM a répondu par un KO du type 0003, 0005, 0014, 0022, 0024 au niveau dossier ou prestation.

7.3.9 Les exigences relatives au service SIM Les exigences relatives à ce service sont détaillées dans le cahier des charges « HospiAMC ».



7.4 Processus CLC

Le service CLC est utilisé en hospitalisation ou en ACE lorsque le calcul s’effectue en ligne. Le service CLC évalue le montant que l’AMC s’engage à prendre en charge. Un numéro d’engagement est généré en réponse à l’appel du service CLC. L’appel au service CLC doit être précédé d’un appel au service IDB. L’identifiant de période de facturation et l’occurrence générés lors de l’appel au service IDB doivent être réutilisés pour l’appel du service CLC.



Figure 22: Processus annuaire service CLC



7.4.1 Appel du service CLC Cette étape permet d’appeler le service CLC, une fois l’adresse du service obtenue. Le service CLC permet de calculer la part prise en charge par l’AMC et donc le reste à charge.

7.4.1.1 Prédécesseurs Afin de pouvoir réaliser l’appel au service CLC, les conditions suivantes doivent être réunies :

Le service annuaire AMC ou le cache ont fourni l’adresse du service CLC. Cette étape est décrite plus en détail dans ce chapitre 7 – service Annuaire.

Le service IDB doit avoir retourné une réponse OK et nécessité de procéder à un calcul en ligne, et dans le contexte « Séjours », la part AMC est supposée non nulle.

7.4.1.2 Successeurs

Si le service CLC répond par OK et pas de reste à charge, le système met à jour l’indicateur STATUT_RAC à PAS_RAC (cas nominal).

Si le service CLC répond par OK et reste à charge, le système conserve l’indicateur STATUT_RAC à RAC (cas alternatif).

Si le service CLC répond par KO, le système conserve l’indicateur STATUT_RAC à RAC (cas alternatif).

7.4.2 La mise à jour de l’indicateur STATUT_RAC à PAS_RAC Cette étape permet de faire évoluer l’indicateur STATUT_RAC à PAS_RAC suite à la réponse fournie par le service CLC.


Le service CLC a répondu par OK et pas de reste à charge.

7.4.2.2 Successeurs

Le système stocke la réponse du service CLC (cas nominal).

7.4.3 La conservation de l’indicateur STATUT_RAC à RAC Cette étape permet de conserver l’indicateur STATUT_RAC à RAC suite à la réponse fournie par le service CLC.


Le service CLC a répondu par OK et reste à charge.

7.4.3.2 Successeurs

Le système stocke la réponse du service CLC (cas nominal).

7.4.4 La conservation de l’indicateur STATUT_RAC à RAC Cette étape permet de conserver l’indicateur STATUT_RAC à RAC suite à la réponse fournie par le service CLC. Si le service CLC répond par un code retour KO, il convient alors de traiter et de classifier l’erreur afin d’automatiser au mieux le traitement des erreurs.


Le service CLC a répondu par KO.



7.4.4.2 Successeurs


Si le KO est de type 0018, 1001, 1002, 2031, 0101, 0102, 0103, 0104, 0105, 0106 ou 0107, le système alimente la liste des erreurs techniques.

Si le KO est de type 0002, 0003, 0005, 0014, 0022 ou 0024 au niveau dossier ou prestation, le système alimente la liste des informations patients.

A noter : comme indiqué précédemment, une proposition de répartition des rejets dans ces trois familles est ici proposée, à titre informatif. Le système doit permettre à l’établissement de définir sa propre répartition des rejets dans les trois familles ci-dessus, ainsi que les actions correctives associées à ces rejets

7.4.5 Le stockage des données CLC Cette étape permet de stocker les données CLC, afin de produire la facture-tiers patient et de pouvoir émettre la DRE-ES AMC.


Le service CLC a répondu par OK.

7.4.6 L’alimentation de la liste erreurs fonctionnelles Cette étape permet de placer la couverture de la venue dans la liste des erreurs fonctionnelles suite à une réponse KO du service annuaire ou du service CLC, pour les codes ci-dessous (répartition donnée à titre informatif). Il s’agit de problèmes sur le contenu du message : l’établissement doit revérifier la couverture.




0002 Pas d'ordonnance

La prise en charge est conditionnée à la présence d'une prescription


0023 Convention AMC non respectée (Réseaux)

Convention métier

0035 Demande hors délai

La demande est effectuée en dehors du délai défini par le contrat-cadre pour les préadmissions, les demandes effectuées a posteriori, ou le calcul.

0037 Echange IDB non effectué

l'AMC reçoit un SIM ou un CLC sans IDB préalable




Le service CLC a répondu par un KO du type 0011, 0018, 0023, 0035 ou 0037.

7.4.7 L’alimentation de la liste erreurs techniques Cette étape permet de placer la couverture de la venue dans la liste des erreurs techniques suite à une réponse KO du service SIM, pour les codes ci-dessous (répartition donnée à titre informatif). Cette liste fera l’objet d’un traitement manuel par les services informatiques et les éditeurs par la suite.


0018 Donnée incorrecte le système applicatif a détecté une donnée incorrecte ne permettant pas de finaliser l'échange

1001 Erreur technique (PS) Dysfonctionnement détecté dans la transaction envoyée par le PS

1002 Erreur technique ((AMC/OTP)


2031 Donnée manquante Les informations fournies par le PS sont insuffisantes ou erronées pour permettre le traitement du dossier

0101 Problème de sécurité Jeton Absent

0102 Problème de sécurité Jeton Erreur Certificat

0103 Problème de sécurité Jeton Certificat Revoqué

0104 Problème de sécurité Jeton Methode Erreur

0105 Problème de sécurité Jeton Obsolete

0106 Problème de sécurité Jeton Signature Invalide


Maintenance



Le service CLC a répondu par un KO du type 0018, 1001, 1002, 2031, 0101, 0102, 0103, 0104, 0105, 0106, 0107 ou http 404.



7.4.8 L’alimentation de la liste informations patients Cette étape permet de placer la couverture de la venue dans la liste des informations patients suite à une réponse KO du CLC, pour les codes ci-dessous (répartition donnée à titre informatif).


0003 Forfait épuisé / plafond atteint

Le forfait ou le plafond pour cette prestation a été consommé

0005 Pas de tiers payant Prestation non soumise à tiers payant 0014 Prestation non couverte La prestation n'est pas prise en charge par le contrat du

bénéficiaire 0022 Le bénéficiaire doit

contacter l'AMC un problème sur le contrat du bénéficiaire, de nature confidentielle, ne permet pas de le mettre en œuvre immédiatement

0024 Délai de carence en cours

Le contrat présente un délai de carence ne permettant pas de prendre en charge les prestations demandées


Le service CLC a répondu par un KO du type, 0003, 0005, 0014, 0022 ou 0024.

7.4.9 Les exigences relatives au service CLC Les exigences relatives à ce service sont détaillées dans le cahier des charges « HospiAMC ».

7.5 Processus DEL

En cas d’erreur suite à l’appel du service CLC, il est possible d’annuler cet appel. Pour cela le numéro d’engagement du CLC doit être renseigné à l’appel du service DEL. Le service DEL n’est pas référencé dans l’annuaire. Il doit être appelé en utilisant l’adresse du service CLC à annuler. Dans le cas où l’adresse du CLC ne répond pas, il convient alors de faire une recherche dans l’annuaire pour le service CLC, afin d’obtenir la nouvelle adresse du service DEL.

7.5.1 Les exigences relatives au service DEL Les exigences relatives à ce service sont détaillées dans le cahier des charges « HospiAMC ».


Fonctionnalités transversales 96/103

8 Fonctionnalités transversales Ce chapitre présente des fonctionnalités transversales au processus ROC qu’il est recommandé d’intégrer dans le fonctionnement du système. Ces fonctionnalités doivent être intégrées dans les processus déjà existants des outils. Ces maquettes ne présagent pas de la forme que devront avoir les écrans définitifs mais présente les objectifs à atteindre. Les objectifs sont :

- de présenter la possibilité sans pour autant imposer une IHM ou un fonctionnement,

- d’apporter aux établissements des fonctionnalités facilitant la gestion au quotidien

- et enfin d’assurer la qualité du système mis en place.

8.1 Archivage des échanges

Tous les échanges entre les services AMC et l’établissement doivent être conservés et archivés à des fins de traçabilité pendant une durée paramétrable dans le système. D’autres métadonnées à des fins statistiques doivent également compléter les échanges :

o date et heure d’appel du service ; o date et heure de réponse du service ; o adresse d’appel.

8.2 Alertes / informations contextuelles

Afin de faciliter et d’optimiser les traitements, les processus peuvent être appelés en tâche de fond permettant alors à l’agent de continuer à travailler sur d’autres dossiers et d’obtenir une réponse par le biais d’une notification dans l’application. Cette notification permettra de retourner rapidement où l’agent avait arrêté son processus.

8.3 Production de factures-tiers normalisées avec AMC hors ROC

Dans le cadre de la mise en place du projet ROC, les AMC deviendront progressivement compatibles ROC. Afin de normaliser les échanges et la production de factures-tiers sur un modèle unique, les établissements devront produire des factures-tiers papiers normalisées ROC également pour les AMC hors ROC. Ces factures-tiers doivent être en conformité avec les données présentes dans la DRE-ES ROC (Cf. cahier des charges Facturation, suivi et recouvrement) et répondre aux exigences suivantes : L’entête de facture-tiers doit présenter les données pertinentes des types suivants : 2CP, 2S, 2B, 2C, 2M, 2P). Le corps de la facture-tiers présente les lignes de factures-tiers selon les types suivants :

3CP, 3S, 3E, 3F, 3H : Prestations remboursables à l’établissement codées suivant l’annexe 10 B2. Ligne de demande de remboursement de prestations



hospitalières – Permet de facturer les frais de structure et de soins, les produits de la LPP facturables et les spécialités pharmaceutiques.

4CP, 4S, 4E: Ligne de demande de remboursement codé suivant les nomenclatures NGAP, NABM, Regroupement CCAM. Honoraires réglés au professionnel de santé, au mandataire des professionnels de santé ou à l’établissement de santé.

Le pied de facture-tiers doit présenter les types suivants :

5CP : Totaux (honoraires, remboursement).

5T : Complément d’informations à destination des organismes d’assurance maladie complémentaire Informations relatives aux professionnels de santé ou établissements de santé tiers (échange de plateau technique).

5U : Complément d’informations à destination des organismes d’assurance maladie complémentaire Informations relatives aux mandataires des professionnels de santé (paiement sur un compte commun à plusieurs PS).

On ne répétera pas les informations déjà présentes de l’entête de facture-tiers dans les lignes ou dans le pied de facture-tiers.

8.4 Traitements batch

Ce paragraphe décrit les traitements quotidiens qui peuvent être réalisés automatiquement par le système afin de préparer des listes de travail mais également d’informer le patient le plus rapidement possible. Ces traitements participent au suivi opérationnel des venues décrit dans le chapitre 4. Ce paragraphe s’intéresse à six situations particulières :

venues en cours avec une date de fin de contrat proche durant le séjour ;

venue en cours dont la date d’échéance de renouvellement est la date du jour ;

venues en hospitalisation en cours à la date de changement d’exercice comptable ;

venues prévisionnelles du jour ;

venues prévisionnelles à J-N (N étant un nombre de jours paramétrable) ;

venues aux Urgences pour lesquelles le patient est entré la veille et est encore présent à minuit.



Figure 23: BPM Traitement Batch



8.4.1 Réalisation du traitement automatique Cette étape permet d’identifier les venues devant faire l’objet d’une liste de travail et d’actions particulières.

8.4.1.1 Successeurs Le système génère, selon les situations identifiées lors du traitement :

la liste des venues en cours avec une date de fin de contrat proche durant le séjour ;

la liste des venues en cours dont la date d’échéance de renouvellement est la date du jour ;

la liste des venues en hospitalisation en cours à la date de changement d’exercice comptable ;

la liste des venues prévisionnelles du jour ;

la liste des venues prévisionnelles à J-N (N étant un nombre de jours paramétrable) ;

la liste des venues aux Urgences pour lesquelles le patient est entré la veille et est encore présent à minuit.

8.4.2 Génération de la liste des venues en cours avec date de fin de contrat proche durant le séjour

Cette étape permet d’identifier les couvertures ayant une date de fin de contrat AMC incluse dans le séjour et proche afin d’avertir le patient avant la fin de la couverture. En avertissant le patient en amont, l’établissement peut mettre à jour la couverture AMC par anticipation à partir d’une nouvelle attestation AMC, lorsque le patient fournit une nouvelle attestation AMC.


Le système a réalisé un traitement automatique.

8.4.3 Génération de la liste des venues en cours dont la date d’échéance de renouvellement est la date du jour

Cette étape permet d’identifier les couvertures dont la date de renouvellement correspond à la date du jour, pour les patients en cours d’hospitalisation. Dans ce cas, il est alors nécessaire de revérifier si la couverture du patient est renouvelée.



8.4.3.2 Successeur

Le système parcourt les enregistrements de la liste de travail générée et incrémente l’occurrence de période de facturation associées aux couvertures concernées.

8.4.4 Incrémentation de l’occurrence Cette étape permet d’incrémenter l’occurrence de chacun des enregistrements de la liste de travail.


Le système a généré la liste des venues en cours dont la date d’échéance de renouvellement est la date du jour.



8.4.4.2 Successeur

Le système procède à l’appel du processus Annuaire service IDB.

8.4.5 Appel du processus Annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB.


Le système a incrémenté l’occurrence.

8.4.5.2 Successeurs

Le système met à jour les informations IDB. et

Le système peut éventuellement procéder à l’appel du processus Annuaire service SIM.

8.4.6 Mise à jour des informations IDB Cette étape permet de mettre à jour les informations IDB, suite au nouvel appel du service.


Le système a procédé à l’appel du processus Annuaire service IDB.

8.4.7 Appel du processus Annuaire service SIM Cette étape permet de récupérer l’adresse du service SIM, puis d’interroger le service SIM si besoin.


Le système a procédé à l’appel du processus Annuaire service IDB.

8.4.8 Génération de la liste des venues en cours à la date de clôture d’exercice comptable

Cette étape permet d’identifier les venues en hospitalisation en cours concernées par un changement d’exercice comptable. Dans ce cas, il est possible de facturer les prestations complémentaires à la date de fin d’exercice.



8.4.8.2 Successeur

Le système parcourt les enregistrements de la liste de travail générée et incrémente l’occurrence de période de facturation associées aux couvertures concernées.

8.4.9 Incrémentation de l’occurrence Cette étape permet d’incrémenter l’occurrence de chacun des enregistrements de la liste de travail.


Le système a généré la liste des venues en cours à la date de changement d’exercice comptable.



8.4.9.2 Successeur

Le système procède à l’appel du processus Annuaire service CLC.

8.4.10 Appel du processus Annuaire service CLC. Cette étape permet d’appeler le service CLC afin de calculer la part AMC et/ou la part Patient sur les prestations hors soins, jusqu’à la date de changement d’exercice comptable. Pour cela, c’est le premier numéro d’occurrence qui sera utilisé.


Le système a incrémenté le numéro d’occurrence.

8.4.11 Génération de la liste des venues prévisionnelles du jour. Cette étape permet d’identifier un défaut potentiel de couverture AMC le jour de l’entrée (à partir de minuit) et ainsi, de lancer des demandes automatiques au service IDB. En fonction du résultat, le système peut donc créer des listes de travail sur les couvertures de la venue suivant leur état.

les couvertures complètes pour lesquelles les patients pourront directement être accueillis selon un « circuit court » (par exemple borne d’accueil) ;

les couvertures incomplètes qui nécessitent une admission du patient selon un « circuit long » (contact avec un opérateur).

Le système peut donc prévoir le nombre de patients qui nécessiteront un accueil selon un « circuit long » et les effectifs d’agents nécessaires en admission chaque jour. Le système peut également anticiper quelles informations sont manquantes dans une venue et ainsi de proposer des formulaires dynamiques et ergonomiques pour le recueil de ces informations. Il sera également possible d’informer le patient (par mail / SMS) quelques heures avant son arrivée pour lui rappeler son rendez-vous mais également l’orienter vers l’un ou l’autre des circuits.



8.4.11.2 Successeur


8.4.12 Appel du processus Annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB.


Le système a généré la liste des venues prévisionnelles du jour.

8.4.13 Génération de la liste des venues prévisionnelles à J-N Cette étape permet d’identifier les venues prévisionnelles des jours à venir, et ainsi, si l’établissement le souhaite, de lancer des demandes automatiques au service IDB N jours avant la venue de façon à identifier au plus tôt un défaut potentiel de couverture AMC, permettant ainsi à l’établissement d’interagir avec le patient pour la rectifier avant sa venue (courrier, sms, appel téléphonique). Le délai de lancement de ces demandes automatiques doit être paramétrable dans le système et différencié selon le contexte (ACE, Séjours).



Pour rappel, les informations fournies dans la réponse du service web IDB avant le jour de la venue ont un caractère informatif puisque la situation de couverture complémentaire du patient peut changer jusqu’au jour de la venue. Plus la demande sera proche de la date de la venue, plus la probabilité que les informations fournies dans la réponse à cette demande soient identiques lors de l’interrogation le jour de la venue augmente. Seules les informations issues de la réponse à l’interrogation du service web réalisée le jour de la venue sont engageantes pour les ACE pratiqués le jour de la venue.

8.4.13.1 Successeur


8.4.14 Appel du processus Annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB


Le système a généré la liste des venues prévisionnelles à J-N.

8.4.15 Génération de la liste des venues aux Urgences pour lesquelles le patient est entré la veille et est toujours présent à minuit.

Cette étape permet, dans le cas d’une venue aux urgences à cheval sur deux jours, d’identifier les patients concernés et d’appeler le service IDB par jour calendaire. Il est en effet nécessaire d’appeler le service IDB deux fois avec un numéro d’occurrence différent : la première fois à l’arrivée du patient et la seconde fois à partir de 0h. Ce processus peut être automatisé. Lors de la facturation, les actes devront également être associés au numéro d’engagement de l’IDB correspondant à la date des actes.



8.4.15.2 Successeur

Le système incrémente le numéro d’occurrence.

8.4.16 Incrémentation de l’occurrence Cette étape permet d’incrémenter l’occurrence.


Le système a généré la liste des venues aux Urgences pour lesquelles le patient est entré la veille et est toujours présent à minuit.

8.4.16.2 Successeur


8.4.17 Appel du processus Annuaire service IDB Cette étape permet de récupérer l’adresse du service IDB, puis d’interroger le service IDB


Le système a incrémenté le numéro d’occurrence.



PR

OJE

T R

OC

- R

EMB

OU

RSE

MEN

TS D

ES O

RG

AN

ISM

ES C

OM

PLE

MEN

TAIR

ES -

GU

IDE

D’I

MP

LEM

ENTA

TIO

N A

DES

TIN

ATI

ON

DES

ED

ITEU

RS

HO

SPIT

ALI

ERS

– Fé

v. 2

01

7

Documents

SIMPHONIE-ROC Guide implémentation Editeurs SIH 170301 v1.0 · 7.4.9 les exigences relatives au service clc 95 7.5 processus del 95 /-