Inleiding In het kader van de overgang van AZR 2.2 naar AZR 3.0 zijn er een drietal trajecten gedefinieerd: Migratie; Conversie(periode); Kwaliteitstraject. Deze trajecten worden los van elkaar uitgevoerd maar hebben wel onderling samenhang. Met dit document willen ZN en het CVZ de samenhang tussen deze onderwerpen toelichten en verduidelijken. Trajecten Migratie Met migratie wordt het omzetten van de bestaande AZR 2.2 informatie naar AZR 3.0 bedoeld. De migratie vindt plaats in het weekend voorafgaande aan de implementatie van AZR 3.0 op 1 augustus. Conversie(periode) Zorgaanbieders die niet op 1 augustus a.s. overgaan op AZR 3.0 kunnen tot 1 november 2011 gebruik maken van de Conversiemodule om de te verzenden AZR 2.2 berichten te converteren naar AZR 3.0 berichten en de ontvangen AZR3.0 berichten om te zetten naar AZR2.2 berichten. Om onderscheid te maken wordt deze omzetting conversie genoemd, terwijl de omzetting van de bestaande AZR 2.2 gegevensset migratie wordt genoemd. Kwaliteitstraject In de keten is behoefte aan het verhogen van de kwaliteit van de AZR-gegevens in verband met (a) het operationele berichtenverkeer, (b) de implementatie van declareren en (c) het in AZR 2.2 aanpassen van een aantal situaties voor een soepele overgang naar de nieuwe functionaliteiten in AZR 3.0. Het kwaliteitstraject is bedoeld om deze kwaliteitsverhoging te bereiken. Samenhang Uiteraard is er een samenhang tussen deze trajecten. De conversieperiode kan alleen succesvol verlopen als de migratie bij ketenpartijen is uitgevoerd volgens de vastgestelde regels. Het succes van de migratie wordt voor een belangrijk deel bepaald door de uitvoering van het kwaliteitstraject. Knelpunten in de AZR 2.2 informatie moeten tijdig worden onderkend en opgelost, waarbij een belangrijk gegeven is dat de informatie bij zowel zorgkantoor als zorgaanbieder synchroon blijft. Mogelijke knelpunten in de AZR 2.2 informatie die de migratie naar AZR 3.0 raken: functies (die gezamenlijk een ZZP vormen) zijn aan meerdere aanbieders toegewezen; functies (die gezamenlijk een ZZP vormen) zijn niet met gelijke periodes geïndiceerd, toegewezen of geleverd; ontbreken van uniformiteit in toewijzingen bemoeilijkt het bepalen van het soort toewijzing in AZR 3.0. 15-07-2011 1/10
Migratie Omdat de migratie en de wijze waarop deze wordt uitgevoerd direct afhankelijk is van de implementatie van de verschillende AZR-systemen bij de diverse ketenpartijen, kan het CVZ slechts in algemene termen de migratie beschrijven. In diverse kaders bij de tekst zijn de raakvlakken met het kwaliteitstraject opgenomen. Gegevensset De te migreren gegevens zijn in principe alle cliënten/indicaties met toewijzingen waarop op of na 1 augustus zorg geleverd wordt of nog zorg te leveren is. Omdat het berichtenverkeer echter soms met enige vertraging plaats vindt, kunnen partijen besluiten om de gegevens die worden meegenomen in de migratie wat ruimer te nemen. In ieder geval geldt dat vanaf 1 augustus berichten altijd (ook als ze een periode betreffen voor 1 augustus) in AZR 3.0 formaat moeten worden verzonden. In het kader van het Kwaliteitstraject heeft ZN een ruimere definitie gehanteerd voor de minimale dataset die door Zorgkantoren wordt gebruikt. Bij de vaststelling van deze definitie zijn een aantal andere factoren meegewogen. Omzettingen In het document Conversie- en migratieregels zijn de omzettingen beschreven om zorgtoewijzingen van AZR 2.2 naar AZR 3.0 te vertalen. Daarbij zijn de omzettingen van de geïndiceerde en toegewezen functies naar zorgzwaartepakketten nadrukkelijk beschreven. Naast deze omzettingen zijn er echter ook andere omzettingen noodzakelijk die minder uitgebreid beschreven zijn en waarbij in de praktijk soms specifieke keuzes gemaakt moeten worden. Onderstaand worden mogelijkheden beschreven om een aantal specifieke situaties tijdens de migratie op te lossen. Uiteraard is het mogelijk dat in het kwaliteitstraject voorafgaand aan de migratie ook aandacht aan deze punten wordt gegeven. Relatie Soort relatie In AZR 2.2 kan de rubriek SOORT RELATIE de waarde 00 bevatten, terwijl dat in AZR 3.0 niet is toegestaan. Dit kan worden opgelost door de waarde van 00 om te zetten naar 09. Geboortedatum partner In AZR 2.2 is het mogelijk de geboortedatum van de partner leeg te laten, terwijl in AZR 3.0 door conditie CD17 wordt afgedwongen deze datum te vullen. Dit kan worden opgelost door de geboortedatum van de partner (soort relatie = 12 ) te vullen met de dummywaarde 01-01- 1900. 15-07-2011 2/10
Adres Soort adres Bij de omzetting van een adresrecord van AZR 2.2 naar AZR 3.0 kan er een probleem ontstaan met conditie CD34, die stelt dat bij een GBA- of verblijfsadres een postcode gevuld moet zijn. Indien een postcode niet of niet juist gevuld is in AZR 2.2 kan het adres niet worden omgezet als GBA- of verblijfsadres. In dit geval kan het adres worden omgezet naar een correspondentieadres, tenzij er dan geen GBA- of verblijfsadres overblijft (dat zou strijdig zijn met technische regel TR61). In dat laatste geval kan dan voor de postcode en huisnummer een dummywaarde gevuld worden (soort adres wordt dan een verblijfsadres). Huisnummertoevoeging Voor het omzetten van de huisnummertoevoeging vanuit AZR 2.2 naar een huisletter, huisnummertoevoeging en aanduiding huisnummer kan de werkwijze zoals hieronder aangegeven worden gevolgd: Indien het veld de waarde "TO" of "BIJ" bevat, dan dit invullen in het veld AANDUIDING HUISNUMMER; Indien dit niet zo is en de HUISNUMMERTOEVOEGING is een string van lengte 1, dan deze waarde invullen in het veld HUISLETTER; Indien dit niet zo is, dan de waarde invullen in het veld HUISNUMMERTOEVOEGING. Landcode In AZR 2.2 is de rubriek CODE LAND leeg als het een Nederlands adres betreft; in AZR 3.0 is de rubriek CODE LAND altijd gevuld. Dit kan als volgt worden omgezet: Indien CODE LAND in AZR 2.2 leeg is, dan omzetten naar NL; Indien de postcode in AZR 2.2 niet juist (qua formaat) gevuld is en het een Nederlands adres betreft, dan omzetten naar een dummywaarde. Toegewezen zorgeenheid Soort toewijzing Bij het bepalen van de juiste soort toewijzing geldt dat er in AZR 2.2 slechts twee mogelijkheden zijn (regulier en overbrugging) en in AZR 3.0 vijf (regulier, overbrugging, alternatief, transfer en administratief). Initieel kan de volgende vuistregel bij de omzetting worden gehanteerd: Indien in AZR 2.2 een zorgtoewijzing overbruggingszorg betreft, dan wordt de soort toewijzing in AZR 3.0 overbrugging ; Indien in AZR 2.2 een zorgtoewijzing een zorgeenheid (functie) betreft die niet in het indicatiebesluit voorkomt en het geen overbruggingszorg betreft, dan wordt de soort toewijzing in AZR 3.0 alternatief ; Indien in AZR 2.2 een zorgtoewijzing een zorgeenheid (functie) betreft die wel in het indicatiebesluit voorkomt, dan wordt de soort toewijzing in AZR 3.0 regulier. Het bepalen van de juiste soort toewijzing is afhankelijk van de werkwijze van de individuele zorgkantoren in AZR 2.2; in het kwaliteitstraject wordt na afronding van de migratie aan dit punt aandacht besteed. 15-07-2011 3/10
Geleverde zorgeenheid Leveringsstatus Initieel kunnen leveringsstatussen worden bepaald aan de hand van de in het document Conversie en Migratieregels beschreven conversiemechanisme (paragraaf 3.3.7). Het corrigeren van leveringsstatussen wordt na afronding van de migratie opgepakt als onderdeel van het kwaliteitstraject. Schema In het document Conversie- en migratieregels zijn de regels voor de migratie opgenomen. Inmiddels is op het Zorgregistratie Portaal via de Conversiemodule ook een omzetting beschikbaar die in het kader van de Migrator op basis van deze regels is ontwikkeld. Hieronder wordt deze omzetting schematisch weergegeven. Bij het omzetten van de MAZ wordt het uitgangspunt gehanteerd dat een aanbieder die in AZR 2.2 de verblijfsfunctie levert (los van overige functies) in AZR 3.0 daarmee het gehele ZZP levert. Start VBLDU geindiceerd? IB omzetten volgens extramurale regels geïndiceerd én geïndiceerd ZZP ongelijk VV, LVG en SGLVG markeren met SOORT FUNCTIE = 2 (onderdeel ZZP), overige functies markeren met SOORT FUNCTIE = 3 (vertaald) geindiceerd? IB omzetten naar ZZP + IB omzetten naar ZZP Overige functies markeren met SOORT FUNCTIE = 3 (vertaald) ZTW Figuur 1 omzetting indicatiebesluit In sommige gevallen wordt omgezet naar een functie die onderdeel is van een ZZP (en niet naar een vertaalde functie). Dit is alleen het geval als het betreffende ZZP (geïndiceerd, toegewezen of geleverd) géén VV, LVG of SGLVG is. Als er sprake is van een onbepaald ZZP zal daarom ook als onderdeel van het ZZP worden beschouwd en als aparte functie beschikbaar blijven. 15-07-2011 4/10
ZTW VBLDU toegewezen? ZTW omzetten volgens extramurale regels toegewezen én toegewezen ZZP ongelijk VV, LVG en SGLVG toegewezen? ZTW omzetten naar ZZP ZTW omzetten naar ZZP + MAZ Figuur 2 omzetting zorgtoewijzing MAZ VBLDU geleverd? MAZ omzetten volgens extramurale regels geleverd én geleverd ZZP ongelijk VV, LVG en SGLVG geleverd? MAZ omzetten naar ZZP MAZ omzetten naar ZZP + Einde Figuur 3 omzetting melding aanvang zorg 15-07-2011 5/10
Conversie(periode) De conversieperiode is bedoeld om softwareleveranciers van zorgaanbieders de logistieke ruimte te geven om voor al hun klanten de migratie met voldoende ondersteuning uit te voeren. In de periode vanaf 1 augustus tot het moment dat de migratie plaats vindt bij de zorgaanbieder geldt dat de zorgaanbieder verantwoordelijk is voor het converteren van AW35- en AW39-berichten van AZR 2.2 naar AZR 3.0, en AW33-berichten van AZR 3.0 naar AZR 2.2. Omdat vanaf 1 augustus 2011 voor de keten de afspraken gelden vanuit AZR 3.0 zullen zorgaanbieders zich operatiol moeten voegen naar die afspraken; dit heeft consequenties voor de conversie. Daarnaast zijn een aantal elementen die noodzakelijk zijn in AZR 3.0 niet beschikbaar in AZR 2.2; ook dit heeft consequenties. Bekende aandachtspunten zijn In het AW39-bericht mag in AZR 2.2 mutatiecode 11 (aanbieder weigert) niet meer gebruikt worden; Op een verstuurd AW39-bericht dat einde zorg bevat zal geen intrekkingsbericht meer volgen; In het AW35-bericht is in AZR 2.2 de rubriek gewenste startdatum niet beschikbaar, zodat in de AZR 3.0-versie niet de volledige logische sleutel kan worden bepaald; zorgkantoren zullen op basis van de wel beschikbare gegevens de match met de juiste toewijzing moeten maken; In het AW39-bericht zijn in AZR 2.2 geen kenmerken van een ZZP opgenomen, zodat hier per definitie een onbepaald ZZP wordt gebruikt. Hierdoor is daarmee in AZR 3.0 geen match te maken op basis van de logische sleutel en zal ook hier door zorgkantoren een match gemaakt moeten worden op basis van de beschikbare gegevens. Retourberichten De Conversiemodule levert voor ieder te converteren bericht een retourbericht op waarin alle validaties conform de betreffende AZR-versie zijn uitgevoerd. Een uitzondering zijn de berichtoverstijgende controles die op basis van één enkel bericht niet zijn uit te voeren. Deze controles leiden tot een retourbericht dat een gebruiker bij de zorgaanbieder kan inzien met behulp van de inzage-functie in de Conversiemodule. Kwaliteitstraject Om de overgang van AZR 2.2 naar AZR 3.0 goed te laten verlopen zijn in het kwaliteitstraject acties noodzakelijk die uiteenvallen in voorbereiding en nazorg. Het kwaliteitstraject raakt vooral zorgkantoren en zorgaanbieders. Een belangrijk aspect is, los van alle verbeteractiviteiten die worden uitgevoerd, het synchroon houden van de gegevens bij zorgkantoor en zorgaanbieder. Voorbereiding In de voorbereiding op de migratie naar AZR 3.0 is het noodzakelijk dat ketenpartijen hun systemen onderzoeken op zaken die mogelijk problemen kunnen veroorzaken tijdens de migratie. Om dit op te lossen zijn twee scenario s mogelijk: zorgkantoren sturen een nieuwe zorgtoewijzing die de herkende problemen voorkomt; zorgkantoren en zorgaanbieders doen synchroon de benodigde aanpassingen zodat de systemen in sync blijven. 15-07-2011 6/10
Knelpunten Meerdere aanbieders In AZR 2.2 kunnen de functies die samen een ZZP vormen aan meerdere aanbieders zijn toegewezen. Dit wordt door zorgkantoren opgelost door tijdig juiste toewijzingen te maken en aanbieders waar nodig onderling afspraken te laten maken. Tijdslijn Het is mogelijk dat de functies die samen een ZZP vormen in de indicatie, de zorgtoewijzing of de melding aanvang zorg niet dezelfde periode beslaan. Dit bemoeilijkt een goede vertaling van losse functies naar één ZZP. In het kwaliteitstraject is het uitgangspunt dat de periode van de verblijfsfunctie bepalend is voor de periode van het ZZP. Voor functies die qua periode geheel binnen de periode van de verblijfsfunctie passen geldt dat deze worden omgezet naar de vertaling van het ZZP met dezelfde periode als dat ZZP. Functies die een begindatum hebben die voor de begindatum van het ZZP ligt, of die een einddatum hebben die na de einddatum van het ZZP ligt, worden geknipt. Dit knippen houdt in dat het gedeelte van de functie dat binnen de periode van de verblijfsfunctie valt wordt omgezet naar de vertaling van het ZZP, en dat het deel dat buiten deze periode valt behouden blijft als zelfstandige functie. Het knippen wordt meegenomen in de omzetting tijdens de migratie, maar wordt eventueel ook al voorafgaand aan de migratie opgelost door nieuwe toewijzingen. In een bijlage wordt in meer detail in gegaan op de werkwijze rondom het knippen van functies. Nazorg Soort toewijzing Tijdens de migratie kan de soort toewijzing niet met honderd procent zekerheid worden bepaald. In de nazorg zal daarom geverifieerd moeten worden of de soort toewijzing juist is, met name bij die toewijzingen waar van een zorgaanbieder wordt verwacht dat hij de rol van dossierhouder op zich mt. Leveringsstatus Ook de leveringsstatus is tijdens de migratie initieel bepaald en zal tijdens de nazorg moeten worden nagelopen. Dit geldt ook voor de leveringsstatussen die het resultaat zijn van conversie van AZR 2.2-berichten tijdens de conversieperiode. Overig In de toelichting op het kwaliteitstraject is reeds aangegeven dat het hier acties betreft die nodig zijn in het soepel laten verlopen van de migratie, maar ook in het kader van het verbeteren van het operationele berichtenverkeer en declareren. 15-07-2011 7/10
Operatiol berichtenverkeer OB / AB BG In de AZR-keten komen de functies OB (ondersteunende begeleiding) en AB (activerende begeleiding) nog voor, terwijl deze functies vervangen zijn door andere begeleiding functies. Bij het reageren op toewijzingen met daarin een functie OB of AB moet een zorgaanbieder zich realiseren dat er feitelijk een andere functie wordt gevraagd. Om aan deze situatie een einde te maken is besloten in het kwaliteitstraject de functies OB- ALG en AB-ALG om te zetten naar BG-IND (begeleiding individueel) en de functies OB-DAG en AB-DAG om te zetten naar BG-GRP (begeleiding groep).het zorgkantoor zal op enig moment (in overleg met de betrokken zorgaanbieders) de functies omzetten en daarna conform landelijke afspraken (zie bijlage) nieuwe toewijzingen versturen. VG5 VG5 / VG8 Bij het opstellen van nieuwe ZZP s zijn VG5 en VG8 zodanig gedefinieerd dat deze deels de bestaande VG5 overlappen. Om de oude VG5 ZZP s goed te kunnen blijven gebruiken is een goede vertaling naar VG5 of VG8 noodzakelijk. Net als bij de omzetting van OB / AB zal in dit geval het zorgkantoor de omzetting uitvoeren en op basis daarvan de betreffende zorgaanbieders een nieuwe toewijzing sturen (in het geval er sprake is van VG8 ipv VG5). Declareren Zorgzwaartepakketten Een probleem bij het declareren is dat niet alle verblijf in de keten is geregistreerd als ZZP. Bij de migratie naar AZR 3.0 is dit opgelost door het onbepaalde ZZP te introduceren. Uiteindelijk zullen uiteraard alle ZZP s bepaald moeten zijn om zo de declaratie eenvoudiger te maken. De wijze waarop vastgesteld moet worden naar welk ZZP een onbepaald ZZP moet worden omgezet, moet nog worden vastgesteld. 15-07-2011 8/10
Bijlage I Knippen van functies Bij de conversie van functies naar een (geïndiceerd, toegewezen of geleverd) zorgzwaartepakket kan er sprake zijn van functies die niet gelijk lopen met de tijdslijn van de verblijfsfunctie. Hiermee wordt als volgt omgegaan: het deel van functies die binnen de geldigheidsperiode van het zorgzwaartepakket vallen, wordt beschouwd als onderdeel van het zorgzwaartepakket en volgt daarmee ook de tijdslijn van het zorgzwaartepakket; het deel van functies die buiten de geldigheidsperiode van het zorgzwaartepakket vallen, worden beschouwd als zelfstandige functies. Voorbeeld Een functie die een begindatum heeft die voor de begindatum van de functie verblijf ligt en een einddatum die na de begindatum verblijf ligt, wordt geknipt zodat een zelfstandige functie met de oorspronkelijke begindatum en als einddatum de ingangsdatum van de verblijfsfunctie overblijft. Voor de zorgtoewijzing kan het zijn dat deze functie verder opgeknipt moet worden in een stukje reguliere zorgtoewijzing (tot start verblijfsfunctie) en een overbruggingszorg toewijzing (indien de MAZ op de verblijfsfunctie later dan ingangsdatum heeft plaatsgevonden). Aandachtspunten De functie BG GRP is een bijzondere functie die indien de functie naast een ZZP zelfstandig moet kunnen worden toegewezen als geïndiceerde functie waar nodig geknipt wordt, maar in de toewijzing ongewijzigd beschikbaar blijft, tenzij er sprake is van verschil in soort toewijzing., In onderstaande figuur wordt dit visueel weergegeven. Berichtenverkeer In principe geldt dat de overblijvende zorgtoewijzingen door de betreffende zorgaanbieder op de normale wijze moeten worden afgehandeld, dus met een MAZ en MUT. Voor het sturen van een MUT op functie A wordt een uitzondering gemaakt, omdat hier bij het aanvangen van de levering van het verblijf expliciet betekent dat het leveren van functie A is beëindigd. Bron: ZN 15-07-2011 9/10
Bijlage II Omzetten OB / AB OB en AB zijn functies die niet meer gebruikt worden binnen de AWBZ en moeten vervangen worden door de functie BG. Het algoritme om de omzetting te realiseren wordt geïmplementeerd door de zorgkantoren. Indien er sprake is van een omzetting wordt dit als volgt de keten in gebracht: zorgkantoren sturen de betreffende aanbieder een AW33-bericht met daarin o een toewijzing voor BG; o de begindatum BG is de oude begindatum OB/AB. zorgaanbieders reageren op een reguliere wijze door het sturen van een AW35-bericht met daarin o een MAZ voor BG. zorgkantoren reageren op een reguliere wijze door het sturen van een CA317-bericht naar het CAK met daarin o de MAZ voor BG. Aandachtspunten Het moment van omzetting wordt bepaald door het zorgkantoor. Het is aan te bevelen dit moment duidelijk richting aanbieders te communiceren aangezien deze mogelijk een grotere hoeveelheid berichten te verwerken krijgen dan normaal. Door tijdige communicatie kan een zorgaanbieder hier tijdig op anticiperen. Het sturen van een MUT op de oorspronkelijke OB / AB toewijzing is niet toegestaan. Bron: ZN 15-07-2011 10/10