TSS Project ecarmed Dekking gezondheidszorg

17/01/2013 Author(s): Alain Tilmant

TSS – Project eCarmed Dekking gezondheidszorg

Revision History Date 10/11/2011

Ver sion 0.1

11/11/2011

0.2

12/12/2011

0.3

09/01/2012

0.4

31/01/2012

0.5

2/03/2012

0.6

8/03/2012

0.7

13/03/2012 (

0.8

30/03/2012

0.9

10/05/2012

1.0

12/06/2012

1.1

16/08/2012 01/10/2012

1.2 1.3

Description

Author

Version embryonnaire basée sur le draft du PID et la définition du service offert par la Smals à destination des CPAS affinement (réunion du 10/11/2011) • les états de la couverture « carmed » • les opérations • le contenu en général 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é • 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/2012 Schéma et logique en attente d’un premier test du service back-end (SR 147554 = service MedicalCardRegistry inaccessible) Adapter le texte pour clarifier « Carte Mé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 Ajout opération « consultCarmedAtAgreementDate » (suite réunion du 7/03/2012, besoin CAAMI) 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 Ajout de l’opération ‘history’ pour le SPP/IS et CAAMI Correction : gestion limitée aux seuls CPAS 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 • Modification du nombre maximum de message d’erreur à 400. affinement suite relecture • Ajout du code erreur 1104-35 • Nouveaux schémas côté back-end délivré le 8/06/2012 Correction URI des services ECarmedService/xxx (WSDL/XSD sont corrects) Changement du schéma du RN 25.2012.00 vs RN 25.2011.04 Le RN remplira les nouveaux éléments dès le 20/11/2012

CC ATI

2012_eCarmed_TSS_NL.docx

version 2.0

participants réunion PYV, PTR, PVB, XXX, ATI

participants réunion du 6/1/2012 CC et ATI. ATI

ATI ATI

ATI ATI

ATI

ATI ATI

Pg 1/69


17/01/2013

-

2.0

Ajout du schéma du déploiement inter-environnements Nom et prénoms remplis par le service back-end 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 GWO : Grégory Wolf, Smals PYV : Pierre-Yves Vandergeerde, SPP IS NNI : Nicolas Nicaise Smals


version 2.0

Pg 2/69


Documents connexes Document [R1] [R2]

[R3 ]

Autho r BCSS BCSS

le PID du projet eCarmed Documentation concernant les webservices BCSS (SOA-platform) http ://www.kszbcss.fgov.be/fr/bcss/page/content/websites/belgium/services/docutheque/soa/AOS. html Service Specification: Integration and use of the service eCarmed Version 0.9

SPP IS

Distribution Révision

Destinataires

0.4 0.5 0.6 0.8 0.9 1.0 1.1 and next

SPP IS, Smals, eHealth SPP IS, Smals, eHealth, CAAMI SPP IS, Smals, eHealth, CAAMI SPP IS, Smals, eHealth, CAAMI SPP IS, Smals, eHealth, CAAMI SPP IS, Smals, eHealth, CAAMI, CPAS SPP IS, Smals, eHealth, CAAMI, CPAS

Version 0.4 0.5

Approved by BCSS : ATI dans l’état (sans validation technique avec celui du back-end Smals) BCSS : ATI dans l’état (sans validation technique avec celui du back-end Smals) (pas encore accessible par la BCSS)

Date 9/01/2011 31/01/2012

0.6

0.8 0.9 1.0 1.1

2.0

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 ?) Affinement ehn vue d’une approbation des partenaires Ajout de l’opération ‘history’ pour le SPP/IS et CAAMI Correction : gestion limitée aux seuls CPAS SPP IS CAAMI eHealth CIN All partners


version 2.0

15/03/2012 30/03/2012

Pg 3/69


Revision History......................................................................................................................... 1 Documents connexes .................................................................................................................. 3 Distribution................................................................................................................................. 3 1 Doel van dit document ....................................................................................................... 6 2 Overzicht van de diensten .................................................................................................. 7 2.1 Context......................................................................................................................... 7 2.1.1 Link tussen functies, diensten en bewerkingen .................................................... 8 2.1.2 Ontwikkeling van de verschillende componenten................................................ 9 2.2 Algemene werking ..................................................................................................... 11 2.2.1 Statusdiagram ..................................................................................................... 11 2.2.2 Activiteitendiagram ............................................................................................ 12 2.2.2.1 De financiële dekking beheren (elektronische beslissing tot tenlasteneming) 12 2.2.2.2

De financiële dekking raadplegen (elektronische beslissing) ..................... 13

2.2.3 Samenvatting van de bewerkingen die door het OCMW en door de andere klanten worden gezien ...................................................................................................... 14 3 Beschrijving van de gegevens .......................................................................................... 17 3.1 Inputbericht ................................................................................................................ 17 3.2 Outputbericht ............................................................................................................. 20 4 Protocol van de dienst ...................................................................................................... 23 4.1 Dienst voor de OCMW's............................................................................................ 23 4.2 Dienst voor de HZIV en de POD MI ......................................................................... 24 4.3 Dienst voor de zorgverleners ..................................................................................... 25 4.4 Ontwikkeling tussen omgevingen ............................................................................. 26 5 Beschrijving van de uitgewisselde berichten ................................................................... 27 5.1 Ontwerp en inhoud. ................................................................................................... 27 5.1.1 Het business-verzoek.......................................................................................... 28 5.1.2 Het business-antwoord ....................................................................................... 29 5.1.3 Het antwoord bij een technische uitzondering ................................................... 30 5.2 XSD ........................................................................................................................... 32 5.2.1 De definitie van het verzoek en van het business antwoord .............................. 32 5.2.1.1 Identificatie van het verzoek en van de klant informationCustomer .......... 32 5.2.1.2

Identificatie van een beslissing eCarmedIdentifier ..................................... 33

5.2.1.3

Inhoud van een beslissing tot tenlasteneming: eCarmedContent ............... 34

5.2.1.4

Financiële dekking van de gezondheidszorg: medicalCover ...................... 35

5.2.1.5

Tussenkomst van de POD MI: refund_podmi_sppis .................................. 36

5.2.1.6

Bewerking: evaluate or open or modifyCarmed ......................................... 37

5.2.1.7

Operation : closeCarmed ............................................................................ 45

5.2.1.8

Bewerking: consultCarmed, consultCarmedHistory ................................... 46

5.2.1.9

Bewerking: consultCarmedAtAgreementDate ............................................ 47

5.2.1.10

Bewerking: queryCarmedManager ............................................................ 48

5.2.1.11

Bewerking: consultCarmedIntervention ..................................................... 49

5.2.1.12

Classificatie van het antwoord .................................................................... 52

5.2.2 De definitie van het element status .................................................................... 53 5.2.3 De definitie van het element backendMessages ................................................. 54 5.2.4 De definitie van het antwoord in de uitzonderingsgevallen ............................... 54 6 Beschikbaarheid en performantie ..................................................................................... 57 2012_eCarmed_TSS_NL.docx version 2.0 Pg 4/69


6.1 Performantie .............................................................................................................. 57 6.2 Beschikbaarheid......................................................................................................... 57 7 Open issues ....................................................................................................................... 57 8 Bijlagen ............................................................................................................................ 58 8.1 Returncode ................................................................................................................. 58 8.2 Business error ............................................................................................................ 58 8.2.1 Business Error Codes van de KSZ ..................................................................... 58 8.2.2 Business Error Codes van de back-end .............................................................. 61 9 Bijlage: voorbeelden ........................................................................................................ 64 9.1 Bewerking ‘consultCarmed’ ...................................................................................... 65 9.2 Bewerking ‘consultCarmedHistory’ .......................................................................... 66 9.3 Bewerking ‘queryCarmedManager’ .......................................................................... 67 9.4 Bewerking ‘consultCarmedIntervention’ .................................................................. 68 9.5 Bewerking ‘consultCarmedAtAgreementDate’ ........................................................ 69


version 2.0

Pg 5/69


1 Doel van dit document In dit document worden de technische vereisten en de gegevensuitwisselingen tussen de betrokken actoren beschreven: • het OCMW - beheerder: het OCMW dat de uitreiking van de eCarmed-dekking beheert, namelijk een elektronische beslissing van financiële tenlasteneming van de medische verzorging. • de andere OCMW's, • de POD MI die zijn terugbetalingsaandeel vastlegt en de beslissingen m.b.t. de tenlasteneming door de OCMW's centraliseert, • de HZIV die de prestaties controleert op basis van de facturen, de terugbetalingen doet vanwege de POD MI, zich laat terugbetalen en de afrekeningen opstuurt naar de POD MI. Deze laatste maakt de afrekeningen en stuurt het saldo van de facturen op naar het OCMW beheerder. • Smals die de DB eCarmed beheert voor rekening van de POD MI en een dienst ter beschikking stelt die via de KSZ toegankelijk is, • het NIC dat het contactpunt 1 met de verzekeringsinstellingen is om het statuut in de ziekteverzekering te achterhalen alsook de toegangspoort tot de KSZ voor de HZIV als onderaannemer van de POD MI. • het eHealth-platform dat de toegangspoort is voor de medische wereld. Het eHealthplatform biedt aan zijn klanten de mogelijkheid om zich te authentiseren aan de hand van een 'Security Token Service' en biedt diensten aan waardoor zij contact kunnen opnemen met partners zoals de KSZ, de ziekenfondsen via het NIPIN-platform (MyCarenet, enz;). • de zorgverleners voor de raadpleging van de financiële dekking (door het eHealth-platform) en het verkrijgen van een erkenningsnummer waardoor de terugbetalingen worden gegarandeerd. • de KSZ die het contactpunt is voor de OCMW's, de POD MI, eHealth, de HZIV (NIC) en het NIC De diensten die op de infrastructuur van de KSZ worden gepubliceerd, worden in dit document toegelicht. De service providers van de KSZ zijn: Smals die de database eCarmed beheert en het Rijksregister voor de identificatiegegevens en het NIC voor het statuut in de ziekteverzekering.

1

zowel van het eHealth-platform als van de KSZ


version 2.0

Pg 6/69


2 Overzicht van de diensten 2.1 Context Er zijn drie verschillende diensten beschikbaar voor elk van de actoren: de OCMW's, de HZIV en de zorgverleners. De dienst voor de OCMW's heeft als doel om de volgende bewerkingen te kunnen verrichten, nl. • vóór de toekenning van een elektronische beslissing tot tenlasteneming van de geneeskundige verzorging het terugbetalingsaandeel van de POD MI te evalueren, • een dekking gezondheidszorg eCarmed toe te kennen, • die te laten beheren door het OCMW van toekenning teneinde o de dekking aan te passen (periode en/of inhoud) o die te annuleren ingeval van foutieve toekenning o die op te schorten (release 2) o die te reactiveren (release 2) • de elektronische beslissingen inzake tenlasteneming en de volledige inhoud ervan te raadplegen o door het OCMW beheerder, o de POD MI, • het OCMW te achterhalen dat van één of meerdere elektronische beslissingen inzake de tenlasteneming van geneeskundige verstrekkingen door de andere OCMW’s beheert. De dienst voor de HZIV heeft als doel over de inhoud van de lopende beslissingen of van de verleende beslissingen inzake tenlasteneming te beschikken bij de verwerking van de facturen afkomstig van de zorgverleners. De dienst voor de POD MI heeft als doel om behalve over de beslissing van het OCMW tot toekenning of wijziging van een financiële hulp over de wettelijke toestand van de geholpen persoon te beschikken, met het oog op de centralisatie van alle toegekende financiële hulpen, de bepaling van zijn aandeel in de terugbetaling en de registratie van alle versies in een centrale gegevensbank. De dienst voor de zorgverleners heeft als doel om de informatie met betrekking tot de tenlasteneming en in voorkomend geval het erkenningsnummer als waarborg voor de terugbetaling te verkrijgen.


version 2.0

Pg 7/69


2.1.1 Link tussen functies, diensten en bewerkingen Dienst eCarmed voor de OCMW's Functies bewerkingen aan de POD MI zijn terugbetalingspercentages in een specifiek geval evaluateCarmed vragen een elektronische beslissing tot tenlasteneming nemen openCarmed een elektronische beslissing tot tenlasteneming aanpassen modifyCarmed de elektronische beslissing tot tenlasteneming verwijderen closeCarmed de inhoud van de elektronische beslissingen tot tenlasteneming consultCarmed raadplegen de inhoud met historiek van de elektronische beslissingen tot consultCarmedHistory tenlasteneming raadplegen over een lijst van de elektronische beslissingen tot tenlasteneming queryCarmedManager beschikken

Dienst eCarmed voor de HZIV en de POD MI Functies bewerkingen de inhoud van de elektronische beslissingen tot tenlasteneming consultCarmed raadplegen de inhoud met historiek van de elektronische beslissingen tot consultCarmedHistory tenlasteneming raadplegen de historische inhoud van elektronische beslissingen tot consultCarmedAtAgreementDate tenlastenming raadplegen (versie die op dat moment actief is)

Dienst eCarmed voor de zorgverleners Functies bewerkingen informatie krijgen over de toegekende tussenkomsten (elektronische consultCarmedIntervention beslissingen tot tenlasteneming) en in voorkomend geval een erkenningsnummer voor een terugbetalingswaarborg


version 2.0

Pg 8/69


2.1.2 Ontwikkeling van de verschillende componenten • • •

de klanttoepassingen: OCMW's, web-app portaal, HZIV, ziekenhuizen, zorgverleners de platformen : bus eHealth, bus KSZ, bus Sociale Zekerheid de toegelichte diensten

In het schema hierna wordt de volledige architectuur van de componenten en van de actoren getoond


version 2.0

Pg 9/69



version 2.0

Pg 10/69


2.2 Algemene werking 2.2.1 Statusdiagram In het diagram hierna staan de verschillende bewerkingen die noodzakelijk zijn voor het verkrijgen van de verschillende fasen van een financiële dekking van de gezondheidszorg.

Toelichting • fase « evaluatie dekking gezondheidszorg » Alvorens een beslissing te nemen over de financiële dekking van de gezondheidszorg wenst het OCMW de terugbetalingspercentages door de POD MI in het betrokken dossier te kennen. Het OCMW moet immers zelf het saldo van de terugbetalingen bekostigen. Deze toestand is virtueel omdat er geen gegevens worden opgeslagen de DB. • fase « toegekende dekking gezondheidszorg » Het OCMW beslist om deze dekking gezondheidszorg toe te kennen, het terugbetalingspercentage van de POD MI wordt vastgelegd en een kaartnummer wordt toegekend. Elke wijziging stemt overeen met een nieuwe versie. • fase « dekking afgeschaft » In geval van een administratieve of andere fout kan het OCMW een dekking annuleren. •

fase « dekking opgeschort »


version 2.0

Pg 11/69


Bij een wijziging van het nummer van de gerechtigde wordt de dekking geblokkeerd. (release 2)

2.2.2 Activiteitendiagram De verantwoordelijkheid van de verschillende actoren wordt in het activiteitendiagram beschreven.

2.2.2.1 De financiële dekking beheren (elektronische beslissing tot tenlasteneming) Het betreft de vier bewerkingen om een elektronische beslissing te beheren. Aan de hand van de functie • ‘evaluate’ kan door de gegevens te leveren die hebben gediend voor een beslissing tot tenlasteneming het tussenkomstaandeel van de POD MI worden bepaald. Het betreft een evaluatie die geen impact heeft op de database: er wordt geen dekking aangemaakt. • De functies 'open' en 'modify' dienen voor het aanmaken van een dekking, respectievelijk voor het wijzigen ervan, • de functie 'close' wordt gebruikt bij een foutieve uitreiking wanneer die moet worden geschrapt.


version 2.0

Pg 12/69


2.2.2.2 De financiële dekking raadplegen (elektronische beslissing) Het diagram voor de raadpleging van een medische kaart is enkel verschillend op het vlak van de tussentijdse platformen die toegang verlenen tot de dienst van de KSZ


version 2.0

Pg 13/69


2.2.3 Samenvatting van de bewerkingen die door het OCMW en door de andere klanten worden gezien Bewerkingen evaluateCarmed

doel verkrijgen van de terugbetalingspercentages die door de POD MI ten laste worden genomen

-

openCarmed

een financiële toekennen

modifyCarmed

de financiële dekking gezondheidszorg wijzigen

• • • •

closeCarmed

de financiële dekking gezondheidszorg verwijderen de beheerder van de "carmed" achterhalen

• • • •

queryCarmedManager

consultCarmed consultCarmedHistory

consultCarmedAtAgreementDate

dekking

gezondheidszorg

de dekking(en) "carmed" raadplegen • de huidige versie • alle versies

•

de versie(s) van de dekking(en) "carmed" raadplegen bij de uitreiking van het erkenningsnummer

•

•

•

•


version 2.0

mee te delen identificatienummer van het OCMW identificatienummer van de gerechtigde info over de vermoedelijke dekking identificatienummer van het OCMW identificatienummer van de gerechtigde informatie over de financiële dekking identificatienummer van het OCMW het eCarmed-nummer identificatienummer van de gerechtigde nieuwe informatie over de financiële dekking identificatienummer van het OCMW het eCarmed-nummer identificatienummer van het OCMW identificatienummer van de dekking (keuze) o het eCarmed-nummer o de gerechtigde + tijdsaanduiding identificatienummer van het OCMW/de POD MI/NIC (HZIV) identificatienummer van de dekking o het eCarmed-nummer o de gerechtigde + tijdsaanduiding identificatienummer van de POD MI/NIC [HZIV] identificatienummer van de dekking of van de gerechtigde (facultatief: een erkenningsperiode) datum van de raadpleging door de zorgverlener

Pg 14/69

te krijgen (positief geval) info over de toestand van de gerechtigde de terugbetalingspercentages POD MI info over de toestand van de gerechtigde de terugbetalingspercentages POD MI het eCarmed-nummer de versie info over de toestand van de gerechtigde de terugbetalingspercentages POD MI het carmed-nummer en de versie

aanvaard/geweigerd { identificatienummer medische kaart, OCMW beheerder} of geen resultaat

{ identificatienummer medische kaart, inhoud van de medische kaart} of geen resultaat

{ identificatienummer medische kaart, inhoud van de medische kaart} of geen resultaat


consultCarmedIntervention

de dekking "carmed" krijgen


version 2.0

• •

identificatienummer van de zorgverlener identificatienummer van de dekking (keuze) o het eCarmed-nummer o de gerechtigde + tijdsaanduiding

Pg 15/69

{ identificatienummer medische kaart, inhoud van de medische kaart, erkenningsnummer} of geen resultaat


In de toepassing ten behoeve van de OCMW's wordt gebruikt gemaakt van de dienst aangeboden door de KSZ voor het beheer van de dekking gezondheidszorg eCarmed. In de toepassingen ten behoeve van de HZIV en de POD MI wordt gebruik gemaakt van de dienst aangeboden door de KSZ voor de raadpleging van de financiële dekkingen in de gezondheidszorg. De zorgverleners gebruiken na authenticatie in het STS-systeem van het eHealth-platform de door eHealth aangeboden dienst. Deze dienst staat in interactie met die van de KSZ waarbij de identificatie van de zorgverlener wordt opgenomen (rechtspersoon of natuurlijke persoon).

Het gaat om de uitwisseling van XML-berichten waarin de SOAP-definitie in acht wordt genomen en met een specifiek XML-document per bewerking waarvan het rootelement een 'Request' of een 'Response' als suffix heeft naargelang de richting van de uitwisseling. De overeenstemming van het bericht kan aan de hand van een technisch schema worden aangetoond.


version 2.0

Pg 16/69


3 Beschrijving van de gegevens Deze beschrijving blijft algemeen omdat de inhoud door de POD MI wordt vastgelegd. In de cookbook “ Service Specification:Integration and use of the service eCarmed (Versie 0.9 of later) into an external application“ van de POD MI wordt de betekenis van de elementen beschreven. Opmerkingen : Er zijn een paar verschillen: • de naam van de dienst: de dienst van de KSZ voor alle klanten heet eCarmed, de dienst die door de KSZ wordt gebruikt en door Smals wordt aangeboden heet 'MedicalCardRegistry'. • de naam van de bewerkingen: de KSZ heeft de naam van de bewerkingen en van de inhoud vastgelegd vanuit het standpunt van de klant hierbij rekening houdende met de regels van de dienstgeoriënteerde architectuur. 3.1 Inputbericht Het verzoek tot toekenning van een dekking in de gezondheidszorg eCarmed dat van het OCMW afkomstig is omvat Mandatory Optional

Business inhoud

<proposal> <ssin> <startDate> <endDate> <medicalCard> <judicialDecisionInd> <decisionDate>

M M M M M M M

<medicalCover> <doctor> <startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <maxPrestation>


Explication cfr doc SPP IS

version 2.0

O O M M M O M M M O O O O O M

NOTHING/PARTIAL/FULL

Pg 17/69


<startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <serviceDescription> <serviceCode> <supportedDrugsDescription>

O M M M O M M M O O O O M M O O M O

<startDate>> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <serviceDescription> <serviceCode> <supportedDrugsDescription>

O M M M O M M M O O O O M M O O M O

<medicalTransportation> <startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription>

O M M M O M M M O O O O M


version 2.0

Pg 18/69


<miscellaneous> <startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <maxAmount>

O M M M O M M M O O O O

<paramedic> <startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <maxAmount> <maxPrestation> <providerList>

O M M M O M M M O O O O O O M

<startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <maxAmount>

O M M M O M M M O O O O O M


version 2.0

Pg 19/69


<prosthesis> <startDate> <endDate> <description> <decisionDate> <supportedSupplementsDescription> <maxAmount>

O M M M O M M M O O O O O M

Naast de naam van de specifieke bewerking omvat de structuur van een verzoek eenzelfde reeks gegevensblokken: • informationCustomer • legalContext • criterium met betrekking tot de operatie

3.2 Outputbericht Een antwoord bestaat uit de blokken van het verzoek gevolgd door een blok status en het "business"antwoord in geval van positief antwoord.

Bij een positief business-antwoord wordt de gewenste informatie meegedeeld in het antwoord van de KSZ: Geval 1.

2.

3. 4. 5.

Doelstelling De evaluatie van de tussenkomst van de POD MI vragen

Resultaat • de tussenkomst van de POD MI • de gegevens met betrekking tot de persoon die door de KSZ aan de POD MI wordt meegedeeld De elektronische beslissing aanmaken of • de tussenkomst van de POD MI wijzigen • het identificatienummer van de medische kaart • de gegevens met betrekking tot de persoon die door de KSZ aan de POD MI wordt meegedeeld Een elektronische beslissing (die foutief positieve status werd toegekend) annuleren De beslissingen die door andere OCMW's de identificatienummers van de werden genomen, raadplegen elektronische beslissingen die tijdens de periode werden genomen De inhoud van de beslissingen raadplegen de identificatienummers en de inhoud van de elektronische beslissingen


version 2.0

Pg 20/69


Bijkomende inlichtingen In het algemeen element status wordt de hoedanigheid van het antwoord weergegeven. In een tweede facultatief element backendMessages staan de opmerkingen die door backendtoepassing MedicalCardRegistry werden meegedeeld Inhoud

Mandatory optional

<status>

M M M O O M M O M M M M M

<description> <21ieldname> <source> DATA_FOUND/ NO DATA_FOUND/ NO RESULT ERROR/ WARNING/ INFORMATION In geval van positief business-antwoord volgens het verzoek Business antwoord <justification lang=”fr”> <justification lang=”nl> <podmi_sppis_Hospitalization_ZIV_AMI_Part> <podmi_sppis_AmbulatoryCare_ZIV_AMI_Part> <podmi_sppis_Other_ZIV_AMI_Part> <podmi_sppis_Hospitalization_PatientPart> <podmi_sppis_AmbulatoryCare_PatientPart> <podmi_sppis_Other_PatientPart> <medicalUrgencyInd> <eCarmedIdentifier> <eCarmedNumber> <ssin> <startDate> <endDate> <municipalityINS> <managedDates> 2012_eCarmed_TSS_NL.docx version 2.0 M operation evaluate open modify 0.00 / 0.50 / 1.00 M open modify consult consultHistory consultAtAgreementDate consultIntervention queryManager Pg 21/69 17/01/2013 Author(s): Alain Tilmant <eCarmedContent> O O 2012_eCarmed_TSS_NL.docx version 2.0 consult consultHistory consultAtAgreementDate consultIntervention consultIntervention Pg 22/69 17/01/2013 Author(s): Alain Tilmant 4 Protocol van de dienst De mededeling geschiedt aan de hand van webservices [SOAP-bericht] De algemene beschrijving staat op de site van de KSZ http://www.kszbcss.fgov.be/nl/bcss/page/content/websites/belgium/services/docutheque/soa/AOS.html 4.1 Dienst voor de OCMW's Service eCarmedService Namespace http://kszbcss.fgov.be/intf/ECarmedService/v1 WS per klant CPAS Bewerkingen WS 1 (WS 1) client : CPAS gestionnaire et autres CPAS (query) • • • • • • Berichten Ingangspunten extranet eCarmedPSWC.wsdl evaluateCarmed openCarmed modifyCarmed closeCarmed queryCarmedManager consultCarmed • consultCarmedHistory evaluateCarmedRequest/Response/Fault openCarmedRequest/Response/Fault modifyCarmedRequest/Response/Fault closeCarmedRequest/Response/Fault Fault queryCarmedManagerRequest/Response/Fault consultCarmedRequest/Response/Fault consultCarmedHistoryRequest/Response/Fault dvlp https://bcssksz-test.service.be/SOA4520/ ECarmedService/manageCarmed https://bcssksz-acc.service.be/SOA4520/ ECarmedService/manageCarmed prod https://bcssksz-prod.service.be/SOA4520/ ECarmedService/manageCarmed eCarmedPSWC.wsdl acpt WSDL XSD protocol BaseLegalDataV1.xsd CommonV3.xsd eCarmedTypesV3.xsd eCarmedV3.xsd rn25_Release201104.xsd rn25_Release201200.xsd HTTPS 2ways URL pour les CPAS URI //bcssksz[-[test]|[acc]].service.be/SOA4520/ ECarmedService/manageCarmed 2012_eCarmed_TSS_NL.docx version 2.0 Pg 23/69 17/01/2013 Author(s): Alain Tilmant Authentification : user/pw (user token) SSL 2ways avec proxy Smals Beveiliging OCMW xml /customerIdentification/cbeNumber /legalContext …. (chaque CPAS) manage eCarmed 4.2 Dienst voor de HZIV en de POD MI Service eCarmedService Namespace http://kszbcss.fgov.be/intf/ECarmedService/v1 WS per klant CAAMI Bewerkingen WS 2 • consultCarmed • consultCarmedHistory • consultCarmedAtAgreementDate Berichten Fault consultCarmedRequest/Response/Fault consultCarmedHistoryRequest/Response/Fault consultCarmedAtAgreementDateRequest/Response/Fault Ingangspunten KSZ dvlp WSDL (WS 2) eCarmedConsult.wsdl client : SPP IS & CAAMI b2b-test.ksz-bcss.fgov.be 85.91.184.96 accept b2b-acpt.ksz.bcss.fgov.be 85.91.184.103 prod b2b.ksz-bcss.fgov.be 85.91.184.102 eCarmedConsult.wsdl XSD BaseLegalDataV1.xsd CommonV3.xsd eCarmedTypesV3.xsd eCarmedV3.xsd rn25_Release201104.xsd rn25_Release201200.xsd protocol HTTPS 2ways URL Pour le CIN (CAAMI) URI //b2b[-test|-acpt].ksz-bcss.fgov.be :4520/ Pour le SPP/IS via le reverse proxy (cfr service CPAS) ECarmedService/consultCarmed Beveiliging HZIV via het NIC Authentification : ssl 2 ways POD MI Authentification : user/pw (user token) SSL 2ways avec proxy Smals xml customerIdentification/cbeNumber legalContext 2012_eCarmed_TSS_NL.docx version 2.0 0820563481 (CIN) 0864484487 (SPP IS) rights eCarmed Pg 24/69 17/01/2013 Author(s): Alain Tilmant 4.3 Dienst voor de zorgverleners Service eCarmedService Namespace http://kszbcss.fgov.be/intf/ECarmedService/v1 WS per klant Prestataire de soin Bewerkingen WS 3 consultCarmedIntervention Berichten Fault consultCarmedInterventionRequest/Response/Fault via het eHealth-platform (cf. info eHealth) De dienst van het platform identificeert aan de hand van de Security Token Service in het businessbericht de gebruiker: natuurlijke persoon of rechtspersoon die de zorgverlener vertegenwoordigt dvlp b2b-test.ksz-bcss.fgov.be 85.91.184.96 accept b2b-acpt.ksz.bcss.fgov.be 85.91.184.103 prod b2b.ksz-bcss.fgov.be 85.91.184.102 eCarmedConsultCare.wsdl Ingangspunt Ingangspunten KSZ WSDL (WS 3) XSD BaseLegalDataV1.xsd CommonV3.xsd eCarmedTypesV3.xsd eCarmedV3.xsd rn25_Release201104.xsd rn25_Release201200.xsd protocol HTTPS 2ways URL pour eHealth eCarmedConsultCare.wsdl client : prestataires de soin //b2b[-test|-acpt].ksz-bcss.fgov.be :4520/ URI Beveiliging ECarmedService/consultCarmedIntervention Zorgverlener Zorgeverlener ten opzichte van het eHealth-platform • token uitgereikt door STS eHealth-platform t.o.v. de KSZ • Authenticatie van het eHealth-platform : ssl 2 ways + assertion • Identificatie zorgverlener door eHealth op basis van token xml customerIdentification/cbeNumber 0809394427 legalContext rights eCarmed 2012_eCarmed_TSS_NL.docx version 2.0 Pg 25/69 17/01/2013 Author(s): Alain Tilmant 4.4 Ontwikkeling tussen omgevingen 2012_eCarmed_TSS_NL.docx version 2.0 Pg 26/69 17/01/2013 Author(s): Alain Tilmant 5 Beschrijving van de uitgewisselde berichten 5.1 Ontwerp en inhoud. Het betreft algemene principes. Het bericht XML-verzoek kan worden geïdentificeerd aan de hand van de naam van de bewerking gevolgd door Request. Het bevat steeds de elementen: • informationCustomer ; hierdoor kan de partner een ticket meedelen en kan hij zich identificeren • legalContext ; het doeleinde van de gevraagde dienst wordt bepaald alsook een element waarin een criterium wordt vastgelegd. De naam van dit element wordt aan de context van de bewerking aangepast. Het XML-antwoordbericht kan worden geïdentificeerd op basis van de naam van de bewerking gevolgd door Response. Het bevat steeds de elementen: • informationCustomer, overgenomen uit het verzoek, • informationCBSS ; waarin het ticket van de transactie en de data en uren van de verwerking worden meegedeeld, • legalContext, overgenomen uit het verzoek • het element met het criterium overgenomen uit het verzoek, • status ; met samenvatting van de verwerkingsstatus van de dienst en in voorkomend geval een element met het resultaat in geval van positief antwoord. In het geval van de dienst eCarmed hebben we na de status een facultatief element toegevoegd backendMessages om bijkomende informatie van de back-end-dienst mee te delen. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 27/69 17/01/2013 Author(s): Alain Tilmant 5.1.1 Het business-verzoek 2012_eCarmed_TSS_NL.docx version 2.0 Pg 28/69 17/01/2013 Author(s): Alain Tilmant Element Definitie Inhoud xxxRequest het rootelement van het business bericht in het element Body van het SOAP-bericht /informationCustomer ticket= [0-9,a-Z]{0,36} timestamp=2011-10-21T09:30:47.0Z customerIdentification cbeNumber : le numéro d’entreprise du CPAS legalContext= ‘registry eCarmed ’ /legalContext /critère métier 5.1.2 Het business-antwoord Het business-antwoord kan negatief of positief zijn Element /informationCustomer Definitie Inhoud het rootelement van het business bericht in het element Body van het SOAP-bericht idem zoals in het verzoek idem zoals in het verzoek 2012_eCarmed_TSS_NL.docx version 2.0 Pg 29/69 17/01/2013 Author(s): Alain Tilmant /informationCBSS /legalContext /critère métier /status idem zoals in het verzoek idem zoals in het verzoek value = • ‘DATA_FOUND’ • ‘NO_DATA_FOUND’ • ‘NO_RESULT’ idem zoals in het verzoek /réponse métier éventuel 5.1.3 Het antwoord bij een technische uitzondering Element /informationCustomer /informationCBSS /legalContext Definitie Inhoud het rootelement van het business bericht in het element Fault van het SOAP-bericht idem zoals in het verzoek idem zoals in het verzoek 2012_eCarmed_TSS_NL.docx version 2.0 Pg 30/69 cf. verzoek 17/01/2013 Author(s): Alain Tilmant /detail 2012_eCarmed_TSS_NL.docx version 2.0 Pg 31/69 17/01/2013 Author(s): Alain Tilmant 5.2 XSD Bij elke bewerking wordt zowel voor de vraag als voor het antwoord gebruik gemaakt van gemeenschappelijke subreeksen. 5.2.1 De definitie van het verzoek en van het business antwoord De gemeenschappelijke blokken 5.2.1.1 Identificatie van het verzoek en van de klant informationCustomer Element cbeNumber legalContext • • voor de OCMW's : identificatie op basis van het ondernemingsnummer voor de zorgverleners, wordt het nummer van eHealth gebruikt voor de HZIV, wordt het nummer van het NIC gebruikt • volgens het doeleinde • • ‘manage eCarmed’ (evaluate, open, modify, close, …) ‘rights eCarmed’ (consult) 2012_eCarmed_TSS_NL.docx version 2.0 Pg 32/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.2 Identificatie van een beslissing eCarmedIdentifier Element de inhoud van het element eCarmedIdentifier 2012_eCarmed_TSS_NL.docx version 2.0 Pg 33/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.3 Inhoud van een beslissing tot tenlasteneming: eCarmedContent Element de inhoud van de financiële dekking gezondheidszorg 2012_eCarmed_TSS_NL.docx version 2.0 Pg 34/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.4 Financiële dekking van de gezondheidszorg: medicalCover de inhoud van het element medicalCover 2012_eCarmed_TSS_NL.docx version 2.0 Pg 35/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.5 Tussenkomst van de POD MI: refund_podmi_sppis de inhoud van het element refund_podmi_sppis 2012_eCarmed_TSS_NL.docx version 2.0 Pg 36/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.6 Bewerking: evaluate or open or modifyCarmed Bewerking / element • evaluateCarmedRequest • openCarmedRequest • modifyCarmedRequest evaluateCarmedRequest openCarmedRequest modifyCarmedRequest 2012_eCarmed_TSS_NL.docx Dankzij deze bewerking krijgt het OCMW van de POD MI de percentages van de tenlasteneming door de Federale Staat voor de verschillende categorieën van zorgverlening. Dankzij deze bewerking kan de KSZ een verzoek van een OCMW doorsturen naar eCarmed voor de twee volgende doelen: 1. het verkrijgen van de percentages van de tenlasteneming door de POD MI voor een patiënt/gerechtigde. Deze stemmen overeen met de percentages teruggestuurd door de evaluatiefunctie op basis van eenzelfde context. 2. om een beslissing tot tenlasteneming in het eCarmed-systeem aan te maken 3. om het dekkingsnummer van deze versie 1 toe te kennen Het OCMW die de beslissing tot tenlasteneming heeft genomen, mag die beslissing wijzigen voor zover het OCMW de rechten van de gerechtigde niet vermindert; het eCarmed-systeem werd ontworpen om een terugbetalingswaarborg aan de zorgverleners aan te bieden. Een beslissing mag dus niet retroactief worden gewijzigd zodat de zorgverleners die de beslissing al zouden hebben geraadpleegd niet voor verrassingen komen te staan. De volgende wijzigingen zijn in de praktijk toegestaan: • De geldigheidsperiode van deze tenlastenneming verhogen (meest recente begindatum, oudste einddatum) - De duur van de beslissing tot hulp mag niet groter zijn dan een jaar (cf. sociale enquête): in het andere geval moet een nieuwe beslissing worden version 2.0 Pg 37/69 17/01/2013 Author(s): Alain Tilmant • • • • • • • • • • 2012_eCarmed_TSS_NL.docx aangemaakt. De geldigheidsperiode van deze tenlastenneming verminderen (oudste begindatum, meest recente einddatum) - voor zover deze periode in de toekomst ligt Een medische kaart stopzetten = als einddatum van geldigheid de volgende dag opgeven (of de begindatum, indien de kaart in de toekomst ligt). Het is niet mogelijk om een medische kaart in het verleden of op heden stop te zetten, omdat een zorgverlener vandaag de beslissing zou kunnen hebben geraadpleegd - op de dag van de stopzetting bijvoorbeeld - en prestaties zou kunnen hebben verricht op basis van de gegevens die erop staan vermeld. Ook in geval van schrapping van de beslissing naar de toekomst toe blijft deze beslissing minstens één dag geldig. De datum van de beslissing van het OCMW wijzigen De indicator "gerechtelijke beslissing" wijzigen. Opgelet, wanneer het niet over een gerechtelijke beslissing gaat, mag de begindatum van de medische kaart niet verder in het verleden liggen dan de aanmaakdatum – 45 dagen. Wijziging van het element waarin het niveau ten opzichte van het leefloon wordt aangeduid, de wijziging van dit element heeft een impact op het tussenkomstpercentage van de POD MI Een of meerdere dekkingen toevoegen De geldigheidsperiode van een dekking verhogen (oudste begindatum, meest recente einddatum) De geldigheidsperiode van deze dekking verminderen (meest recente begindatum, oudste einddatum) - voor zover deze periode in de toekomst ligt Een dekking stopzetten = de volgende dag als einddatum opgeven (of de begindatum indien de kaart in de toekomst ligt). Het is niet mogelijk om een dekking in het verleden of zelfs vandaag stop te zetten omdat een zorgverlener de kaart vandaag zou kunnen hebben geraadpleegd. Het is ook niet mogelijk om een dekking in de toekomst te schrappen - ze blijft minstens één dag geldig. De lijst met de gemachtigde zorgverleners verwijderen - met andere woorden, alle zorgverleners uit deze discipline machtigen om in het kader van deze dekking version 2.0 Pg 38/69 17/01/2013 Author(s): Alain Tilmant • • • • • • gezondheidszorg aan te bieden Zorgverleners toevoegen aan een vooraf bestaande lijst Een lijst van gemachtigde zorgverleners toevoegen wanneer er geen voorhanden is, enkel wanneer de kaart pas geldig is vanaf de volgende dag Een zorgverlener in een lijst met gemachtigde zorgverleners schrappen enkel wanneer de kaart pas geldig is vanaf de volgende dag De tekstvelden wijzigen De data van de beslissingen wijzigen De tenlasteneming door het OCMW wijzigen. Indien de kaart reeds geldig is in het verleden, is het niet mogelijk om de tussenkomst van het OCMW te verminderen (bv. een tussenkomst van 100% terugbrengen tot 0%). Het detail van proposal • evaluateCarmedRequest • openCarmedRequest 2012_eCarmed_TSS_NL.docx version 2.0 Pg 39/69 17/01/2013 Author(s): Alain Tilmant het detail van proposal • modifyCarmedRequest 2012_eCarmed_TSS_NL.docx version 2.0 Pg 40/69 17/01/2013 Author(s): Alain Tilmant Het business antwoord • evaluateCarmedResponse • openCarmedResponse • modifyCarmedResponse het element backendMessages omvat één of meerdere elementen backendMessage. Het bevat de opmerkingen van de dienst MedicalCardRegistry. @severity = ‘ERROR’ | ‘WARNING’ | ‘INFORMATION’ Er worden maximum 400 foutberichten voorzien voor de backend-dienst. De inhoud van result • evaluateCarmedResponse 2012_eCarmed_TSS_NL.docx version 2.0 Pg 41/69 17/01/2013 Author(s): Alain Tilmant De inhoud van result • openCarmedResponse • modifyCarmedResponse Er wordt een beslissingsnummer en een versie meegedeeld. Hierna worden twee soorten beslissingen beschreven De principiële beslissing Er is sprake van een principiële beslissing wanneer het OCMW een beslissing aanmaakt zonder effectieve dekking, met andere woorden, deze beslissing geeft geen recht op een financiële tussenkomst voor medische verzorging De beslissing wordt gerechtvaardigd door: o de noodzaak voor het OCMW om een termijn van 45 dagen na te leven voor het indienen van zijn beslissing tot tussenkomt bij de POD MI - deze principiële beslissing zonder effectieve dekking volstaat. o de identificatie van het voor de patiënt bevoegde OCMW, informatie die nuttig kan zijn voor de zorgverlener. o het verbod dat aldus aan de overige OCMW's wordt opgelegd om een elektronische beslissing i.v.m. deze persoon in te dienen. , Met deze beslissing is de zorgverlener voor géén enkele prestatie gedekt. De uitvoerbare beslissing De beslissing wordt uitvoerbaar wanneer minstens één dekking inzake gezondheidszorg wordt "geactiveerd". Onder activatie wordt verstaan dat het OCMW minstens één geldige dekking inzake gezondheidszorg voor een bepaalde periode heeft ingediend. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 42/69 17/01/2013 Author(s): Alain Tilmant De uitvoerbare beslissing opent het recht voor de zorgverlener om zijn schuldvorderingen in te dienen bij de HZIV, teneinde door de HZIV terugbetaald te worden ten belope van het percentage dat door de Staat ten laste wordt genomen (= de POD MI). Volgens de voorwaarden van de elektronische beslissing die de zorgverlener op elk moment kan raadplegen in het eCarmed-systeem. Dit geeft op termijn aanleiding tot de afschaffing van de bestaande formulieren van de POD MI : de formulieren B en D voor medische hulp. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 43/69 17/01/2013 Author(s): Alain Tilmant De gegevens van de gerechtigde op basis waarvan de POD MI zijn beslissing heeft genomen, worden teruggestuurd naar de klanttoepassing. Deze gegevens worden door de KSZ ingezameld, alvorens het verzoek aan de back-end-dienst wordt overgemaakt. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 44/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.7 Operation : closeCarmed closeCarmed Request Het OCMW beheerder deelt het nummer mee van de beslissing die moet worden geannuleerd. closeCarmed Response De POD MI past de beslissing aan de situatie aan, om later een facturatieverschil te vermijden indien de zorgverlener een erkenningsnummer voor tussenkomst heeft gekregen Belangrijke opmerking Tijdens de opstartfase is de back-end-dienst nog niet van plan om deze functie te ontwikkelen. De opdrachtgever, de POD MI, heeft hen dit niet uitdrukkelijk gevraagd. Er moeten eventueel specifieke instructies worden meegedeeld om de bewerking modifyCarmed te gebruiken. Het is de taak van de klanttoepassing om de informatie uit de laatste versie van de beslissing opnieuw mee te delen en hierbij elk van de periodes aan te passen. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 45/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.8 Bewerking: consultCarmed, consultCarmedHistory Request Het selectiecriterium is • • ofwel het nummer van de beslissing ofwel de gerechtigde op een datum of in een periode Response Volgens de gebruikte bewerking krijgt men de actieve versie(s) van de elektronische beslissing(en) die aan het opzoekingscriterium voldoet (voldoen). Zo niet worden alle versies meegedeeld. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 46/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.9 Bewerking: consultCarmedAtAgreementDate Request De HZIV kan volgens de te verrichten controle bepalen • de datum waarop de zorgverlener een erkenningsnummer heeft ontvangen in combinatie met o ofwel een kaartnummer (de periode ervan is gekend) o ofwel een gerechtigde (een periode kan worden meegedeeld) Response In het positief antwoord wordt bij de raadpleging door de zorgverlener de actieve versie van de historiek weergegeven. Indien er die dag een wijziging gebeurt, kunnen er twee versies worden meegedeeld omdat het uur van de raadpleging niet beschikbaar is. Indien het een periode betreft, zouden verschillende beslissingen door meerdere OCMW's voor opeenvolgende periodes kunnen worden meegedeeld. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 47/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.10 Bewerking: queryCarmedManager Request Response detail van carmed 2012_eCarmed_TSS_NL.docx version 2.0 Pg 48/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.11 Bewerking: consultCarmedIntervention Request Het eHealth-platform vult het element endUser in op basis van de authenticatie van de zorgverlener. De zorgverlener deelt het volgende mee • • ofwel het nummer van de elektronische beslissing ofwel de gerechtigde en een tijdsaanduiding van de tussenkomst o ofwel de dag o ofwel een periode Response 2012_eCarmed_TSS_NL.docx version 2.0 Pg 49/69 17/01/2013 Author(s): Alain Tilmant fragment • • • De inhoud van de beslissing wordt eventueel beperkt tot de verschillende dekkingen en tot de tussenkomst ten laste van de POD MI. De POD MI kan de toegang tot de inhoud beperken, indien het OCMW een limitatieve lijst van zorgverleners heeft opgesteld. Indien er een tussenkomst is, wordt het erkenningsnummer meegedeeld. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 50/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.11.1 Identificatie van de zorgverlener (verzoek): Wanneer de zorgverlener zich bij het eHealth-platform authentiseert aan de hand van zijn rijksregisternummer, kan na verificatie in de authentieke bronnen (RIZIV, ...) een token worden afgeleverd met het RIZIV-nummer en de betrokken medische categorie(ën). De eHealth-toepassing voert in het bericht van de bewerking consultCarmedIntervention in het element endUser een inputgegeven medicalEntity in voor elke medische categorie waarvan de zorgverlener deel uitmaakt. Gelet op het doeleinde van de dienst heeft de rechtspersoon voorrang op de natuurlijke persoon. Dit betekent dat de categorie (ziekenhuis, apotheek, ...) enkel moet worden overgemaakt wanneer die aanwezig is in de authenticatietoken. In het andere geval wordt de natuurlijke persoon meegedeeld: arts, ... . Categorie van de zorgverlener Natuurlijke persoon Centrum voor dagverzorging Groepering van verpleegkundigen Ziekenhuis Rust- en verzorgingstehuis Medisch huis Apotheek 2012_eCarmed_TSS_NL.docx Medische categorie 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 version 2.0 Pg 51/69 17/01/2013 Author(s): Alain Tilmant 5.2.1.12 Classificatie van het antwoord antwoord met erkenningsnummer status value ‘DATA_FOUND’ negatief antwoord wanneer er een beslissing bestaat status value description information fieldName fieldValue + 52ieldna backendMessages Niet-exhaustieve lijst 1105-02 1105-07 1105-08 ‘NO_DATA_FOUND’ WARNING[1] WARNING 1105-xx Betekenis Er is geen medische kaart Geen tussenkomst bepaald voor de opgegeven datum of periode De zorgverlener komt niet voor in de lijst voor een tussenkomst van het OCMW … 2012_eCarmed_TSS_NL.docx version 2.0 Pg 52/69 17/01/2013 Author(s): Alain Tilmant 5.2.2 De definitie van het element status Het element value kan drie verschillende waarden hebben : status/value DATA_FOUND NO_DATA_FOUND NO_RESULT Betekenis de dienst heeft het gevraagde geleverd de dienst heeft het gevraagde niet geleverd: zie de elementen “information” de dienst heeft niets geleverd: zie het element “status/description” Bij een onvolledig (NO_DATA_FOUND) of een negatief antwoord (NO_RESULT) status/description status/information /fieldName /fieldValue 2012_eCarmed_TSS_NL.docx ERROR[n] WARNING[n’] INFORMATION[n”] n, n’ et n” > 0 met beschrijving met ERROR/WARNING/INFORMATION ERROR/WARNING/INFORMATION de code nnnn-nn die door de back-end-dienst werd geleverd version 2.0 Pg 53/69 17/01/2013 Author(s): Alain Tilmant 5.2.3 De definitie van het element backendMessages In geval van information/fieldName met ‘ERROR’ of ‘WARNING’of ‘INFORMATION’, wordt de beschrijving van de betekenis van de foutcode van de back-end opgenomen in het element backendMessages/backendMessage @severity=’ERROR’ | ’WARNING’ | ‘INFORMATION’ reasonCode : d{4}-d{2} @lang = ‘fr’ | ‘nl’ 5.2.4 De definitie van het antwoord in de uitzonderingsgevallen Dit bericht wordt aangemaakt wanneer het antwoord niet gegenereerd wordt vanaf een antwoord van de back-end-dienst. Ofwel is het niet beschikbaar ofwel is de validatie negatief. De elementen description, information zijn aanwezig. Erratum : het aantal voorkomens van het element information mag gelijk zijn aan 400. In het schema is het aantal voorkomens verhoogd ten opzichte van de optie die gewoonlijk is vastgelegd op 15. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 54/69 17/01/2013 Author(s): Alain Tilmant De technische implementatie in detail ter informatie Dit aspect wordt volledig behandeld in het interne document PCM Proces van de KSZ generisch gedeelte 1. Het verzoek van de partner in ontvangst nemen [SSL-sessie met authenticatie van de klant] 2. Het verzoek routeren naar het verwerkingspunt conform de definitie van de dienst [cf. de WSDL]. 3. De overeenstemming van het bericht ten opzichte van het schema van de dienst controleren [cf. de XSD] 4. De blok « informationCBSS » toevoegen met het ticket van de transactie en de datum en het uur van ontvangst van het bericht. 5. Een logging van het verzoek maken. 6. De toegangsmachtiging tot de dienst met de « credentials » vragen [AAApolicy] 7. Een beroep doen op de dienst « xxxx » 8. Aan het antwoord van de dienst de datum en het uur van het antwoord toevoegen in de blok « informationCBSS » 9. Een logging van het antwoord maken 10. Het antwoord aan de klant overmaken specifiek gedeelte 1. de vier blokken van het verzoek : informationCustomer, informationCBSS, legalContext en de businesscriteria opslaan, 2. de kwaliteit van de gegevens controleren, 3. in het geval van het beheer van de kaart nagaan of het dossier toebehoort aan het OCMW klant, 4. het bericht van de back-end-dienst genereren en hierbij de gegevens van het verzoek aanpassen: • informationCustomer : de contactgegevens van de KSZ opnemen (indien de back-enddienst dit voorziet) • het RR en/of de KSZ raadplegen om de gegevens betreffende de gerechtigde in te zamelen (raadpleging xm25 met een specifieke toepassingscode van de POD MI (te verkrijgen bij het RR). • mapping tussen de gegevens 5. de conformiteit van het bericht volgens het schema van de dienst valideren MedicalRegistry ( ?)[cf. XSD] 6. een beroep doen op de back-end-dienst (toevoeging van het gedeelte WS-security namelijk handtekening van een timestamp, de BST (=certificaat) en de Body). 7. het antwoord van de dienst verwerken, 8. het antwoord voor de front-end genereren naar gelang het element result van de back-enddienst 2012_eCarmed_TSS_NL.docx version 2.0 Pg 55/69 17/01/2013 Author(s): Alain Tilmant 9. de vier blokken informationCustomer, informationCBSS, legalContext en de businesscriteria overnemen • de blok status toevoegen en eventueel de fout- of andere berichten van de back-end • het business-antwoord eventueel samenstellen door het deel identifier van de medische kaart te scheiden van het deel inhoud of de support van de POD MI • de overeenstemming van het bericht ten opzichte van het schema eCarmed (front-end) valideren 10. Het antwoord meedelen aan de dienst (generisch gedeelte) 2012_eCarmed_TSS_NL.docx version 2.0 Pg 56/69 17/01/2013 Author(s): Alain Tilmant 6 Beschikbaarheid en performantie 6.1 Performantie De dienst antwoordt zo snel mogelijk afhankelijk van de raadplegingswijze en van de responstijd die door de gegevensleverancier wordt vastgelegd. 6.2 Beschikbaarheid De dienst moet alle dagen van de week beschikbaar zijn tussen 4 uur 's morgens en 20 uur 's avonds en dit gedurende 99,5% van de tijd. Buiten deze uren zijn periodes van onbeschikbaarheid mogelijk. Opmerking: in de bestuursovereenkomst van de KSZ wordt een beschikbaarheid van 98% opgelegd. To do • de dienst van het NIC om het statuut inzake gezondheidszorg [ZIV] te krijgen : scenario  POD MI 7 Open issues Issue description • de dienst van Smals zal de “best practices” niet opvolgen om te vermijden dat hij zijn testreeksen moet verbeteren (cf. doc 20120105_eCarmed-Schémas_Back&FrontEnd”(unieke naam voor dezelfde elementen, het aantal niveaus verminderen voor de unieke afstammingen, …) • het geslacht en de geboortedatum worden niet geleverd door de dienst van Smals omdat deze gegevens niet worden bijgehouden in de verschillende versies van de kaart. Wachten op rijp beraad voor release 2? • Op het niveau van de dienst van Smals, zal de functie van annulering van een kaart in een eerste fase niet beschikbaar zijn. (Enkel de functie modify is voorzien: het is de taak van de klant om de periode en de dekking aan te passen). Opmerking: De KSZ biedt een bewerking closeCarmed aan waarvoor enkel het kaartnummer vereist is. • Predicaat: geen semantische beschrijving van de businessinhoud omdat die door de partners is gekend naar aanleiding van de vergaderingen tijdens de 18 maanden van het project 2012_eCarmed_TSS_NL.docx version 2.0 Assigned to Smals en POD MI Smals en POD MI √ 1/10/2012 Smals en POD MI Smals en POD MI Document [R3] : de informatie kan worden veralgemeend Pg 57/69 17/01/2013 Author(s): Alain Tilmant 8 Bijlagen 8.1 Returncode Hierna de lijst met de returncodes die u van de KSZ kan krijgen. Code MSG00000 Value DATA_FOUND NO_DATA_FOUND MSG000001 NO_RESULT MSG000015 reject by AAApolicy Beschrijving de dienst werd geleverd de dienst werd gedeeltelijk geleverd de dienst heeft niets geleverd de dienst is niet toegestaan voor de klant Soort bericht normal normal normal Fault 8.2 Business error 8.2.1 Business Error Codes van de KSZ Beschrijving code value / or type verwerking OK MSG00000 DATA_FOUND NO_DATA_FOUND FAULT FAULT Back-end antwoordt niet Fatale fout in het GCOS (mainframe van het Rijksregister) De dienst van het Bisregister antwoordt niet (PersonService) De dienst sectoraal repertorium van de OCMW's antwoordt niet De dienst SSKM antwoordt niet RN van de klant niet toegestaan Transactie naar het RR niet toegestaan voor de klant Warning, historic of address is maybe missing, the service is not reachable. Warning, historic of civil state is maybe missing, the service is not reachable. filtered backend response Integration is not valid for this SSIN with this cbeNumber SSIN error (unknown niss for pcsa for this context) for SectorialIntegrationsPCSAService This person is dead. You can't evaluate, 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 operation 'queryCarmedManager' 2012_eCarmed_TSS_NL.docx FAULT FAULT FAULT FAULT FAULT ECA00001 NO_DATA_FOUND ECA00002 NO_DATA_FOUND MSG00001 MSG00012 NO_DATA_FOUND NO_DATA_FOUND MSG00012 NO_DATA_FOUND ECA00003 NO_RESULT ECA00004 NO_RESULT version 2.0 Pg 58/69 17/01/2013 Author(s): Alain Tilmant cfr éléments description + information External information unavailable - PCSA Unexpected internal error, please contact the CBSS. Unexpected internal error, please contact the CBSS. Xxx External information unavailable PCSA (cfr Registre BCSS) message/description The SSIN given in request does not exist. The SSIN given in request has been replaced The SSIN given in request is cancelled The SSIN in request is not valid (checksum error) INSZ unknown for client in this legal context. Incorrect legal context for this operation Légal contexte incorrect The given NIS/KBO/CBE Number is not found MSG00001 MSG00001 MSG00001 NO_RESULT NO_RESULT NO_RESULT MSG00001 NO_RESULT MSG00001 MSG00005 MSG00005 MSG00005 MSG00006 MSG00007 MSG00011 NO_RESULT NO_RESULT NO_RESULT NO_RESULT NO_RESULT NO_RESULT NO_RESULT MSG00012 MSG00013 MSG00013 SIPC0001 NO_RESULT NO_RESULT NO_RESULT NO_RESULT *het nieuwe SSIN wordt in een subelement van information meegedeeld: <status> NO_RESULT MSG00006 <description>SSIN replaced newSSIN the new ssin Beschrijving verwerking OK code MSG00000 negatief business antwoord MSG00001 Positief antwoord <status> DATA_FOUND MSG00000 <status> NO_DATA_FOUND MSG00000 <description>WARNING[1] WARNING nnnn-nn <status> NO_DATA_FOUND MSG00000 <description>INFORMATION[1] 2012_eCarmed_TSS_NL.docx version 2.0 value DATA_FOUND NO_DATA_FOUND NO_RESULT Negatief antwoord <status> NO_RESULT MSG00001 <description>ERROR[1] ERROR nnnn-nn Pg 59/69 17/01/2013 Author(s): Alain Tilmant <60ieldname>WARNING nnnn-nn 2012_eCarmed_TSS_NL.docx version 2.0 Pg 60/69 17/01/2013 Author(s): Alain Tilmant 8.2.2 Business Error Codes van de back-end De doorstreepte barcodes zouden niet moeten worden geleverd door de dienst eCarmed Error code 1100-02 1100-03 1100-04 1100-05 1100-06 1100-07 1100-08 1100-09 1100-10 1100-11 1100-12 1100-15 1100-16 1100-17 1100-18 1100-20 1100-21 1100-25 1100-26 1100-30 1100-31 Description Le champ date de décision n’est pas complété alors qu’il est obligatoire dans le cadre de la sauvegarde d’une carte médicale. Veuillez complétez le champ date de décision et recommencer l’opération de sauvegarde de la carte médicale. Le NISS du bénéficiaire est incorrect. Le format du numéro BCE du CPAS que vous avez introduit n’est pas correct. Le numéro BCE doit toujours comporter 10 chiffres. Le format du numéro INAMI que vous avez introduit pour un médecin n’est pas correct. Le format du numéro BCE de la compagnie que vous avez introduit n’est pas correct. Le numéro BCE doit toujours comporter 10 chiffres. Le numéro de carte spécifié est incorrect. La date de fin de la carte médicale doit être supérieure ou égale à la date de début de la carte médicale. La période de validité de la couverture médicale hospitalisation doit se situer dans la période de validité de la carte médicale. La date de fin de la couverture hospitalisation doit être supérieure ou égale à la date de début de cette couverture de soins. Il ne peut pas y avoir deux numéros INAMI identiques au sein de la même couverture. Dans votre couverture médicale hospitalisation, vous avez encodé deux fois le numéro INAMI 12345678. Il ne peut pas y avoir deux numéros d’entreprise identiques au sein de la même couverture. Dans votre couverture médicale hospitalisation, vous avez encodé deux fois le numéro d’entreprise 0123456789. Il ne peut y avoir deux numéros de service identique pour un même hôpital. Le champ prise en charge de la part AMI pour la couverture médicale hospitalisation n’est pas complété alors qu’il est obligatoire dans le cadre de la sauvegarde d’une carte médicale. Veuillez complétez ce champs et recommencer l’opération de sauvegarde de la carte médicale. Le champ prise en charge de la part patient pour la couverture médicale hospitalisation n’est pas complété alors qu’il est obligatoire dans le cadre de la sauvegarde d’une carte médicale. Veuillez complétez ce champs et recommencer l’opération de sauvegarde de la carte médicale. Le champ prise en charge des suppléments pour la couverture médicale hospitalisation n’est pas complété alors qu’il est obligatoire dans le cadre de la sauvegarde d’une carte médicale. Veuillez complétez ce champs et recommencer l’opération de sauvegarde de la carte médicale. Il n’y a pas de carte médicale portant le numéro 1234567890. Le numéro BCE du CPAS que vous avez introduit est inconnu du système. La période de validité d’une carte médicale ne peut pas dépasser 12 mois. Veuillez modifier la date de début et/ou la date de fin de la carte médicale afin d’arriver à une période de validité inférieure ou égale à 12 mois. La date de début de la carte médicale ne peut pas être antérieure à 45 jours à partir de la date de son enregistrement, sauf s’il s’agit d’une décision judiciaire. Veuillez soit modifier la date de début de la carte médicale afin qu’elle soit supérieure ou égale à 01/12/2011, soit spécifier qu’il s’agit d’une décision judiciaire. Une carte médicale pour ce bénéficiaire est déjà active au sein de votre CPAS. Veuillez modifier la carte existante. Il ne peut en effet pas y avoir plus d’une carte active en même temps pour un même bénéficiaire. Une carte médicale pour ce bénéficiaire est déjà active au sein du CPAS de LIEGE ayant le numéro BCE 0123456789. Veuillez prendre contact avec ce CPAS afin qu’il arrête la 2012_eCarmed_TSS_NL.docx version 2.0 Sévérité ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR Pg 61/69 17/01/2013 Author(s): Alain Tilmant 1100-32 1100-35 1100-36 1100-37 1100-38 1101-01 1104-01 1104-05 1104-10 1104-10 1104-11 1104-12 1104-15 1104-16 1104-17 1104-20 1104-21 1104-22 1104-23 carte active avant d’en créer une nouvelle. Il ne peut en effet pas y avoir plus d’une carte active en même temps pour un même bénéficiaire. Une carte médicale pour ce bénéficiaire est déjà active au sein des CPAS suivants : LIEGE, BRUXELLES. Veuillez prendre contact avec ces CPAS afin qu’ils arrêtent leurs cartes médicales actives avant d’en créer une nouvelle. Il ne peut en effet pas y avoir plus d’une carte active en même temps pour un même bénéficiaire. L’erreur suivante s’est produite lors du calcul du pourcentage de remboursement du SPP-IS : personne décédé Une erreur technique est apparue pendant le calcul du pourcentage de remboursement du SPP-IS. Le pourcentage calculé par le SPP-IS n’est pas connu. Une erreur technique est apparue pendant le calcul du pourcentage de remboursement du SPP-IS : Le module de calcul est temporairement hors service. Veuillez réessayer plus tard. Une erreur technique est apparue pendant le calcul du pourcentage de remboursement du SPP-IS : Le pourcentage calculé par le SPP-IS est inactif. La personne que vous avez spécifiée est illégale, donc la durée maximale de chaque couverture médicale ne peut excéder 3 mois. ERROR ERROR ERROR ERROR ERROR ERROR Vous ne possédez pas le droit de modifier cette décision de prise en charge car ERROR vous n’êtes pas son propriétaire. En effet, cette décision a été créée par le CPAS LIEGE ayant le numéro BCE 0123456789. Veuillez prendre contact avec ce CPAS afin qu’il procède à la modification de la prise en charge. Vous ne pouvez pas supprimer la couverture médicale hospitalisation qui était déjà présente dans le système. Veuillez recommencer la modification en indiquant la couverture médicale hospitalisation ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de fin de la carte médicale est antérieure à la date du jour, vous ne pouvez donc plus modifier la date de fin de la carte médicale. ERROR ERROR La date de fin de la décision de prise en charge est antérieure à la date du jour, ERROR vous ne pouvez donc plus modifier la date de fin de la décision d’aide. La date de début de la carte médicale est antérieure à la date du jour, vous ne pouvez donc plus augmenter cette date mais uniquement la diminuer afin de ne pas restreindre les droits du bénéficiaire. Vous ne pouvez pas encoder de date de fin de la carte médicale antérieure à la date du jour. La date de fin de la couverture médicale hospitalisation est antérieure à la date du jour, vous ne pouvez donc pas diminuer la date de fin de cette couverture médicale. La date de début de la couverture médicale hospitalisation est antérieure à la date du jour, vous ne pouvez donc plus augmenter cette date mais uniquement la diminuer afin de ne pas restreindre les droits du bénéficiaire. Vous ne pouvez pas encoder de date de fin de la couverture médicale hospitalisation antérieure à la date du jour. La date de début de la couverture médicale de l’hôpital est antérieure à la date du jour, vous ne pouvez donc pas supprimer l’hôpital 12345678 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant cet hôpital ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture médicale de l’hôpital est antérieure à la date du jour, vous ne pouvez donc pas supprimer le service X de l’hôpital 12345678 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant ce service d’hôpital ou arrêter la carte existant et créer une nouvelle carte adaptée La date de début de la couverture médicale du médecin est antérieure à la date du jour, vous ne pouvez donc pas supprimer le médecin 12345678 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant ce médecin ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture médicale paramédicale est antérieure à la date du jour, vous ne pouvez donc pas supprimer le fournisseur paramédical 12345678 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant ce fournisseur ou arrêter la carte existant et créer une nouvelle carte adaptée. 2012_eCarmed_TSS_NL.docx version 2.0 ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR ERROR Pg 62/69 17/01/2013 Author(s): Alain Tilmant 1104-24 La date de début de la couverture médicale de médicament est antérieure à la date du jour, vous ne pouvez donc pas supprimer la pharmacie 12345678 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant cette pharmacie ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture médicale des prothèses est antérieure à la date du jour, vous ne pouvez donc pas supprimer le fournisseur de prothèse 0123456789 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant ce fournisseur ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture de transport est antérieure à la date du jour, vous ne pouvez donc pas supprimer la société de transport 0123456789 qui était déjà présent dans le système. Veuillez recommencer la modification en indiquant cette société ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture médicale hospitalisation est antérieure à la date du jour, vous ne pouvez donc pas diminuer les frais de prise en charge de la part AMI par votre CPAS. Veuillez recommencer la modification en indiquant tout comme valeur de prise en charge de la part AMI pour la couverture médicale hospitalisation ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture médicale hospitalisation est antérieure à la date du jour, vous ne pouvez donc pas diminuer les frais de prise en charge de la part AMI par votre CPAS. Veuillez recommencer la modification en indiquant tout ou partiel comme valeur de prise en charge de la part AMI pour la couverture médicale hospitalisation ou arrêter la carte existant et créer une nouvelle carte adaptée. La date de début de la couverture médicale hospitalisation est antérieure à la date du jour, vous ne pouvez donc pas ajouter une liste de restrictions pour la couverture médicale hospitalisation. Le NISS fourni dans la partie TI ne correspond pas au NISS bénéficiaire de cette décision de prise en charge médicale. ERROR 1105-01 Le bénéficiaire 99999999964 ne possède pas de carte médicale. ERROR 1105-02 Le bénéficiaire 99999999964 ne possède pas de décision de prise en charge active. La couverture docteur n'est pas présente. Vous ne pouvez pas bénéficier de remboursement dans le cadre de cette carte médicale. Cette entreprise ne peut pas voir les cartes médicales. La couverture docteur est présente mais n'est pas active pour la période du 01/02/2012 au 29/02/2012. Vous ne pouvez donc pas bénéficier de remboursement dans le cadre de cette carte médicale. La décision de prise en charge existe, mais vous n'êtes pas autorisé à bénéficier de remboursement dans le cadre de cette carte médicale La date de début ne peut être plus grande que la date de fin. La période demandée ne peut pas commencer plus d'un mois après aujourd'hui. Veuillez indiquer une date de début inférieure à 01/03/2012. L'identification du prestataire docteur doit contenir des numéros INAMI. Le résultat de la requête est trop grand, seules les 15 cartes les plus récentes ont été renvoyées. Veuillez affiner vos critères de recherche pour voir les cartes suivantes. En tant que prestataire de soins, vous devez faire une recherche par niss et période (pas par numéro de carte). WARNING WARNING 1104-25 1104-26 1104-27 1104-28 1104-29 1104-35 1105-05 1105-06 1105-07 1105-08 1105-10 1105-12 1105-13 1105-20 1105-25 2012_eCarmed_TSS_NL.docx version 2.0 ERROR ERROR ERROR ERROR ERROR ERROR ERROR WARNING WARNING ERROR ERROR ERROR WARNING ERROR Pg 63/69 17/01/2013 Author(s): Alain Tilmant 9 Bijlage: voorbeelden Versie : 1.1 (sinds 0.8): het resultaat voor consultCarmedIntervention kan mogelijks niet conform zijn wanneer het verzoek heeft plaatsgevonden op een tijdstip later dan de datum van de prestatie. De voorbeelden hierna zijn gebaseerd op een elektronische beslissing tot tenlasteneming waarvoor er een wijziging heeft plaatsgevonden. Gerechtigde Beslissingsnummer Periode Versie 1 Versie 2 Versie 3 OCMW beheerder 85120327549 000000146005 22/03/2012 01/04/2012 11/04/2012 0212344876 (EUPEN) De verzoekberichten worden niet weergegeven omdat het antwoord de selectiecriteria bevat. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 64/69 17/01/2013 Author(s): Alain Tilmant 9.1 Bewerking ‘consultCarmed’ URI =: /ECarmedService/manageCarmed Bestemd voor OCMW, POD MI, HZIV 1 – geen financiële dekking op de gevraagde datum 2012_eCarmed_TSS_NL.docx version 2.0 Pg 65/69 17/01/2013 Author(s): Alain Tilmant 9.2 Bewerking ‘consultCarmedHistory’ URI = /ECarmedService/manageCarmed Bestemd voor OCMW, POD MI, HZIV De aanvraag van een historiek voor een ssin en op een datum in de periode geeft de drie versies 2012_eCarmed_TSS_NL.docx version 2.0 Pg 66/69 17/01/2013 Author(s): Alain Tilmant 9.3 Bewerking ‘queryCarmedManager’ URI= /ECarmedService/manageCarmed Bestemd voor de OCMW’s in het algemeen De opzoeking van de dekkingen voor een ssin binnen een periode geeft de laatste versie van de verschillende dekkingen weer 2012_eCarmed_TSS_NL.docx version 2.0 Pg 67/69 17/01/2013 Author(s): Alain Tilmant 9.4 Bewerking ‘consultCarmedIntervention’ URI= /ECarmedService/consultCarmedIntervention Bestemd voor de zorgverleners, ziekenhuizen via eHealth De raadpleging van de financiële dekking op een bepaalde datum (en bij toeval de dag van een bijwerking) De zorgverlener krijgt in geval van bijwerking de vorige versie en de nieuwe versie pas vanaf de volgende dag. 2012_eCarmed_TSS_NL.docx version 2.0 Pg 68/69 17/01/2013 Author(s): Alain Tilmant 9.5 Bewerking ‘consultCarmedAtAgreementDate’ URI= /ECarmedService/consultCarmed De raadpleging van de financiële dekking toegekend in het verleden door de zorgverlener op de datum van de prestatie geeft in het geval van een bijwerking twee versies 1 en 2. (in de implementatie vóór jui 2012) 2012_eCarmed_TSS_NL.docx version 2.0 Pg 69/69

TSS Project ecarmed Dekking gezondheidszorg

Recommend Documents