TSS Projet ecarmed Couverture Soins de Santé

Transcription

1 TSS Projet ecarmed Couverture Soins de Santé Revision History Date Ver sion Description 10/11/ Version embryonnaire basée sur le draft du PID et la définition du service offert par la Smals à destination des CPAS 11/11/ affinement (réunion du 10/11/2011) les états de la couverture «carmed» les opérations le contenu en général 12/12/ Affinement (réunion 23/11/2011, architecture 30/11/2011, ehealth 8/12/2011) layout des operations : contenu les consultations distinctes par type de client prestataire de soin avec ou non un lien avec une entité 09/01/ changement contenu service back-end Smals 19/12/2011 correction suivant les remarques de la BCSS du 22/12/2011 et réactions de la Smals lors de la réunion du 6/01/ /01/ Schéma et logique en attente d un premier test du service back-end (SR = service edicalcardregistry inaccessible) 2/03/ Adapter le texte pour clarifier «Carte édicale» par «Décision électronique de prise en charge» Ajout des codes retour (révision du 20/02/2012 de la Smals) Définition du enduser : prestataire de soin Affinement de chaque opération par groupe d acteurs Affinement suite aux premiers tests avec le partenaire 8/03/ Ajout opération «consultcarmedatagreementdate» (suite réunion du 7/03/2012, besoin CAAI) 13/03/ le service a été développé et testé avec celui du back-end Smals : ( affinement et schémas définitifs (démarrage 28/2) Reprise d informations fonctionnelles en provenance du document [R3] du SPP IS 30/03/ Ajout de l opération history pour le SPP/IS et CAAI Correction : gestion limitée aux seuls CPAS 10/05/ Version définitive dans l état des développements à la BCSS et de ceux du service back-end (dernier schéma non encore produit) nombre de version de décisions de couverture ou de couvertures porté à 24 au lieu de 15. Ajout de l identifiant du bénéficiaire dans l opération modifycarmedrequest odification du nombre maximum de message d erreur à /06/ affinement suite relecture Ajout du code erreur Nouveaux schémas côté back-end délivré le 8/06/ /08/ Correction URI des services ECarmedService/xxx (WSDL/XSD sont corrects) ATI 01/10/ Changement du schéma du RN vs RN ATI Le RN remplira les nouveaux éléments dès le 20/11/2012 Author CC ATI participants réunion PYV, PTR, PVB, XXX, ATI participants réunion du 6/1/2012 CC et ATI. 2012_eCarmed_TSS.docx version 2.0 Pg 1/69 ATI ATI ATI ATI ATI ATI

2 Ajout du schéma du déploiement inter-environnements Nom et prénoms remplis par le service back-end 17/01/ Après validation des tests et mise-à-jour des textes du bloc «status» ATI - ATI : Alain Tilmant, BCSS - CC : Catherine Cocu, BCSS - PTR : Pierre Tricot, SPP IS - PVB : Patrick Vanden Bossche, Smals - GW : Grégory Wolf, Smals - PYV : Pierre-Yves Vandergeerde, SPP IS - NNI : Nicolas Nicaise Smals 2012_eCarmed_TSS.docx version 2.0 Pg 2/69

3 Documents connexes Document Autho r [R1] le PID du projet ecarmed BCSS [R2] Documentation concernant les webservices BCSS (SA-platform) http :// BCSS [R3 ] html Service Specification: Integration and use of the service ecarmed Version 0.9 SPP IS Distribution Révision Destinataires 0.4 SPP IS, Smals, ehealth 0.5 SPP IS, Smals, ehealth, CAAI 0.6 SPP IS, Smals, ehealth, CAAI 0.8 SPP IS, Smals, ehealth, CAAI 0.9 SPP IS, Smals, ehealth, CAAI 1.0 SPP IS, Smals, ehealth, CAAI, CPAS 1.1 and next SPP IS, Smals, ehealth, CAAI, CPAS Version Approved by Date 0.4 BCSS : ATI dans l état (sans validation technique avec celui 9/01/2011 du back-end Smals) 0.5 BCSS : ATI dans l état (sans validation technique avec celui 31/01/2012 du back-end Smals) (pas encore accessible par la BCSS) 0.6 remarque : le service back-end n étant pas disponible par la BCSS, nous nous réservons d adapter les schémas fournis lors d une prochaine révision (1.0?) 0.8 Affinement ehn vue d une approbation des partenaires 15/03/ Ajout de l opération history pour le SPP/IS et CAAI 30/03/2012 Correction : gestion limitée aux seuls CPAS SPP IS CAAI ehealth CIN 2.0 All partners 2012_eCarmed_TSS.docx version 2.0 Pg 3/69

4 Revision History... 1 Documents connexes... 3 Distribution bjectif du document Vue d ensemble des services Contexte Liens entre fonctionnalités, les services et les opérations Déploiement des divers composants Fonctionnement général Diagramme d état Diagramme d activité Gérer la couverture financière (décision électronique de prise en charge) Consulter la couverture financière (décision électronique) Résumé des opérations vue par le CPAS et les autres clients Description des données essage d entrée essage de sortie Protocole du service Service pour les CPAS Service pour la CAAI et le SPP IS Service pour les prestataires de soin Déploiement inter-environnements Description des messages échangés Conception et contenu La requête métier La réponse métier La réponse en cas d exception technique XSD La définition de la requête et de la réponse métier Identification de la requête et du client : informationcustomer Identification d une décision : ecarmedidentifier Contenu d une décision de prise en charge : ecarmedcontent Couverture financière des soins : medicalcover Intervention du SPP IS : refund_podmi_sppis pération : evaluate or open or modifycarmed peration : closecarmed pération : consultcarmed, consultcarmedhistory pération : consultcarmedatagreementdate pération : querycarmedanager pération : consultcarmedintervention Classification de la réponse La définition de l élément status La définition de l élément backendessages La définition de la réponse dans les cas d exception Disponibilité et performance Performance Disponibilité _eCarmed_TSS.docx version 2.0 Pg 4/69

5 7 pen issues Annexes Code de retour Business error Business Error Codes de la BCSS Business Error Codes du back-end Annexe : exemples pération consultcarmed pération consultcarmedhistory pération querycarmedanager pération consultcarmedintervention pération consultcarmedatagreementdate _eCarmed_TSS.docx version 2.0 Pg 5/69

6 1 bjectif du document Ce document décrit les spécificités techniques et les échanges d informations entre les acteurs du projet : le CPAS gestionnaire : celui qui gère l émission de la couverture ecarmed à savoir une décision électronique de prise en charge financière des soins médicaux. les autres CPAS, le SPP IS qui détermine son engagement de taux de remboursement et centralise les décisions de prise en charge prises par les CPAS, la CAAI qui contrôle les prestations effectuées sur base des factures, effectue les remboursements de la part SPP IS, se fait rembourser et transmet les décomptes au SPP IS. Ce dernier effectue les décomptes et envoie le solde des factures au CPAS gestionnaire. la Smals qui gère la DB ecarmed pour le compte du SPP IS et met à disposition un service accessible par la BCSS, le CIN qui est le point de contact 1 avec les organismes assureurs pour disposer du statut assurance soins de santé ainsi que le relais d accès à la BCSS pour la CAAI en tant que prestataire du SPP IS. la plateforme ehealth qui est le point d accès pour le monde médical. La plateforme ehealth permet à ses clients de s authentifier par un service Security Token Service et offre des services pour atteindre les autres partenaires tels que la BCSS, les mutualités via la plateforme NIPIN ( ycarenet,etc ) les prestataires de soins pour la consultation de la couverture financière (par la plateforme ehealth) et obtenir un numéro d agrément pour garantir ses remboursements. la BCSS qui est le point de contact vis-à-vis des CPAS, le SPP IS, ehealth, la CAAI (CIN) et le CIN Les services qui sont publiés sur l infrastructure de la BCSS sont l objet de ce document. Les services provider de la BCSS sont la Smals qui gère la base de données ecarmed, le Registre national pour les données d identification et le CIN pour l état du statut soin de santé. 1 tant de la plateforme ehealth que de celle de la BCSS 2012_eCarmed_TSS.docx version 2.0 Pg 6/69

7 2 Vue d ensemble des services 2.1 Contexte Trois services distincts sont disponibles pour chacun des acteurs : les CPAS, la CAAI et les prestataires de soins. L objectif des différentes opérations du service pour les CPAS est d évaluer avant attribution d une décision électronique de prise en charge de soins, la part de remboursement du SPP IS, d attribuer une couverture de soins de santé ecarmed, de la gérer par le CPAS qui l a attribué afin o de l adapter la couverture, (la période et, ou son contenu) o de l annuler en cas d attribution par erreur, o de la suspendre (release 2), o de la réactiver (release 2). de consulter soit les décisions électroniques de prise en charge de soins et leur contenu en totalité par o le CPAS gestionnaire, o le SPP IS, de connaître le CPAS gestionnaire d une ou de décisions électroniques de prise en charge de soins par les autres CPAS L objectif du service pour la CAAI est de disposer du contenu des décisions de prise en charge en cours ou en historique lors du traitement des factures en provenance des prestataires de soins. L objectif du service pour la SPP-IS est de disposer, en complément de la décision du CPAS d attribuer ou de modifier l aide financière, de la situation légale de la personne aidée, afin de centraliser toutes les aides financières accordées, de déterminer sa part d intervention et de persister toutes les versions dans une base de données centrale. L objectif du service pour les prestataires de soins est d obtenir les informations de prise en charge et, le cas échéant, le numéro d agrément pour garantir le remboursement. 2012_eCarmed_TSS.docx version 2.0 Pg 7/69

8 2.1.1 Liens entre fonctionnalités, les services et les opérations Service ecarmed pour les CPAS Fonctionnalités demander au SPP IS, ses taux d intervention financière sur un cas spécifique prendre une décision électronique d une prise en charge adapter la décision électronique d une prise en charge supprimer la décision électronique d une prise en charge consulter le contenu de décisions électroniques d une prise en charge consulter le contenu avec historique de décisions électroniques d une prise en charge disposer d une liste des décisions électroniques de prise en charge opérations evaluatecarmed opencarmed modifycarmed closecarmed consultcarmed consultcarmedhistory querycarmedanager Service ecarmed pour la CAAI et le SPP IS Fonctionnalités opérations consulter le contenu de décisions électroniques d une prise en consultcarmed charge consulter le contenu avec historique de décisions électroniques consultcarmedhistory d une prise en charge consulter le contenu historique de décisions électroniques d une consultcarmedatagreementdate prise en charge (version active à ce moment) Service ecarmed pour les prestataires de soin Fonctionnalités opérations obtenir les informations sur les interventions accordées (décisions consultcarmedintervention électroniques d une prise en charge) et, s il échet, un numéro d agrément de garantie de paiement 2012_eCarmed_TSS.docx version 2.0 Pg 8/69

9 2.1.2 Déploiement des divers composants les applications des clients : CPAS, web-app portail, CAAI, hôpitaux, prestataires les plateformes : bus ehealth, bus BCSS, bus Sécurité Sociale les services exposés Le schéma suivant reprend l architecture complète des composants et des acteurs 2012_eCarmed_TSS.docx version 2.0 Pg 9/69

10 2012_eCarmed_TSS.docx version 2.0 Pg 10/69

11 2.2 Fonctionnement général Diagramme d état Le diagramme ci-dessous reprend les opérations pour atteindre les différents états d une gestion d une couverture financière soin de santé. Explication état «évaluation couverture soin de santé» Avant de décider d octroyer une couverture financière soin de santé, le CPAS souhaite connaître les taux d intervention du SPP IS pour le dossier en enquête. En effet, elle devra supporter elle-même le solde des remboursements. Cet état est virtuel car aucune persistance n est prévue au niveau de la DB. état «couverture soin de santé accordée» Le CPAS décide d attribuer cette couverture soin de santé, les taux de remboursement du SPP IS sont fixés et un numéro de carte est attribué. Chaque modification correspond à une nouvelle version. état «couverture supprimée» En cas d erreur administrative ou autre, le CPAS peut annuler une couverture. état «couverture suspendue» 2012_eCarmed_TSS.docx version 2.0 Pg 11/69

12 Lors d un changement de numéro du bénéficiaire, la couverture est bloquée. (release 2) Diagramme d activité Le diagramme d activité décrit la responsabilité des divers acteurs Gérer la couverture financière (décision électronique de prise en charge) Cela concerne les quatre opérations pour gérer une décision électronique. Les fonctions evaluate permet d obtenir les taux d intervention du SPP-IS en fournissant les données de base à la prise d une décision de prise en charge. Il s agit d une évaluation qui n a aucun effet au niveau de la base de données : aucune couverture n est créée. open et modify servent, respectivement à créer une couverture ou à la modifier, close est utilisée lorsqu il y a eu émission par erreur et que l on veut la supprimer. 2012_eCarmed_TSS.docx version 2.0 Pg 12/69

13 Consulter la couverture financière (décision électronique) Le diagramme pour la consultation d une carte médicale diffère uniquement par les plateformes intermédiaires pour accéder au service de la BCSS 2012_eCarmed_TSS.docx version 2.0 Pg 13/69

14 2.2.3 Résumé des opérations vue par le CPAS et les autres clients pérations objet à fournir à recevoir (cas positif) evaluatecarmed obtenir les taux de remboursement pris en - identifiant du CPAS info sur la situation du bénéficiaire charge par le SPP IS - identifiant du bénéficiaire les taux de remboursement SPP IS - info sur la couverture envisagée opencarmed attribuer une couverture financière soins de santé - identifiant du CPAS - identifiant du bénéficiaire - info sur la couverture financière modifycarmed modifier la couverture financière soins de santé identifiant du CPAS numéro ecarmed identifiant du bénéficiaire nouvelle info sur la couverture financière closecarmed supprimer la couverture financière soin de santé identifiant du CPAS numéro ecarmed querycarmedanager obtenir le gestionnaire du «carmed» identifiant du CPAS identifiant de la couverture (choix) o le numéro ecarmed o le bénéficiaire + repère temporel info sur la situation du bénéficiaire les taux de remboursement SPP IS le numéro carmed la version info sur la situation du bénéficiaire les taux de remboursement SPP IS le numéro carmed et la version accepté / refusé { idendifiant carte médicale, CPAS gestionnaire } ou pas de résultat consultcarmed consultcarmedhistory consultcarmedatagreementdate consulter la (les) couverture(s) «carmed» la version actuelle toutes les versions consulter la (les) version(s) de (s) la couverture(s) «carmed» au moment de l émission du numéro d agrément identifiant du CPAS/SPP IS / CIN [CAAI] identifiant de la couverture o le numéro ecarmed o le bénéficiaire + repère temporel identifiant du SPP IS / CIN [CAAI] identifiant de la couverture ou du bénéficiaire (optionnel : une période d agrément) date de la consultation par le prestataire de soins consultcarmedintervention obtenir la couverture «carmed» identifiant du prestataire identifiant de la couverture (choix) { identifiant carte médicale, contenu de la carte médicale } ou pas de résultat { identifiant carte médicale, contenu de la carte médicale } ou pas de résultat { identifiant carte médicale, contenu de la carte médicale, numéro d agrément } ou 2012_eCarmed_TSS.docx version 2.0 Pg 14/69

15 o o le numéro ecarmed le bénéficiaire + repère temporel pas de résultat 2012_eCarmed_TSS.docx version 2.0 Pg 15/69

16 L application des CPAS exploite le service offert par la BCSS pour gérer l état de la couverture soin de santé ecarmed. Les applications de la CAAI / SPP IS exploitent le service offert par la BCSS pour consulter les couvertures financières de soin de santé. Les prestataires de soins, après authentification avec le système STS de la plateforme ehealth, exploitent le service qu ehealth présente. Ce dernier interagit avec celui de la BCSS en y incluant l identification du prestataire de soins (personne morale ou personne physique). Il s agit d échange de messages XL respectant la définition SAP et contenant un document XL spécifique par opération dont l élément parent est suffixé par Request ou Response en fonction de la direction de l échange. Un schéma technique permet de valider la conformité du message. 2012_eCarmed_TSS.docx version 2.0 Pg 16/69

17 3 Description des données Cette description reste générale car l expression du contenu est définie par le SPP IS. Le cookbook Service Specification:Integration and use of the service ecarmed (Version 0.9 ou plus) into an external application du SPP IS décrit la signification des éléments. Remarques : Il y a quelques différences : le nom du service : le service exposé par la BCSS pour l ensemble des clients s appelle ecarmed, celui utilisé par la BCSS et exposé par la Smals est edicalcardregistry le nom des opérations : la BCSS a défini le nom des opérations et de leur contenu par rapport à la vision du client suivant les règles de l art de l architecture orientée service. 3.1 essage d entrée La demande d attribution d une couverture soin de santé ecarmed provenant du CPAS contient Contenu métier <proposal> <ssin> <validityperiod> <startdate> <enddate> <medicalcard> <judicialdecisionind> <decisiondate> <incomelessthanrisind> <medicalcover> <doctor> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <maxprestation> <healthcareproviderlist> <nihiinbr> andatory ptional Explication cfr doc SPP IS NTHING/PARTIAL/FULL 2012_eCarmed_TSS.docx version 2.0 Pg 17/69

18 2012_eCarmed_TSS.docx version 2.0 Pg 18/69 <hospitalization> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <hospitallist> <hospital> <nihiinbr> <servicedescription> <hospitalservicelist> <servicecode> <supporteddrugsdescription> <ambulatoryhospitalization> <validityperiod> <startdate>> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <hospitallist> <hospital> <nihiinbr> <servicedescription> <hospitalservicelist> <servicecode> <supporteddrugsdescription> <medicaltransportation> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <companylist> <cbenumber>

19 <miscellaneous> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <maxamount> <paramedic> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <maxamount> <maxprestation> <providerlist> <nihiinbr> <pharmaceuticaldrug> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <maxamount> <pharmacylist> <nihiinbr> 2012_eCarmed_TSS.docx version 2.0 Pg 19/69

20 <prosthesis> <validityperiod> <startdate> <enddate> <pswc_support> <pswc_ziv_ami_part> <pswc_patientpart> <pswc_supplement> <description> <decisiondate> <supportedsupplementsdescription> <maxamount> <companylist> <cbenumber> La structure d une requête outre le nom de l opération spécifique est composée d un même ensemble de blocs de données : informationcustomer legalcontext critère lié à l opération 3.2 essage de sortie La structure d une réponse reprend les blocs de la requête suivis d un bloc statut et la réponse «métier» en cas de succès. Dans le cas d une réponse métier positive, la réponse fournie par la BCSS consiste à fournir l information souhaitée : Cas bjectif Résultat 1. Demander l évaluation de l intervention du SPP IS l intervention du SPP les données liées à la personne communiquée par la BCSS au SPP IS 2. Créer ou modifier la décision électronique l intervention du SPP l identifiant de la carte médicale les données liées à la personne communiquée par la BCSS au SPP IS 3. Annuler une décision électronique statut positif (attribuée par erreur) 4. Consulter les décisions existantes par les les identifiants des décisions électroniques autres CPAS prises sur la période 5. Consulter le contenu des décisions les identifiants et leur contenu des décisions électroniques 2012_eCarmed_TSS.docx version 2.0 Pg 20/69

21 Précisions supplémentaires L élément général status fournit la qualité de la réponse. Un second élément optionnel backendessages permet de prendre connaissance des remarques communiquées par l application back-end edicalcardregistry Contenu <status> <value> <code> <description> <information> <21ieldname> <fieldvalue> <backendessages> <backendessage severity= <reasoncode> <source> <communication lang=»fr»> <communication lang=»nl»> andatory optional DATA_FUND/ N DATA_FUND/ N RESULT ERRR/ WARNING/ INFRATIN En cas de réponse métier positive suivant la requête Réponse métier <refund_podmi_sppis> <refundcode> <affiliedutualityind> <beneficiarystatus> <justification lang= fr > <justification lang= nl> <podmi_sppis_hospitalization_ziv_ai_part> <podmi_sppis_ambulatorycare_ziv_ai_part> <podmi_sppis_ther_ziv_ai_part> <podmi_sppis_hospitalization_patientpart> <podmi_sppis_ambulatorycare_patientpart> <podmi_sppis_ther_patientpart> <medicalurgencyind> <ecarmedidentifier> <ecarmednumber> <versionnbr> <beneficiary> <ssin> <lastname> <firstname> <gender> <birthdate> <validityperiod> <startdate> <enddate> <pswc> <cbenumber> <municipalityins> <name lang= fr > <name lang= nl > <manageddates> <creationdate> operation evaluate open modify 2012_eCarmed_TSS.docx version 2.0 Pg 21/ / 0.50 / 1.00 open modify consult consulthistory consultatagreementdate consultintervention queryanager

22 <lastodificationdate> <ecarmedcontent> consult consulthistory consultatagreementdate consultintervention <agreementnbr> consultintervention 2012_eCarmed_TSS.docx version 2.0 Pg 22/69

23 4 Protocole du service La communication applicative est réalisée par l appel de web-services [message SAP] La description générale peut être trouvée sur le site de la BCSS Service pour les CPAS Service ecarmedservice Namespace WS par CPAS (WS 1) ecarmedpswc.wsdl client pérations WS 1 client : CPAS gestionnaire evaluatecarmed et autres CPAS (query) opencarmed modifycarmed closecarmed querycarmedanager consultcarmed consultcarmedhistory essages evaluatecarmedrequest/response/fault opencarmedrequest/response/fault modifycarmedrequest/response/fault closecarmedrequest/response/fault Fault querycarmedanagerrequest/response/fault consultcarmedrequest/response/fault consultcarmedhistoryrequest/response/fault Point d entrées extranet WSDL XSD protocole URL URI dvlp acpt prod ECarmedService/manageCarmed ECarmedService/manageCarmed ECarmedService/manageCarmed ecarmedpswc.wsdl BaseLegalDataV1.xsd CommonV3.xsd ecarmedtypesv3.xsd ecarmedv3.xsd rn25_release xsd rn25_release xsd HTTPS 2ways pour les CPAS //bcssksz[-[test] [acc]].service.be/sa4520/<uri> ECarmedService/manageCarmed 2012_eCarmed_TSS.docx version 2.0 Pg 23/69

24 Sécurisation CPAS Authentification : user/pw (user token) SSL 2ways avec proxy Smals xml /customeridentification/cbenumber. (chaque CPAS) /legalcontext manage ecarmed 4.2 Service pour la CAAI et le SPP IS Service ecarmedservice Namespace WS par client CAAI (WS 2) ecarmedconsult.wsdl pérations WS 2 consultcarmed consultcarmedhistory consultcarmedatagreementdate client : SPP IS & CAAI essages Fault consultcarmedrequest/response/fault consultcarmedhistoryrequest/response/fault consultcarmedatagreementdaterequest/response/fault Points d entrée BCSS WSDL XSD protocole URL URI dvlp b2b-test.ksz-bcss.fgov.be accept b2b-acpt.ksz.bcss.fgov.be prod b2b.ksz-bcss.fgov.be ecarmedconsult.wsdl BaseLegalDataV1.xsd CommonV3.xsd ecarmedtypesv3.xsd ecarmedv3.xsd rn25_release xsd rn25_release xsd HTTPS 2ways Pour le CIN (CAAI) //b2b[-test -acpt].ksz-bcss.fgov.be :4520/<uri> Pour le SPP/IS via le reverse proxy (cfr service CPAS) ECarmedService/consultCarmed Sécurisation CAAI Via le CIN Authentification : ssl 2 ways SPP IS Authentification : user/pw (user token) SSL 2ways avec proxy Smals xml customeridentification/cbenumber (CIN) (SPP IS) legalcontext rights ecarmed 2012_eCarmed_TSS.docx version 2.0 Pg 24/69

25 4.3 Service pour les prestataires de soin Service ecarmedservice Namespace WS par client Prestataire de soin (WS 3) ecarmedconsultcare.wsdl pérations WS 3 consultcarmedintervention client : prestataires de soin essages Point d entrée Points d entrée BCSS WSDL XSD protocole URL URI Sécurisation Fault consultcarmedinterventionrequest/response/fault via la plateforme ehealth (cfr info ehealth) Leur service sur base du Security Token Service définira dans le message métier l identification de l utilisateur : personne physique ou morale représentant le prestataire de soins. dvlp b2b-test.ksz-bcss.fgov.be accept b2b-acpt.ksz.bcss.fgov.be prod b2b.ksz-bcss.fgov.be ecarmedconsultcare.wsdl BaseLegalDataV1.xsd CommonV3.xsd ecarmedtypesv3.xsd ecarmedv3.xsd rn25_release xsd rn25_release xsd HTTPS 2ways pour ehealth //b2b[-test -acpt].ksz-bcss.fgov.be :4520/<uri> ECarmedService/consultCarmedIntervention Prestataires de soin prestataire vis-à-vis de la plateforme ehealth le token délivré par STS plateforme ehealth vis-à-vis de la BCSS Authentification de la plateforme ehealth : ssl 2 ways + assertion Identification prestataire fourni par ehealth sur base du token xml customeridentification/cbenumber legalcontext rights ecarmed 2012_eCarmed_TSS.docx version 2.0 Pg 25/69

26 4.4 Déploiement inter-environnements 2012_eCarmed_TSS.docx version 2.0 Pg 26/69

27 5 Description des messages échangés 5.1 Conception et contenu Il s agit des principes généraux. Le message requête XL est identifiable par son nom d opération suivi de Request. Il contient toujours les éléments : informationcustomer ; permettant au partenaire de fournir un ticket et de s identifier legalcontext ; précisant la finalité du service demandé ainsi qu un élément précisant un critère. Le nom de cet élément est adapté au contexte de l opération Le message réponse XL est identifiable par son nom d opération suivi de Response. Il contient toujours les éléments : informationcustomer, repris de la requête, informationcbss ; fournissant le ticket de la transaction ainsi que les dates et heures de traitement, legalcontext, repris de la requête l élément reprenant le critère ; repris de la requête, status ; résumant le statut du traitement du service et, s il échet, un élément reprenant le résultat en cas de réponse positive. Dans le cas du service ecarmed, nous avons inséré, après status, un élément optionnel backendessages pour communiquer des informations supplémentaires du service back-end. 2012_eCarmed_TSS.docx version 2.0 Pg 27/69

28 5.1.1 La requête métier 2012_eCarmed_TSS.docx version 2.0 Pg 28/69

29 Elément Définition Contenu xxxrequest l élément racine du message métier sous l élément Body du message soap /informationcustomer ticket= [0-9,a-Z]{0,36} timestamp= t09:30:47.0z /legalcontext customeridentification cbenumber : le numéro d entreprise du CPAS legalcontext= registry ecarmed /critère métier La réponse métier La réponse métier peut être négative ou positive. Elément Définition Contenu l élément racine du message métier sous l élément Body du message soap /informationcustomer idem que dans requête idem que dans requête 2012_eCarmed_TSS.docx version 2.0 Pg 29/69

30 /informationcbss /legalcontext idem que dans requête /critère métier idem que dans requête idem que dans requête cfr requête /status value = DATA_FUND N_DATA_FUND N_RESULT /réponse métier éventuel La réponse en cas d exception technique Elément Définition Contenu l élément racine du message métier sous l élément Fault du /informationcustomer /informationcbss /legalcontext idem que dans requête message soap idem que dans requête 2012_eCarmed_TSS.docx version 2.0 Pg 30/69

31 /detail 2012_eCarmed_TSS.docx version 2.0 Pg 31/69

32 5.2 XSD Chaque opération exploite des sous-ensembles communs tant pour la question et la réponse La définition de la requête et de la réponse métier Les blocs communs Identification de la requête et du client : informationcustomer Elément cbenumber pour les CPAS : identifié par leur numéro d entreprise pour les prestataires de soins, il s agit de celui de ehealth pour la CAAI, il s agit de celui du CIN legalcontext suivant la finalité manage ecarmed (evaluate, open, modify, close, ) rights ecarmed (consult) 2012_eCarmed_TSS.docx version 2.0 Pg 32/69

33 Identification d une décision : ecarmedidentifier Elément le contenu de l élément ecarmedidentifier 2012_eCarmed_TSS.docx version 2.0 Pg 33/69

34 Contenu d une décision de prise en charge : ecarmedcontent Elément le contenu de la couverture financière soin de santé 2012_eCarmed_TSS.docx version 2.0 Pg 34/69

35 Couverture financière des soins : medicalcover le contenu de l élément medicalcover 2012_eCarmed_TSS.docx version 2.0 Pg 35/69

36 Intervention du SPP IS : refund_podmi_sppis le contenu de l élément refund_podmi_sppis 2012_eCarmed_TSS.docx version 2.0 Pg 36/69

37 pération : evaluate or open or modifycarmed pération / élément evaluatecarmedrequest opencarmedrequest modifycarmedrequest evaluatecarmedrequest opencarmedrequest modifycarmedrequest Elle permet au CPAS d obtenir du SPP IS les pourcentages de prise en charge de l Etat fédéral applicables pour les différentes catégories de soins. Cette opération permet à la BCSS de transférer vers ecarmed une requête faite par un CPAS dans deux buts : 1. d obtenir les pourcentages de prise en charge par le SPP IS pour un patient/bénéficiaire. Ceci correspond à ceux retournés par la fonction d évaluation sur base d un même contexte. 2. de créer une décision de prise en charge dans le système ecarmed 3. d attribuer le numéro de couverture de cette version 1. Toute modification de la décision de prise en charge est permise par le CPAS qui l a créée pour autant qu elle ne diminue pas les droits du bénéficiaire dans le passé ; le système ecarmed a été conçu pour offrir une garantie de remboursement aux prestataires de soins. n ne peut donc modifier une décision rétroactivement pour ne pas donner de surprises aux prestataires de soin qui aurait déjà consulté la décision. Concrètement, les modifications permises sont les suivantes :: Augmenter la période de validité de cette prise en charge (date de début plus récente, date de fin plus ancienne) n ne peut allonger la durée de la décision d aide au-delà 2012_eCarmed_TSS.docx version 2.0 Pg 37/69

38 d une année (cf. L enquête sociale) : il faut sinon créer une nouvelle décision. Diminuer la période de validité de cette prise en charge (date de début plus ancienne, date de fin plus récente) pour autant que cette période soit dans le futur Arrêter une carte médicale = indiquer comme date de fin de validité le lendemain (ou la date de début, si la carte est dans le futur). Il n est pas possible d arrêter une carte médicale dans le passé ou même aujourd hui parce qu un prestataire aurait pu consulter la décision au jour de l arrêt par exemple et effectuer des prestations sur la base de l information qu il y a trouvée. De même, en cas de suppression de la décision dans le futur, cette décision restera valide au moins un jour. odifier la date de décision du CPAS odifier l indicateur «décision judiciaire». Attention, s il ne s agit pas d une décision judiciaire, la date de début de la carte médicale ne peut remonter plus loin dans le passé que date de création 45 jours. odification de l élément indiquant le niveau par rapport au revenu d intégration, le changement de cet élément aura un impact sur le pourcentage d intervention du SPP IS Ajouter une ou des couvertures Augmenter la période de validité d une couverture (date de début plus ancienne, date de fin plus récente) Diminuer la période de validité de cette couverture (date de début plus récente, date de fin plus ancienne) pour autant que cette période soit dans le futur Arrêter une couverture = indiquer comme date de fin le lendemain (ou la date de début, si la carte est dans le futur). Il n est pas possible d arrêter une couverture dans le passé ou même aujourd hui parce qu un prestataire aurait pu voir la carte aujourd hui. De même, il n est pas possible de supprimer une couverture dans le futur elle restera au minimum valide un jour. Supprimer la liste des prestataires autorisés autrement dit autoriser tous les prestataires de cette discipline à réaliser des soins dans le cadre de cette couverture Ajouter des prestataires à une liste préexistante Ajouter une liste de prestataires autorisés alors qu il n y en avait pas, uniquement si la 2012_eCarmed_TSS.docx version 2.0 Pg 38/69

39 Le détail de proposal evaluatecarmedrequest opencarmedrequest carte commence à partir du lendemain Supprimer un prestataire dans une liste de prestataires autorisés uniquement si la carte commence à partir du lendemain odifier des champs textuels odifier des dates de décisions odifier la prise en charge par le CPAS. Si la carte commence dans le passé, il n est pas possible de réduire l intervention du CPAS (par exemple : passer d une intervention de 100% à 0%). 2012_eCarmed_TSS.docx version 2.0 Pg 39/69

40 le détail de proposal modifycarmedrequest 2012_eCarmed_TSS.docx version 2.0 Pg 40/69

41 La réponse métier evaluatecarmedresponse opencarmedresponse modifycarmedresponse l élément backendessages contient un ou plusieurs éléments backendessage. Il contient les remarques du service = ERRR WARNING INFRATIN Il a été prévu, un maximum de 400 messages d erreurs émis par le service back-end. Le contenu de result de evaluatecarmedresponse 2012_eCarmed_TSS.docx version 2.0 Pg 41/69

42 Le contenu de result de opencarmedresponse modifycarmedresponse Un numéro de décision est fourni ainsi que sa version. La notion de deux types de décision est décrite ci-après. La décision de principe : n parle de décision de principe lorsque le CPAS crée une décision sans couverture effective : en d autres termes, cette décision ne crée aucun droit à une intervention financière pour des soins médicaux. Elle se justifie par : o La nécessité pour le CPAS de respecter le délai de 45 jours qu il a pour introduire sa décision d intervention au SPP IS une décision «de principe» puisqu assortie d aucune couverture effective, suffit. o L identification du CPAS compétent pour le patient, information qui peut être utile au prestataire. o L interdiction faite ainsi aux autres CPAS d introduire une décision électronique sur cette personne., Avec cette décision, le prestataire ne sera couvert pour aucune prestation. La décision exécutable : La décision devient exécutable lorsqu une couverture de soins au moins est «activée». Par activation, on entend que le CPAS a introduit au moins une couverture de soins valide pour une période donnée. La décision exécutable ouvre le droit pour le prestataire de soins d introduire ses 2012_eCarmed_TSS.docx version 2.0 Pg 42/69

43 créances auprès de la CAAI afin de bénéficier du remboursement par celle-ci du pourcentage de prise en charge de l Etat (= le SPP IS). Selon les modalités reprises dans la décision électronique que le prestataire peut consulter à tout moment dans le système ecarmed. Ceci entraine à terme la suppression des formulaires existants du SPP IS : les formulaires B et D pour l aide médicale. 2012_eCarmed_TSS.docx version 2.0 Pg 43/69

44 Les données du bénéficiaire sur lesquelles le SPP IS s est basé pour prendre sa décision, sont retournées à l application cliente. Ces données ont été collectées par la BCSS avant de transmettre la requête au service back-end edicalcardregistry. 2012_eCarmed_TSS.docx version 2.0 Pg 44/69

45 peration : closecarmed closecarmed Request closecarmed Response Le CPAS gestionnaire fournit le numéro de la décision à annuler Le SPP IS adapte la décision en fonction de la situation pour éviter une discordance ultérieure de facturation si un prestataire a reçu un numéro d agrément d intervention Remarque importante Dans cette phase de démarrage, le service backend n a pas encore envisagé de développer cette fonction. Le SPP IS donneur d ordre ne leur a pas demandé explicitement. Eventuellement des instructions spécifiques devront être fournies pour utiliser l opération modifycarmed : à charge de l application cliente de refournir des informations présentes lors de la décision de la dernière version mais en adaptant chacune des périodes. 2012_eCarmed_TSS.docx version 2.0 Pg 45/69

46 pération : consultcarmed, consultcarmedhistory Request Response Le critère de sélection est soit le numéro de la décision soit le bénéficiaire à une date ou dans une période Suivant l opération utilisée, on reçoit la (les) version(s) active(s) de(s) décision(s) électronique(s) répondant au critère de recherche. Sinon, il s agit de toutes les versions. 2012_eCarmed_TSS.docx version 2.0 Pg 46/69

47 pération : consultcarmedatagreementdate Request Response La CAAI peut spécifier suivant le contrôle à effectuer la date à laquelle le prestataire a reçu un numéro d agrément et combinée o soit à un numéro de carte (sa période est connue) o soit à un bénéficiare (une période peut être fournie) La réponse positive fournit la version historique active lors de la consultation par le prestataire de soins. S il y a une modification, le même jour, deux versions peuvent être fournies car nous ne disposons pas de l heure de la consultation. S il s agit d une période, plusieurs décisions délivrées par plusieurs CPAS couvrant des périodes successives pourraient être délivrées 2012_eCarmed_TSS.docx version 2.0 Pg 47/69

48 pération : querycarmedanager Request Response détail de carmed 2012_eCarmed_TSS.docx version 2.0 Pg 48/69

49 pération : consultcarmedintervention Request Response La plateforme ehealth remplit l élément enduser sur base de l authentification du prestataire de soins Le prestataire précise soit le numéro de la décision électronique soit le bénéficaire et un repère temporel de l intervention o soit le jour o soit une période 2012_eCarmed_TSS.docx version 2.0 Pg 49/69

50 fragment Le contenu de la décision se limite, éventuellement, aux différentes couvertures ainsi qu à l intervention prise en charge par le SPP IS. Le SPP IS peut limiter l accès au contenu, si le CPAS a précisé une liste limitative des prestataires S il y a intervention, un numéro d agrément est fourni. 2012_eCarmed_TSS.docx version 2.0 Pg 50/69

51 Identification du prestataire de soins (requête) : Lorsque le prestataire de soins s authentifie à la plateforme ehealth avec son numéro national, les vérifications auprès des sources authentiques (INAI,..) permettent de délivrer un token reprenant le(s) numéro(s) INAI ainsi que la (les) catégorie(s) médicale(s) associée(s). L application ehealth insère dans le message de l opération consultcarmedintervention dans l élément enduser une entrée medicalentity pour chaque catégorie médicale auxquelles appartient le prestataire. Au vu de la finalité du service, la personne morale prime sur la personne physique. Cela signifie que seule la catégorie (hôpital, officine, etc. ) devra être transmise s elle est présente dans le token d authentification. Dans le cas contraire, c est la personne physique qui est fournie : docteur, Catégorie de Prestataire de soin Personne physique Centre de soins de jour Groupement infirmier Hôpital aison de repos et de soins aison médicale Pharmacie Catégorie médicale doctor pharmacist dentist midwife nurse physiotherapist dietist podiatrist logopedist orthoptist orthopedist bandagist implantprovider occupationaltherapist opticien audicien biologistpharmacist psychologist mastergerontology masterremedialeducation specializededucator bachelorfamilyscience bachelorreadaptation masterpsychomotortherapy masterappliedpsychology practicalnurse retirementnurse socialworker daycarecenter groupofnurses hospital retirement medicalhouse pharmacy 2012_eCarmed_TSS.docx version 2.0 Pg 51/69

52 Classification de la réponse réponse avec numéro d agrément status value DATA_FUND réponse négative lorsqu une décision existe status value N_DATA_FUND description WARNING[1] information fieldname WARNING fieldvalue 1105-xx + 52ieldna backendessages Liste non exhautive Signification Il n y a pas de carte médicale Pas d intervention spécifiée pour la date ou la période fournie Le prestataire n est pas repris dans la liste pour une intervention du CPAS 2012_eCarmed_TSS.docx version 2.0 Pg 52/69

53 5.2.2 La définition de l élément status L élément value peut prendre trois valeurs : status/value Signification DATA_FUND le service a fourni ce qui a été demandé N_DATA_FUND le service n a pas fourni tout ce qui a été demandé : voir les éléments information N_RESULT le service n a rien fourni : voir l élément status/description En cas de réponse incomplète (N_DATA_FUND) ou négative (N_RESULT) status/description status/information /fieldname /fieldvalue ERRR[n] WARNING[n ] INFRATIN[n ] n, n et n > 0 avec description contenant ERRR/WARNING/INFRATIN ERRR/WARNING/INFRATIN le code nnnn-nn fourni par le service back-end 2012_eCarmed_TSS.docx version 2.0 Pg 53/69

54 5.2.3 La définition de l élément backendessages En cas de information/fieldname avec ERRR ou WARNING ou INFRATIN, la description de la signification du code erreur du back-end est repris dans l élément ERRR WARNING INFRATIN reasoncode : = fr nl La définition de la réponse dans les cas d exception Ce message est produit lorsque la réponse n est pas générée à partir d une réponse du service back-end : soit il n est pas disponible ou une validation n est pas positive. Les éléments description, information sont présents Erratum : le nombre d occurrences de l élément information peut atteindre 400. Le schéma a une définition surchargeant l option par défaut de _eCarmed_TSS.docx version 2.0 Pg 54/69

55 Les détails de l implémentation technique à titre d information. Le document interne PC couvre complètement cet aspect. Processus de la BCSS partie générique 1. Réceptionner la requête provenant du partenaire [session SSL avec authentification du client] 2. Diriger la requête vers le point de traitement conforme à la définition du service [cfr le WSDL]. 3. Contrôler la conformité du message par rapport au schéma du service [cfr le XSD] 4. Ajouter le bloc «informationcbss» contenant le ticket de la transaction ainsi que la date et heure de la réception du message. 5. Prendre un logging de la requête. 6. Demander l autorisation d accéder au service avec les «credentials» fournis [AAApolicy] 7. Appeler le service «xxxx» 8. Ajouter à la réponse du service, la date et heure de la réponse dans le bloc «informationcbss» 9. Prendre une trace de la réponse [Logging] 10. Fournir la réponse au client. Partie spécifique 1. sauver les quatre blocs de la requête : informationcustomer, informationcbss, legalcontext et les critères métier, 2. vérifier la qualité des données, 3. vérifier dans le cas de la gestion de la carte, l appartenance du dossier par le CPAS client, 4. générer le message du service back-end en adaptant les informations de la requête : informationcustomer : reprendre coordonnées de la BCSS (si le back-end le prévoit) consulter le RN et, ou la BCSS pour collectionner les données concernant le bénéficiaire (consultation xm25 avec un code application spécifique du SPP IS [à obtenir du RN]). mapping entre les données 5. valider la conformité du message suivant le schéma du service edicalregistry (?)[cfr XSD] 6. appeler le service back-end (ajout de la partie WS-security à savoir signature d un timestamp, du BST (=certificat) et du Body). 7. traiter la réponse du service, 8. générer la réponse pour le front-end en fonction de l élément result du service back-end 9. reprendre les quatre blocs informationcustomer, informationcbss, legalcontext et les critères métier ajouter le bloc status et éventuellement les messages d erreur ou autres du back-end 2012_eCarmed_TSS.docx version 2.0 Pg 55/69

56 constituer, éventuellement, la réponse métier en séparant l entité identifier de la carte médicale et celle du contenu et, ou le support du SPP IS valider la conformité du message par rapport au schéma du service ecarmed(frontend) 10. Fournir la réponse au service (partie générique) 2012_eCarmed_TSS.docx version 2.0 Pg 56/69

57 6 Disponibilité et performance 6.1 Performance Le service répondra le plus rapidement possible dépendant du mode de consultation utilisé et des temps de réponses qui sont fixés par le fournisseur de données. 6.2 Disponibilité Le service doit être disponible tous les jours de la semaine entre 4h du matin et 20h le soir à 99,5%. Le reste du temps, des périodes d indisponibilité peuvent survenir. Remarque : le contrat d administration de la BCSS nous demande une disponibilité de 98%. To do le service du CIN pour obtenir le statut soin de santé [AI] : scénari? SPP IS 7 pen issues Issue description le service de la Smals ne suivra pas les best practices afin d éviter de corriger ses batteries de test (cfr doc _eCarmed-Schémas_Back&FrontEnd (unicité du nom pour les mêmes éléments, réduire le nombre de niveau pour les descendances uniques, etc ) le sexe et la date de naissance ne seront pas fournis par le service de la Smals car ces deux données ne sont pas persistées au niveau des différentes versions de la carte. Attente d une réflexion à maturité pour le release 2? Au niveau du service Smals, la fonction d annulation d une carte ne sera pas disponible dans un premier temps. (Seule la fonction modify est prévue : à charge du client d adapter période et couverture ). Rmq : La BCSS propose une operation closecarmed qui n exige que le numéro de carte Prédicat : pas de description sémantique du contenu métier des champs car connu des partenaires suite aux réunions durant les dix-huit mois du projet Assigned to Smals et SPP IS Smals et SPP IS 1/10/2012 Smals et SPP IS Smals et SPP IS Document [R3] : les informations peuvent être extrapolées 2012_eCarmed_TSS.docx version 2.0 Pg 57/69

58 8 Annexes 8.1 Code de retour Ci-dessous, la liste des codes retour susceptible d être composé par le service de la BCSS. Code Value Description Type de message SG00000 DATA_FUND le service a été rendu normal N_DATA_FUND le service a été rendu normal partiellement SG N_RESULT le service n a rien fourni normal SG reject by AAApolicy le service n est pas autorisé au Fault client 8.2 Business error Business Error Codes de la BCSS Description code value / or type traitement K SG00000 DATA_FUND N_DATA_FUND Back-end ne répond pas FAULT Erreur fatale au niveau du GCS (mainframe FAULT du Registre National) Le service du registre BIS ne répond pas FAULT (PersonService) Le service répertoire sectoriel des CPAS ne FAULT répond pas Le service SSK ne répond pas FAULT NN du client non autorisé (RN) FAULT Transaction vers le RN non autorisée pour le FAULT client Warning, historic of address is maybe ECA00001 N_DATA_FUND missing, the service is not reachable. Warning, historic of civil state is maybe ECA00002 N_DATA_FUND missing, the service is not reachable. filtered backend response SG00001 N_DATA_FUND Integration is not valid for this SSIN with this SG00012 N_DATA_FUND cbenumber SSIN error (unknown niss for pcsa for this SG00012 N_DATA_FUND context) for SectorialIntegrationsPCSAService This person is dead. You can't evaluate, ECA00003 N_RESULT open or modify a card for this SSIN. You are not the manager of this card. You can't consult its contents. Please use the ECA00004 N_RESULT 2012_eCarmed_TSS.docx version 2.0 Pg 58/69

59 operation 'querycarmedanager' cfr éléments description + information SG00001 N_RESULT External information unavailable - PCSA SG00001 N_RESULT Unexpected internal error, please contact SG00001 N_RESULT the CBSS. Unexpected internal error, please contact SG00001 N_RESULT the CBSS. Xxx External information unavailable PCSA SG00001 N_RESULT (cfr Registre BCSS) SG00005 N_RESULT message/description SG00005 N_RESULT The SSIN given in request does not exist. SG00005 N_RESULT The SSIN given in request has been replaced SG00006 N_RESULT The SSIN given in request is cancelled SG00007 N_RESULT The SSIN in request is not valid (checksum SG00011 N_RESULT error) INSZ unknown for client in this legal context. SG00012 N_RESULT Incorrect legal context for this operation SG00013 N_RESULT Légal contexte incorrect SG00013 N_RESULT The given NIS/KB/CBE Number is not found SIPC0001 N_RESULT *le nouveau SSIN est fourni dans un sous élément de information : <status> <value>n_result</value> <code>sg00006</code> <description>ssin replaced</description> <information> <fieldname>newssin</fieldname > <fieldvalue>the new ssin</fieldvalue> </information> </status> Description code value traitement K SG00000 DATA_FUND N_DATA_FUND réponse métier négative SG00001 N_RESULT <status> <value>data_fund</value> <code>sg00000</code> </status> Réponse positive <status> <value>n_data_fund</value> <code>sg00000</code> <description>warning[1]</description> <information> <fieldname>warning</fieldname> <fieldvalue>nnnn-nn</fieldvalue> </information> </status> <status> <value>n_data_fund</value> <code>sg00000</code> Réponse négative <status> <value>n_result</value> <code>sg00001</code> <description>errr[1]</description> <information> <fieldname>errr</fieldname> <fieldvalue>nnnn-nn</fieldvalue> </information> </status> 2012_eCarmed_TSS.docx version 2.0 Pg 59/69