Extra exemplaren kunt u verkrijgen via de website

Transcriptie

1 Rapport Samenvatting Specificaties AZR 2.2 Publicatienummer Uitgave College voor zorgverzekeringen Postbus AH Diemen Fax (020) Internet Volgnummer Afdeling Auteur VZU Doorkiesnummer Tel. (020) Bestellingen Extra exemplaren kunt u verkrijgen via de website

2

3 Inhoud 1. Inleiding...1 Achtergrond...1 Toelichting besluiten functionele specificaties...1 Versiebeheer en verzending Specificaties AZR Algemeen : Herkenbaarheid foutcodes : Vereenvoudiging berichten : Wachtlijstdefinitie : XML Implementatiestrategie : Sublocaties en AGB-codes : Gebruik van nullen : Gebruik foutcodes 0395 en : Conventie naamgeving AZR-berichten : Complexiteit bedrijfsregels : Afspraken over gebruik tekenset(s) : Controle afspraken datumvelden : Bedrijfsregel 47 aanpassen : Definitie dagtekening verzending Specificaties AZR 2.2 BSN : Verouderde tekst BSN in standaarden : Verschillen structuur GBA en AZR : Procedure correcties op BSN : Tijdig versturen MAZ : BSN en persoons- en adresgegevens : Onbekende geboortedatum : BSN: notatie indien onbekend Specificaties AZR 2.2 Indicatie : Meeverhuizende partner : Bedrijfsregel voor verwachte einddatum : Wijziging Artikel 60-verklaring afgegeven Specificaties AZR 2.2 Zorgtoewijzing : Intrekking niet herkenbaar : Zorgtoewijzingsnummer opnemen : Transferzorg : Problemen overdracht cliënt met nieuwe indicatie Specificaties AZR 2.2 Zorglevering : Begindatum functie en nabije toekomst : Sleutel AW35 uitbreiden : Melden verandering hoeveelheid zorg : Status aanlevering record : Uniek zijn van Identificatie Aanlevering...16

4 : MUT-MAZ matching : Weigeren zorg middels AW : Gebruik reden mutatie/einde zorg : Muteren VZH-VPH-VZH : Meerdere mutaties in AW : Mutatiedatum in relatie tot einddatums indicatie en zorgtoewijzing : Onderbreking Extramurale zorg : Intrekking melding einde zorg Specificaties AZR 2.2 Berekening Eigen Bijdrage : MAZ op MAZ en volgtijdelijkheid berichten : Differentiatie foutcodes Specificaties AZR 2.2 Bovenregionaal berichtenverkeer : 2 e Aanlevering bovenregionaal wordt afgekeurd : Uitwisseling oude indicaties

5 Samenvatting Het onderhavige document bevat een samenvatting van de specificaties van de nieuwe release 2.2 van de AWBZ-brede zorgregistratie. Deze release 2.2 voorziet in verbeteringen ten opzichte van de vorige release 2.1. Op hoofdlijnen zijn de verbetering als volgt te rubriceren: Gebleken onvolkomenheden in het berichtenverkeer tussen het zorgkantoor, zorgaanbieder, CAK en CIZ oplossen; Algemene verbeteringen van het berichtenverkeer; Specifieke onderwerpen of trajecten die direct om actie vragen zoals bijvoorbeeld transferzorg, sublocaties en AGB-codes, gebruik Burger service nummer (BSN). Door middel van inventarisatie, impactbepaling en verbetervoorstellen zijn in de Klankbordgroep, en in nauw overleg met de betrokken ketenpartijen de functionele specificaties ontwikkeld. De besluitvorming is voorbereid in samenspraak met de stuurgroep AZR en het programmamanagement AZR van VWS. Het CVZ heeft als tactisch beheerder van AZR begin juli 2008 de uiteindelijke beslissing genomen.

6

7 1. Inleiding Achtergrond Met de AWBZ-brede Zorgregistratie (AZR) zijn de betrokken partijen in staat het proces van indicering, zorgtoewijzing en zorglevering te ondersteunen om zo cliënten zo goed en efficiënt mogelijk van de geïndiceerde zorg te voorzien. AZR Start AZR is een uniforme systematiek voor het elektronisch uitwisselen van informatie volgens vaste standaarden tussen ketenpartijen in de AWBZ: indicatieorgaan, zorgkantoor, zorgaanbieder en CAK-bz. Deze systematiek heeft zich ontwikkeld van zorgregistratiesysteem voor het samenstellen van wachtlijsten tot instrument voor de ondersteuning van het proces van indicatiestelling, zorgtoewijzing en zorglevering. Het zorgkantoor fungeert als regionaal informatieknooppunt. De AZR bestaat in hoofdzaak uit procesbeschrijvingen, bedrijfsregels en EI-standaarden (EI: Externe Integratie) voor berichtenverkeer. In afwachting van release 3.0 en in overleg met de ketenpartijen is afgesproken te komen tot inventarisatie van verbeterpunten voor de korte en langere termijn. Deze inventarisatie was het inhoudelijke vertrekpunt voor het opstellen van de functionele specificaties. Opbouw Toelichting besluiten functionele specificaties De besluiten zoals die in dit document zijn opgenomen zijn als volgt gerangschikt: Algemeen; BSN; Specifiek voor 1 of meer processtappen binnen de AZR: indicatie, zorgtoewijzing, zorglevering en berekening eigen bijdrage; Bovenregionaal. Dit document is bedoeld als aanvulling op alle andere landelijke documenten die gebruikt worden rondom AZR: De EI-standaarden, inclusief de codetabellen, voor AZR 2.2, versienummer 1.1; Het Handboek Zorgregistratie AWBZ, AZR 2.2, inclusief bedrijfsregels; 1

8 Versiebeheer en verzending Versie 1.0 Definitief, dd 22 juli

9 2. Specificaties AZR Algemeen : Herkenbaarheid foutcodes Zowel bij de Helpdesk Zorgregistratie van het CVZ als bij de Helpdesk EI van Vektis wordt met enige regelmaat gevraagd naar de vindbaarheid van foutcodes voor de AZR-retourberichten. De toegankelijkheid van zowel de foutcodelijst als de overige AZR-codelijsten op de Vektis-site wordt verbeterd: publicatie zal voortaan plaatsvinden op WESP, Tevens wordt de bestaande foutcodelijst opgeschoond. Codelijst COD : Vereenvoudiging berichten De wens is geuit om AZR te zuiveren van overbodige informatie. In het kader van versie 2.2 is bekeken of het vereenvoudigen en of reduceren van informatie tot winst zou kunnen leiden in het verkeer tussen zorgaanbieder en zorgkantoor. Aanleiding hiervoor was het idee dat een aantal gegevens in de keten verstuurd werd zonder dat dit een duidelijk doel zou dienen. Het verwijderen van de gegevens leidt niet tot een substantiële verbetering of vereenvoudiging. De gegevenselementen worden niet in AZR 2.2 verwijderd. Nadere analyse wordt in het kader van AZR 3.0 gedaan. 3

10 : Wachtlijstdefinitie Op dit moment bestaat er geen consensus tussen zorgkantoren, VWS en het CVZ over de wachtlijstdefinitie. Hierdoor is er geen eenduidig beeld over hoe lang de wachtlijsten nu daadwerkelijk zijn, of wanneer een persoon op de wachtlijst thuishoort. Deze onduidelijkheid veroorzaakt o.a. politieke onrust over de vraag of zorgkantoren hun wettelijke taak wel goed uitvoeren en waarom er nog steeds geen regionale informatie voorhanden is over de wachttijden per regio. Daarnaast blijkt dat Vektis een technisch probleem heeft. De landelijke wachtlijstberichten die zorgkantoren naar Vektis versturen zijn grote bestanden. Deze bestanden zijn nu zo groot, dat het steeds moeilijker wordt voor zorgkantoren om deze te versturen, en voor Vektis om de bestanden op een makkelijke manier op te halen. Wachtlijstproblematiek later samen met zorgkantoren en VWS in een apart project op te pakken : XML Implementatiestrategie De huidige AZR berichtenstandaard, versie 2.1 is gebaseerd op de uitwisseling van de informatie in een platte tekst bestandsformaat ( ASCII ). Een alternatieve vorm van uitwisseling is mogelijk middels XML (extensible Markup Language), een standaard voor het definiëren van formele markuptalen voor de representatie van gestructureerde gegevens in de vorm van platte tekst. Het toepassen van XML voor AZR is een onderwerp dat op de agenda staat van het programmamanagement bij VWS. 4

11 : Sublocaties en AGB-codes Het toewijzen van zorg aan sublocaties van een zorginstelling is in AZR 2.1 gedeeltelijk mogelijk gemaakt, maar niet in de voorlooprecords van de AZRstandaarden. In alle voorlooprecords van de AW33/AW34, AW35/AW36 en AW39/AW310 zijn twee gegevenselementen toegevoegd: POSTCODE LOCATIE AWBZ (NUM276) HUISNUMMER LOCATIE AWBZ (COD775). AW33/AW34, AW35/AW36 en AW39/AW : Gebruik van nullen In de huidige standaarden van AZR 2.1 is bij een aantal gegevenselementen het gebruik van 0 (nul) toegestaan. De betekenis kan verschillend zijn. Het besluit is het gebruik van nullen NIET aan te passen, en mee te nemen bij AZR versie : Gebruik foutcodes 0395 en 4401 De documentatie AW3X en CA3X van Vektis is niet consistent in de verwijzing naar het gebruik van de foutcodes 0395 en Het gebruik van de foutcodes 0395 en 4401 corrigeren in AW3X en CA3X (standaardbeschrijving Vektis), en in de foutcodelijst. AW3X en CA3X 5

12 : Conventie naamgeving AZR-berichten In het verleden is de behoefte geuit om eens te kijken naar landelijke afspraken over de naamgeving van AZR-bestanden. AZR2.2-issue, maar doorschuiven naar AZR3.0. Met softwareleveranciers nagaan of er voldoende draagvlak bestaat voor een conventie of voor richtlijnen, waarvan de toegevoegde waarde duidelijk aantoonbaar is : Complexiteit bedrijfsregels De opbouw, onderlinge samenhang en hiërarchie van bedrijfsregels in het Handboek Zorgregistratie (AWBZ) is niet altijd even transparant. Niet opnemen in onderhoud AZR2.2, maar doorschuiven naar AZR : Afspraken over gebruik tekenset(s) In de AZR zijn geen harde afspraken gemaakt welke tekenset(s) toegestaan zijn in het elektronische berichtenverkeer. In de praktijk kan dit ertoe leiden, dat bepaalde tekens in berichten door het systeem van de ontvangende partij niet herkend of verwerkt kunnen worden. Discussie uitstellen voor de AZR2.2 en voor AZR3.0 inventariseren of er voldoende draagvlak is voor het voorschrijven van het gebruik van twee tekensets voor de flat-fileberichten, die gangbaar zijn in XML-berichten: UTF-8 en iso

13 : Controle afspraken datumvelden De beschrijving van het gebruik van de datumvelden in het berichtenverkeer is niet consistent met de standaarden. Een einddatumveld moet altijd worden beschouwd als een tot-en-met datum. Aanpassingen in de tekst en in 2 bedrijfsregels in het Handboek Zorgregistratie (AWBZ) doorvoeren. Hoofdstukken en Bedrijfsregels 82 en : Bedrijfsregel 47 aanpassen Met de huidige bedrijfsregel 47 kan bij een niet-gespecificeerde activiteitcode (9999) niet de volledige functiecode worden gecommuniceerd, terwijl het handig kan zijn om deze gegevens te communiceren. De huidige situatie blijft gehandhaafd. Bedrijfsregel 47 en de codetabel Activiteitcode incl. ZZP-code (COD743-VEKT) worden niet aangepast : Definitie dagtekening verzending Het voorlooprecord van alle AZR-standaarden bevat het gegevenselement met de naamgeving DAGTEKENING VERZENDING. In de beschrijving staat: De datum van aanmaak van de betreffende gegevens. Het verschil tussen de naamgeving en de beschrijving leidt soms tot vragen bij de helpdesk en tot meervoudige interpretatie bij ketenpartners. De beschrijving in de standaarden bij DAGTEKENING VERZENDING aanpassen in: De datum van verzending van het bericht. Alle berichten 7

14 3. Specificaties AZR 2.2 BSN : Verouderde tekst BSN in standaarden De tekst bij het gegevenselement BURGERSERVICENUMMER (BSN) CLIENT in de standaarden en de AW3x, is verouderd en moet geactualiseerd worden. Het gaat o.a. om de tekst voor toekomstig gebruik. De tekst bij de gegevenselementen BURGERSERVICENUMMER (BSN) CLIENT en BURGERSERVICENUMMER (BSN) ECHTGENOOT/PARTNER CLIENT wordt geactualiseerd. De tekst in de AW3x Standaardbeschrijving algemeen EI AWBZzorg wordt vervangen. Alle berichten : Verschillen structuur GBA en AZR Het formaat van gegevenselementen en de gegevensstructuur van de GBA verschilt van het formaat van gegevenselementen en de gegevensstructuur van de AZR. De impact van het verschil tussen het GBA en AZR is op dit moment nog niet duidelijk en hangende deze discussie zullen de gegevenselementen en de gegevensstructuur van AZR niet veranderd worden. Ketenpartijen zullen op dit gebied waarschijnlijk een aantal problemen ervaren, maar deze zijn nu nog niet (volledig) bekend. Het CVZ hoopt dat deze problemen door de ketenpartijen gemeld worden bij de helpdesk zorgregistratie. Indien ketenpartijen behoefte hebben aan meer richtlijnen op dit gebied, zal het CVZ in samenwerking met de ketenpartijen een invulinstructie over het gebruik van BSN in de AZR ontwikkelen. Het voorstel is om in het kader van AZR 3.0 hier opnieuw te beoordelen of de formaten van de GBA en AZR geüniformeerd moeten worden. 8

15 : Procedure correcties op BSN Het is mogelijk dat onjuiste gegevens omtrent BSN en persoonsgegevens in een AZR-bericht voorkomen, ondanks alle uitgevoerde controles. De voorgestelde procedure en de uitwerking hiervan worden opgenomen in een separate publicatie Handreiking BSN in AZR. In dat document is een aantal situaties verder uitgewerkt : Tijdig versturen MAZ Het versturen van de MAZ-berichten voor extramurale zorg met een BSN binnen 3 dagen na aanvang van de zorg is volgens een aantal zorgaanbieders moeilijk in het geval dat de identiteit van de cliënt vastgesteld moet worden. Prestatieindicator van 3 dagen wordt vooralsnog niet aangepast. Op het moment dat zicht is hoeveel Meldingen aanvang zorg als gevolg van het controleren van BSN te laat komen, zal de prestatie-indicator geëvalueerd worden. Voor de korte termijn zullen er geen veranderingen plaatsvinden. Op grond van ervaringscijfers zal het besluit genomen worden of, en in welke mate de periode van drie dagen bijgesteld zou moeten worden : BSN en persoons- en adresgegevens Het is niet duidelijk of de persoons- en adresgegevens van de SBV-z of de bij de- ketenpartij-bekende persoons- en adresgegevens in de AZR worden gecommuniceerd. De volgende besluiten zijn genomen: - de FAQ-lijst van het CVZ wordt aangepast; - de omschrijving van de SOORT ADRES (COD757) code 01 wordt gewijzigd; - het handboek wordt aangepast aan deze casuïstiek. - er komt een nieuwe bedrijfsregel. Nadere uitwerking wordt opgenomen in de Handreiking BSN in AZR. 9

16 Hoofdstuk Nieuwe bedrijfsregel 115 Codelijst COD : Onbekende geboortedatum Het is niet duidelijk hoe een onbekende geboortedatum van de cliënt in de AZR wordt gecommuniceerd. Het BSN en een defaultwaarde voor de onbekende geboortedatum worden gecommuniceerd in AZR. Indien een ketenpartij van de SBV-z een onbekende geboortedatum ontvangt, dan wordt deze defaultwaarde in het AZRberichtenverkeer gecommuniceerd. De defaultwaarde is Hoofdstuk : BSN: notatie indien onbekend Er moet een mogelijkheid komen om na 1 juni 2009 in AZR te melden dat een BSN niet bekend is. In de AZR-standaarden wordt een extra gegevenselement opgenomen; REDEN BSN ONBEKEND. Dit veld geeft de reden van het niet kunnen vermelden van het BSN weer, terwijl de ketenpartij wel aan alle eisen heeft voldaan. Indien een cliënt (nog) geen BSN heeft, zal het gegeven BURGERSERVICENUMMER (BSN) CLIËNT niet gevuld worden (vullen met nullen) en zal in het veld reden BSN onbekend worden vermeld wat de reden hiervan is. Nieuwe bedrijfsregel 113 toegevoegd Alle standaarden, nieuwe codetabel COD982 10

17 4. Specificaties AZR 2.2 Indicatie : Meeverhuizende partner Wanneer sprake is van een meeverhuizende partner, wordt de informatie van die partner niet (altijd) in AZR meegegeven. Zorgaanbieders hebben daar last van, en moeten buiten AZR-gegevens beheren van personen die wel gebruik maken van AWBZ-faciliteiten. aanpassing nodig in AZR. De werkprocessen en de bijbehorende software van het CIZ (GINO) zullen worden aangepast zodat partnergegevens van de meeverhuizende partner niet vergeten kunnen worden. Kleine tekstuele aanpassing in het handboek. Hoofdstuk : Bedrijfsregel voor verwachte einddatum Bij de Helpdesk zorgregistratie is gemeld dat er behoefte is aan een extra bedrijfsregel die aangeeft dat de Verwachte einddatum geïndiceerde functie niet kleiner mag zijn dan de Datum ingang geïndiceerde functie. Volgens het CIZ wordt de VERWACHTE EINDDATUM GEÏNDICEERDE FUNCTIE gevuld met dezelfde datum als DATUM GELDIGHEID (EINDE) GEÏNDICEERDE FUNCTIE. Omdat de helpdesk melding betrekking had op AZR versie 1.0 wordt geen bedrijfsregel opgenomen : Wijziging Artikel 60-verklaring afgegeven Momenteel is in de AZR een veld over de BOPZ-verklaring (COD126) opgenomen. De omschrijving en daardoor het gebruik van dit veld wordt als onduidelijk ervaren. In de standaard van het gegevenselement ARTIKEL 60-VERKLARING AFGEGEVEN (COD126) tekstuele aanpassing opnemen, zodat gebruik ervan duidelijk is. 11

18 Hoofdstuk 6.7.9, Bedrijfsregel 74 IO31/IO32, AW33/AW34, ZK31/ZK32, ZK33/ZK34 12

19 5. Specificaties AZR 2.2 Zorgtoewijzing : Intrekking niet herkenbaar Voor zorgaanbieders die gebruik maken van de website-functionaliteit van het zorgkantoor in plaats van het berichtenverkeer, is het niet duidelijk wanneer een zorgtoewijzing wordt ingetrokken. Omdat de problematiek te maken heeft met de regionale oplossingen van zorgkantoren om zorgaanbieders zonder geautomatiseerde verwerking van berichten te ondersteunen, is geen landelijk geldende oplossing aangegeven. Een mogelijke oplossing zou kunnen zijn zorgaanbieders een te sturen wanneer één of meerdere aan hen toegewezen functies worden ingetrokken : Zorgtoewijzingsnummer opnemen Op dit moment is het voor een zorgaanbieder niet duidelijk genoeg welke zorgtoewijzing leidend is wanneer een zorgkantoor meerdere zorgtoewijzingen stuurt. Hetzelfde geldt voor een zorgkantoor wanneer deze meerdere bovenregionale zorgtoewijzingen toegestuurd krijgt. De oplossing met een volgnummer is nog niet sluitend, maar dient direct na AZR 2.2 opgepakt te worden. Ter herkenning van de volgorde van zorgtoewijzingen wordt als aanvulling een nieuw veld TIJD toewijzing in het functierecord van de AW33 toegevoegd. Hoofdstuk AW33/AW34, ZK33/ZK : Transferzorg Het zichtbaar maken van transferzorg is op dit moment niet geregeld in de AZR (transferzorg is formeel gezien geen wachtlijstsituatie). Als dit wel zou gebeuren, gaat dit gepaard met een landelijk, uniform te hanteren werkwijze met bijbehorend mogelijke aanpassingen in de systematiek. 13

20 In de AZR zal voor toekomstig gebruik een aantal nieuwe velden ter herkenning van transferzorg worden opgenomen. AW33/AW34, AW35/AW36, ZK33/ZK34, ZK35/ZK : Problemen overdracht cliënt met nieuwe indicatie Zorgaanbieders ervaren problemen met de overdracht van een cliënt die een (nieuwe) indicatie voor een nieuwe zorgaanbieder krijgt (bijv. een thuiszorgcliënt die een verblijfsindicatie krijgt). Er is een gedragsregel afgesproken dat de zorgtoewijzing voor het nieuwe indicatiebesluit op dezelfde dag verstuurd moet worden als de intrekking op het oude indicatiebesluit. 14

21 6. Specificaties AZR 2.2 Zorglevering : Begindatum functie en nabije toekomst Het feit dat de BEGINDATUM FUNCTIE in een MAZ (AW35, ZK35, CA317) in de nabije toekomst mag liggen, zorgt in een aantal situaties voor problemen. is dat nabije toekomst gedefinieerd wordt als 30 dagen in de toekomst. Er komt een bedrijfsregel waar dit mee afgedwongen wordt. Hoofdstuk , en , Bedrijfsregel : Sleutel AW35 uitbreiden In één en hetzelfde MAZ bericht is het niet mogelijk om een foutief functierecord te verwijderen en tegelijkertijd een gecorrigeerd functierecord toe te voegen op dezelfde startdatum. Zowel de klasse als de opslag zullen worden opgenomen als nieuwe sleutelvelden. AW35/AW36, ZK35/ZK36, CA317/CA : Melden verandering hoeveelheid zorg Welke veranderingen in de hoeveelheid geleverde zorg moeten nu wel en welke hoeven niet met een MAZ gemeld te worden? Verduidelijkingen van het begrip schommelingen in het handboek opnemen. Toevoegen van een aantal voorbeelden wanneer wel/niet de verandering gemeld moet worden met een MAZ. Hoofdstuk

22 : Status aanlevering record De functionaliteit van status aanlevering record in de berichten AW35 en AW39 is niet waterdicht. Zowel het handboek als de tekst in de EI-standaard zullen worden aangepast. Hoofdstukken , en COD467 in alle berichten : Uniek zijn van Identificatie Aanlevering In het berichtenverkeer worden regelmatig MAZ- en MUT-berichten die (een) zorgaanbieder(s) aanbieden bij het zorgkantoor afgekeurd. De software van het zorgkantoor keurt af, omdat in de voorlooprecords van de aangeleverde berichten, die afkomstig zijn van dezelfde afzender, dezelfde Identificatie aanlevering is opgenomen. Uit de documentatie blijkt niet duidelijk of de identificatie aanlevering voor een afzender over alle berichten heen uniek moet zijn of dat de identificatie aanlevering voor een afzender per berichtsoort uniek moet zijn. Zowel de teksten in het Handboek als in de Vektis standaard aanpassen; IDENTIFICATIE AANLEVERING moet per berichtsoort uniek zijn voor de verzendende partij. Hoofdstuk toegevoegd AW35/AW36, AW39/AW310, CA317/CA318, CA319/CA320, ZK35/ZK36, ZK39/ZK : MUT-MAZ matching Er is onduidelijkheid ontstaan over hoe een MUT (AW39) gekoppeld kan worden aan een eerder geleverde MAZ (AW35). Het Handboek Zorgregistratie versie 2.1 zegt hierover iets anders dan de AW39 Vektis standaard. Het besluit is om de ontbrekende datumvelden toevoegen aan MUT (AW39). Hoofdstuk AW39/AW310, ZK39/ZK310 16

23 : Weigeren zorg middels AW39 Verzoek om te onderzoeken wat de toegevoegde waarde is van mutatiecodes 11 (zorgaanbieder weigert functie) en 12 (cliënt weigert functie). is om de codes voorlopig te handhaven totdat tussen de zorgkantoren onderling een goede procedure afgesproken is hoe hier bovenregionaal mee om te gaan. In een volgende release zouden deze codes uit de standaard kunnen verdwijnen. Dit betekent dat zorgkantoren berichten met mutatiecodes 11 en 12 niet mogen afkeuren : Gebruik reden mutatie/einde zorg Er is onduidelijkheid over de mogelijke combinaties tussen functies en redenen mutatie/einde zorg en het gebruik van de codes indicatie bestemming bij vertrek. Daarnaast wenst men meer duidelijkheid over het gebruik van de mutatiedatum in het berichtenverkeer. Gebruik Codes reden mutatie Besloten is om een aantal de codes uit de lijst te schrappen. Zie hiervoor ook casuïstiek ( Onderbreking Extramurale Zorg). De velden die betrekking hebben op bestemming bij vertrek worden uit het mutatie-/einde zorgbericht verwijderd. Vanwege bovenstaande wijzigingen wijzigen diverse bedrijfsregels. Gebruik mutatiedatum De mutatiedatum (in veel gevallen einddatum van de zorg) moet de einddatum van de zorgperiode bevatten. Hoofdstuk 12, diverse paragrafen. Diverse bedrijfsregels. AW39/AW310, ZK39/ZK310, CA319/CA320, Codelijst COD588-vek : Muteren VZH-VPH-VZH Een cliënt verblijft in een verzorgingshuis. De cliënt wordt vervolgens na een korte opname in het ziekenhuis opgenomen in een verpleeghuis. Na verloop van tijd keert de cliënt weer terug in het verzorgingshuis. Hoe dienen de zorginstellingen hier mee om te gaan? 17

24 Verduidelijking opnemen in het handboek in de vorm van enkele voorbeelden. Hoofdstuk : Meerdere mutaties in AW39 Mogelijkheid onderzoeken om meerdere mutaties voor één functie in één mutatiebericht op te nemen. Indien in één mutatiebericht voor een cliënt zowel reden mutatie tijdelijke afwezigheid als onderbroken functie wordt hervat wordt gebruikt, dan treedt er de fout record dubbel opgenomen (0803) op. In de casus Muteren van VZH-VPH-VZH is besloten om de codes 03 (tijdelijke afwezigheid) en 15 (onderbroken functie wordt hervat) niet meer voor te schrijven. De sleutel in de AW39 hoeft daarom niet aangepast te worden : Mutatiedatum in relatie tot einddatums indicatie en zorgtoewijzing Er is geen controle op de MUTATIEDATUM AWBZ-ZORG ten opzichte van de einddatum van de zorgperiode. Nieuwe bedrijfsregel toevoegen, waardoor controles op de MUTATIEDATUM AWBZ- ZORG ten opzichte van einddatum indicatie en einddatum zorgtoewijzing mogelijk worden. Nieuwe bedrijfsregel : Onderbreking Extramurale zorg Zorgaanbieders worden verplicht na de melding einde zorg (bv. mutatiebericht code 16), ook nog de zorg af te melden op het zorgportaal van het zorgkantoor. Zorgaanbieders worden verplicht een onderbreking van extramurale zorg door bv. ziekenhuisopname middels een melding einde zorg (mutatiecode 16) te melden bij het zorgkantoor. Als argument hiervoor wordt het verloop van de 18

25 eigen bijdrage van de cliënt genoemd. Zorgaanbieders die gebruik maken van de website van het zorgkantoor moeten bij een aantal websites de zorgtoewijzing sluiten. Omdat het in sommige gevallen niet handig is dat de zorgtoewijzing ingetrokken wordt, zijn aangepaste codes voor reden mutatie uitgegeven. Hoofdstuk , en Bedrijfsregels: 9, 102 en103. Bedrijfsregels 98 en 104 zijn vervallen. Codelijst COD588-vek : Intrekking melding einde zorg Een eenmaal ten onrechte verzonden melding einde zorg is niet meer ongedaan te maken is om voor AZR 2.2 geen mogelijkheid in het berichtenverkeer op te nemen om foutieve meldingen einde zorg ongedaan te maken. 19

26 7. Specificaties AZR 2.2 Berekening Eigen Bijdrage : MAZ op MAZ en volgtijdelijkheid berichten In de praktijk is het mogelijk dat bij het CAK twee (2) MAZ-berichten voor één (1) cliënt, afkomstig van twee verschillende zorgaanbieders binnenkomen. Daarnaast komt het voor dat de MAZ- en MUT-berichten afkomstig van één (1) zorgaanbieder, voor één (1) cliënt niet in de juiste volgorde bij het CAK binnenkomen. Het genomen besluit gaat uit van een pragmatische aanpak bij het CAK én gebruik van uniforme werkwijzen. In het Handboek zullen aanvullende beschrijvingen worden opgenomen. Hoofdstuk : Differentiatie foutcodes De fouten ten aanzien van het CA-berichten, die CAK teruggeeft aan de zorgkantoren zijn te generiek. Er bestaat een grote behoefte om tot differentiatie te komen in te gebruiken foutcodes. Er wordt een aantal specifieke foutsoorten ten behoeve van de CA317 toegevoegd aan de foutcodetabel. CA318, CA320, COD282 20

27 8. Specificaties AZR 2.2 Bovenregionaal berichtenverkeer : 2 e Aanlevering bovenregionaal wordt afgekeurd Sommige zorgkantoren keuren elke 2 e aanlevering van een ZK33 bericht voor dezelfde cliënt af terwijl de wijziging van de zorgtoewijzing wel van belang is voor de zorgaanbieder uit de regio van het zorgkantoor. Besloten is tot aanpassing van applicaties van zorgkantoren zodat meerdere bovenregionale zorgtoewijzingen voor dezelfde cliënt verwerkt kunnen worden. Het handboek wordt aangevuld. Hoofdstuk : Uitwisseling oude indicaties Sommige zorgkantoren kunnen oude zorgtoewijzingen niet meer bovenregionaal versturen omdat de indicatie is verlopen of geveegd naar aanleiding van een nieuw besluit. De oude zorgtoewijzing was wel bestemd voor een bovenregionale zorgaanbieder maar deze heeft de zorgtoewijzing nooit gekregen en kan daar dus ook geen melding aanvang zorg meer op leveren. Een soortgelijk probleem is het versturen van een melding aanvang zorg naar een bovenregionaal zorgkantoor wanneer de betreffende indicatie verlopen of geveegd is naar aanleiding van een nieuw besluit. Het besluit is om zorgkantoren te verplichten om ook oude zorgtoewijzingen bovenregionaal te kunnen versturen en om bovenregionale meldingen aanvang zorg op oude zorgtoewijzingen te kunnen verwerken. Hoofdstuk

28

29 Bijlage : Verbeterpunten Casuïstiek Opstellen procesmodel (ist) Berichtenverkeer Zorgkantoor naar CAK Casuïstiek BSN Verouderde tekst BSN in standaarden MAZ op MAZ; probleem verschillende zorgaanbieders zijn niet herkenbaar// Overplaatsing o.a. bij 2 ZZP s in 1 besluit// Volgtijdelijkheid berichten Berichtenverkeer CAK naar zorgkantoor Differentiatie foutcodes. : foutcodes zijn onvoldoende dekkend Bovenregionaal (ZK naar ZK) BSN met als eerste positie een nul (0) (FAQ-besluit) BSN en unieke ID (FAQ-besluit) verschillen structuur SBV-z en AZR Procedure correcties op BSN (uitspraak ZN) : 2 e aanlevering wordt afgekeurd(mutatiestroom onvolledig) tijdig versturen van de MAZ : regel over verantwoordelijkheid muteren ZK 33 ontbreekt BSN en persoons- en adresgegevens Verhuizing (PGB) levert probleem BSN: onbekende geboortedatum Overbrugging proces/-beleid BSN: notatie indien onbekend CIZ Zorgkantoren/Zorgkantoren CIZ Sublocaties en AGB-codes Zorgkantoor naar Zorgaanbieder Sublocaties en AGB-codes Intrekking niet herkenbaar (onderscheid wel en geen berichtenverkeer) Lijst Onderhoudspunten Overlap Zorgtoewijzing (o.a. oplossing van volgnummer) Gebruik "Status aanlevering record" Overlap Zorgtoewijzing (uitwerking besluit KBG 15-04) Intrekking Melding Einde zorg Gebruik zorgtoewijzing-volgnummer Uitwisseling oude indicaties Uitwerking casus 3.4 Wijziging van leveringsvorm Transferzorg in AZR Meeverhuizende partner Transferzorg uitwerken Bedrijfsregel voor verwachte einddatum Gebruik foutcodes Wijziging "Artikel 60-verklaring afgegeven" Herkenbaarheid foutcodes (ondersteuning) Gebruik van nullen Zorgaanbieder naar zorgkantoor Gebruik foutcodes 0395 en 4401 AW 39 verder uitwerken (ook bovenregionaal) Datum dagtekening specificeren MUT-MAZ matching Conventie naamgeving AZR-bestanden Gebruik van code 11 en 12 (reden mutatie) Complexiteit bedrijfsregels Toegestane combinaties van functies en reden mutatie Afspraken over gebruik tekenset(s) Verwerking VZH-VPH-VZH Sleutel AW35 uitbreiden Melden einde zorg Sleutel AW39 uitbreiden 1

30 Melden schommelingen Controleren afspraken datumvelden (t/m) Mutatiedatum in relatie tot einddatum indicatie Geleverde klasse <= toegewezen klasse Mutatieberichten bij/na einde zorg // Onderbreking Extramurale Zorg Bedrijfsregel 47: onderscheid in activiteitcode Bedrijfsregel 101 Aanpassen bedrijfsregel 36 voor AW35 Vereenvoudiging Regels betreffende verschillende aanvraagnummers voor 1 cliënt, in 1 bericht Vereenvoudigen alle berichten door overbodige gegevens weg te halen Gegevenselement "Identificatie aanlevering" altijd uniek Wachtlijst Sleuteldatum icm voorgaande opname Wachtlijstdefinitie, problematische wachtlijsten, omvang en verwerking AW317 Lijst Aandachts- en knelpunten Beleidsregels VP en PV Ingekomen softwareleveranciers Beleidsregels (o.a. VP en PV aanpassen in activiteitcode tabel) Opnemen uitwerken mutatieverkeer (geen opvolging aan doorgeven NAW) Handboek Verkeerde AGB codes vanuit toewijzing leiden tot veel werk XML implementatiestrategie Opnemen Server to Server verkeer (3.0) XML implementatiestrategie Handboek doelgroepgericht maken VPT Starten infomatiesessies AZR voor admin personeel bij zorgaanbieders VPT in AZR 2.2 Ingekomen Uvit per mail gebruik AGB codes (Vraag doorgestuurd per mail) 2