HL7
2
0

Diagnose Behandel Combinaties (DBC)

Deze bijlage van de Nederlandse implementatierichtlijnen voor HL7 versie 2.4 beschrijft berichten die samenhangen met alle vormen van gegevensuitwisseling rond Diagnose Behandel Combinaties (DBC’s), inclusief de daarmee samenhangende concepten (met name het zorgtraject en de verwijzing) conform specificaties opgesteld door het DBC2003 project en DBC-Onderhoud.

Deze specificaties zijn mede gebaseerd op de volgende documenten:

  1. Projectbeschrijving  HL7 Projectbureau Toetsing nieuw model DBC2003 en opstellen implementatierichtlijnen voor toepassing in HL7 berichtenverkeer, versie 2.0 d.d. 12 december 2001.
  2. Data- en procesmodel DBC Registratie d.d. 6-12-2001, DBC2003.
  3. Specificaties HL7 Versie 2.4, ANSI Standard 6-10-2000.

Voor een uitgebreide toelichting op het data- en procesmodel voor DBC’s, wordt verwezen naar: http://www.dbconderhoud.nl

Binnen de gegevensbeschrijving voor DBC’s is sprake van twee verschillende datamodellen. Het minimale datamodel bevat alleen de verplichte velden voor DBC-registratie. Dit is hieronder weergegeven.

Daarnaast is er het uitgebreide datamodel, dat aanvullende informatie bevat over o.a. verwijzingen, verantwoordelijkheidsperioden en mutaties van DBC-typeringen. Dit ziet er schematisch als volgt uit:

Bij het uitwerken van de HL7 specificaties is uitgegaan van de mogelijkheid om het uitgebreide datamodel te ondersteunen, hoewel de berichten zodanig zijn opgebouwd dat ook volstaan kan worden met enkel de gegevenselementen uit het minimale datamodel. Daar waar nodig is het onderscheid expliciet aangegeven.

Scope

Deze tekst bevat specificaties en implementatierichtlijnen voor vier berichtcategorieën, te weten:

  • DBC-mutatieberichten
    Deze berichten vormen de kern van het document en zijn bedoeld voor het doorgeven van mutaties met betrekking tot zorg- en DBC-trajecten. De berichten zijn gebaseerd op toepassing van hoofdstuk 12 van de internationale HL7 standaard, met een aantal uitbreidingen om alle benodigde informatie op te nemen.
  • DBC-opvraagberichten
    Dit betreft berichten voor het actief opvragen van informatie rond zorg- en DBC-trajecten door een opvragend systeem. Dit gebeurt conform de algemene specificaties voor queries uit hoofdstuk 5 van HL7.
  • DBC-declaratieberichten
    Binnenkort zullen DBC-trajecten ook moeten worden gedeclareerd aan de ziekenhuisfacturering. Deze ­ca­tegorie berichten is gericht op het aanleveren van DBC-declaratiecodes aan het factureringssysteem.
  • Berichten met DBC-referenties
    Diverse andere berichtsoorten moeten kunnen worden gekoppeld aan een specifiek zorg- of DBC-traject, met als doel om alle administratieve en zorgactiviteiten te kunnen relateren aan een bepaald ziektegeval. In dit hoofdstuk wordt aangegeven hoe deze berichtsoorten kunnen worden voorzien van een DBC-referentie.

In de hiernavolgende paragrafen worden een aantal aspecten rond het functioneren van applicaties met betrekking tot bovenstaande berichten nader toegelicht. De betekenis van de concepten uit de DBC-specificaties wordt bekend verondersteld, zodat de nadruk ligt op het beschrijven van de communicatie tussen applicaties. Zo ontstaat als het ware een communicatiemodel, als aanvulling op het data- en procesmodel van DBC-Onderhoud.

Applicatierollen, interacties en trigger events

Applicatierollen

Bij het gebruik van de berichten uit dit hoofdstuk worden zes rollen onderscheiden die applicaties kunnen hebben. In veel gevallen kan dezelfde applicatie, afhankelijk van de transactie, meerdere rollen hebben.

  • DBC vastleggende rol
    De vastleggende rol hoort bij applicaties die actief zorgen voor het vastleggen van nieuwe DBC-gegevens of mutaties op bestaande DBC-gegevens. Mogelijk zijn hierin nog subrollen te onderscheiden voor appli­caties die slechts specifieke gegevens registreren of die slechts bepaalde toestandsveranderingen ondersteunen, maar vooralsnog wordt uitgegaan van applicaties die de volledige registratie rond DBC’s dekken.In de praktijk kan bovengenoemde rol worden vervuld door een ‘bestaande’ module, zoals een afspraken­systeem of een factureringssysteem, maar het kan ook een specifieke DBC-registratiemodule betreffen.
  • DBC volgende rol
    De volgende rol hoort bij applicaties die op de één of andere manier geïnteresseerd zijn in DBC-gegevens en deze automatisch ontvangen van een applicatie die DBC-gegevens vastlegt, zoals hierboven bedoeld.Dit kunnen systemen zijn waarbinnen andere gegevens aan zorg- of DBC-trajecten worden gekoppeld, zoals hieronder bedoeld met de refererende rol. Ook kan het gaan om systemen waarbinnen de financiële afhandeling van DBC’s plaatsvindt, zoals hieronder bedoeld met de declarerende rol. In feite zijn de refererende en declarerende rol (voor zover het de inkomende berichten betreft) dus deelrollen van de volgende rol.De volgende rol is algemener in de zin dat niets wordt verondersteld over de aard van de verwerking van DBC-gegevens en de uitgaande berichten. Dit kunnen bijv. EPD-systemen zijn die de DBC-gegevens puur als patiëntgerichte informatie ontvangen en presenteren. Ook kan de volgende rol samenvallen met de vastleggende rol, als meerdere systemen (een deel van) de DBC-gegevens beheert en onderling uitwisselt.
  • DBC opvragende rol
    De opvragende rol hoort bij applicaties die actief DBC-gegevens opvragen bij applicaties die DBC’s vastleggen. Dit gebeurt op basis van een zogenaamde query, waarop een bijbehorend antwoord volgt.Net als bij de volgende rol hierboven kunnen systemen die refereren aan zorg- of DBC-trajecten of die de DBC’s financieel verwerken ook fungeren in de opvragende rol, als zij door middel van een query aan de benodigde DBC-gegevens komen. Dit is een voorbeeld van de bekende dualiteit tussen mutaties en queries
  • DBC refererende rol
    Elke patiënt wordt binnen een zorgorganisatie geïdentificeerd door het bijbehorende patiëntnummer. Dit patiëntnummer wordt dan ook meegegeven als informatie-element in elk HL7 bericht dat gerelateerd is aan een specifieke patiënt (vrijwel altijd door het PID segment op te nemen in het betreffende bericht).Hetzelfde geldt voor bijv. klinische opnames, die door het meesturen van een PV1 segment als referentie kunnen worden toegevoegd aan andere administratieve en zorgactiviteiten binnen het ziekenhuis.Op dezelfde wijze kan het nodig zijn om activiteiten te koppelen aan een specifiek zorg- of DBC-traject, bijv. ten behoeve van bepaling van zorgprofielen of kostprijzen. Dergelijke informatie ontstaat dus vaak na statistische bewerking achteraf (bijv. in een datawarehouse), maar vereist een referentie op het moment van ontstaan van de brongegevens. Dit hangt ook samen met de beoogde methodiek voor het bepalen van DBC-declaratiecodes, die gebaseerd is op de combinatie van DBC-trajecten en daaraan gerelateerde activiteiten.De refererende rol kan dus gespeeld worden door elk systeem dat gegevens voortbrengt die zijn te relateren aan een bepaald ziektegeval (en dus DBC-traject). Voorbeelden hiervan zijn poliklinische afspraak- en registratiesystemen, opnamesystemen, OK systemen, diverse soorten labsystemen en radiologiesystemen. De referentie naar een zorg- of DBC-traject (door middel van een unieke identificatie) wordt dan mee­gestuurd met de normale berichten voor het uitwisselen van de kernactiviteiten van de betreffende systemen.
  • DBC declarerende rol
    De declarerende rol betreft applicaties die DBC’s in de vorm van financiële transacties verzenden ten be­hoeve van facturering. Meestal is de ontvanger van de declaraties het factureringssysteem van de instelling.Per 1 januari 2003 is aan DBC’s een directe financiële vergoeding gekoppeld. Declaratie aan het factureringssysteem vindt dan plaats op basis van zogenaamde DBC-declaratiecodes, die worden afgeleid uit de DBC-dataset en de aan het DBC-traject gerelateerde activiteiten.
  • DBC facturerende rol
    De facturerende rol wordt op dit moment niet verder uitgewerkt, maar hoort bij applicaties die DBC’s factureren aan debiteuren (dit gebeurt vrijwel altijd door het factureringssysteem van de instelling). Bij elektronische communicatie zullen de ontvangende debiteuren met name de zorgverzekeraars zijn.Momenteel vindt verzending van facturen (factuurregels) meestal plaats via de zogenaamde VEKTIS 5 standaard. Er zijn voorbereidingen in gang gezet voor ontwikkeling van VEKTIS 6, maar een alternatief zou kunnen zijn om HL7 berichten voor deze communicatie te gebruiken. Dit wordt later nog onderzocht

Interacties

Het volgende schema geeft een samenvatting van de interactie tussen de verschillende applicatierollen:

In dit document zijn de berichtspecificaties (en de implementatierichtlijnen) opgedeeld aan de hand van de vier soorten interacties die hierboven zijn te onderscheiden (mutaties, queries/antwoorden, referenties en declaraties).

Strikt genomen is er een aparte Beantwoordende Rol, die zorgt voor antwoorden op queries van de Opvragende Rol. Deze rol kan samenvallen met de Vastleggende Rol, maar ook met de Volgende Rol.

In de loop van 2009 is de landelijke Grouper operationeel geworden. Hiermee worden DBC’s gevalideerd volgens de nieuwe DBC DOT systematiek. De communicatie van en naar de Grouper verloopt via HL7 versie 3 berichten. Zie de website van DBC-Onderhoud voor meer informatie.

(*) De Facturerende Rol en eventuele factuurberichten worden in dit document niet verder uitgewerkt. Op het moment dat DBC’s feitelijk gefactureerd gaan worden aan zorgverzekeraars wordt dit nader bekeken.

Objecten, statussen en trigger events

In deze paragraaf worden enkele concepten toegelicht die de basis vormen voor de rest van de specificaties.

HL7 berichten worden verstuurd om informatie over ‘objecten’ uit te wisselen tussen verschillende sys­temen. Objecten zijn in dat verband de abstracte gegevensgroepen, die besloten liggen in het datamodel van de systemen (bv. Patiënten, opnames of diagnoses). Elk object heeft een bepaalde ‘status’, die de gegevensinhoud van het object bepaalt, en het zijn de veranderingen in die status die moet worden uitgewisseld.

Wat precies relevante statusveranderingen zijn, hangt af van de aard van het gemeenschappelijke proces­model dat de systemen delen (anders gezegd: op welke manier hun processen van elkaar afhankelijk zijn). Telkens als een object van status verandert spreekt men van een ‘trigger event’. Het zijn trigger events die directe aanleiding zijn voor het verzenden van HL7 berichten door het systeem waar de wijziging optreedt.

Noot: Uitzondering op deze regel is de ‘query’, waarbij de huidige status actief wordt opgevraagd.

Objecten

In de context van de DBC-registratie staan er twee objecten centraal (op basis van het minimale gegevensmodel), namelijk het zorgtraject en het DBC-traject. Het is duidelijk dat het zorgtraject daarbij ‘boven’ het DBC-traject staat, in de zin dat een zorgtraject gerelateerd kan zijn aan meerdere DBC-trajecten. In deze versie van de specificaties zal dan ook vooral worden ingegaan op statusveranderingen van het zorgtraject.

De totale lijst van relevante objecten voor DBC’s, inclusief het uitgebreide gegevensmodel, is als volgt:

Noot: In het minimale gegevensmodel komen ook nog de patiënt en het specialisme als object voor, maar hun statusveranderingen zijn niet relevant in de context van DBC-registratie. De patiënt en het specialisme worden dus in feite beschouwd als kenmerken (oftewel attributen) van het bijbehorende zorgtraject.

Noot: In het uitgebreide gegevensmodel komt ook nog de specialist als object voor, maar diens status­veranderingen zijn niet relevant in de context van DBC-registratie. De specialist wordt dus beschouwd als kenmerk van de bijbehorende verantwoordelijkheidsperiode (oftewel betrokken_specialist_in_zorgtraject).

Statussen

Voor deze versie van de specificaties is als uitgangspunt gekozen dat alle bovenstaande objecten zijn te be­schouwen als kenmerken van het zorgtraject. Dat wil zeggen dat statusveranderingen in alle onder­liggende gegevens worden beschouwd als wijzigingen van het bijbehorende zorgtraject. Dit heeft als voordeel dat een zeer beperkte set trigger events (en dus berichten) voldoende is, maar als nadeel dat de trigger events niet erg specifiek zijn als het gaat om de aard van de statusverandering bij wijziging van het zorgtraject.

Een zorgtraject heeft drie primaire statussen, namelijk lopend, afgesloten en geannuleerd:

  • Een lopend zorgtraject hoort bij een zorgvraag waarvoor de patiënt nog in behandeling is.
  • Een afgesloten zorgtraject hoort bij een zorgvraag waarvoor de behandeling reeds is afgesloten.
  • De status geannuleerd heeft betrekking op verwijderde (ongeldige) registraties van zorgtrajecten.

De statussen en de transities daartussen worden afgebeeld in het volgende State Transition Diagram:

Noot: De state transition diagrams voor de andere eerder genoemde objecten lijken sterk op bovenstaand model, aangezien ze allemaal (m.u.v. de verwijzing) het karakter hebben van een afgebakend tijdsinterval.

Trigger events

De trigger events vallen nu samen met de relevante statusveranderingen in het schema hierboven (de codes ZD1 t/m ZD5 voor deze events zijn in de pijlen gezet). Bij elk trigger event is een bijbehorend (mutatie)­bericht gedefinieerd. Deze DBC-mutatieberichten worden in de volgende paragraaf nader beschreven.

Alleen bij de status lopend kan de gegevensinhoud van het zorgtraject (en/of de onderliggende objecten) gewijzigd worden. Dit leidt ook tot een trigger event (met code ZD2), ook al zijn de begin- en eindstatus van het zorgtraject gelijk. Hier valt dus ook bijv. het starten van een nieuw onderliggend DBC-traject onder.

DBC-Mutatieberichten

Het generieke ZDM berichtformaat

Deze categorie berichten vormt de kern van dit document. De berichten zijn bedoeld voor de uitwisseling van alle kerngegevens rondom zorg- en DBC-trajecten, met een “DBC vastleggende” applicatie als bron en een andere (geïnteresseerde) applicatie als bestemming. De aard van de ondersteunde trigger events is af­ge­leid uit de state transitions die in de voorgaande paragraaf zijn beschreven. Het generieke berichtformaat is:

In deze berichtopbouw wordt uitgegaan van het Zorgtraject (PRB), conform het uitgebreide model dat in hoofdstuk 2 van de implementatiegids beschreven is. In de loop van de tijd kunnen bij een Zorgtraject meerdere verantwoordelijke artsen (ROL) vastgelegd zijn. Tevens kunnen meerdere hoofd- en nevendiagnoses (DG1) geregistreerd zijn. Daarnaast kunnen meerdere behandelcodes (PTH) vastgelegd zijn.

Het eerste DBC-traject (ZDB) binnen een Zorgtraject begint gelijktijdig met het Zorgtraject. DBC’s kunnen binnen een Zorgtraject alleen opvolgend in tijd voorkomen: ze kunnen elkaar niet overlappen. Wanneer een DBC afgesloten wordt, wordt op dat moment bepaald welke diagnose hiervoor typerend is. Dit geldt ook voor de verantwoordelijk arts en de behandelcode.

Binnen een ZDM-mutatiebericht moeten altijd alle binnen het Zorgtraject geregistreerde DBC’s meegestuurd worden.

Elk ZDM bericht moet minimaal één PRB segment bevatten. Per PRB segment moet minimaal één ZDB segment voorkomen.

De IN1, IN2 en IN3 segmenten kunnen optioneel op DBC-niveau na het ZDB-segment toegevoegd worden om informatie over de machtiging van de betreffende DBC door te geven. Hierbij is het IN1 segment verplicht. Zie voor verdere informatie over deze segmenten HL7 2.4 Hoofdstuk 6 Financial Management.

Binnen het bericht is het mogelijk om per DBC-traject (ZDB) optioneel alle daaraan gekoppelde verrichtingen op te nemen (het zorgprofiel). Hiervoor zijn alle betreffende segmenten vanaf FT1 t/m de verzekerings- en machtigingsgegevens voor deze FT1 overgenomen uit het DFT^P03 bericht, zie hoofdstuk 6 voor nadere uitleg hierover.
Het is hierdoor ook mogelijk om op verrichtingniveau een eventuele afwijkende betalende instantie aan te geven middels het IN1-segment onder de FT1, of een machtiging op verrichtingniveau via de combinatie van IN1 en IN3 onder het FT1-segment. Het IN1-segment is altijd verplicht wanneer een IN3-segment gebruikt wordt.

De Grouper Hashcodes voor het DBC-traject kunnen opgenomen worden in het ZDH segment.  Dit segment wordt (herhalend)  per ZDB segment opgenomen direct na de (optionele) IN1 groep met verzekeringsinformatie.

Het zorgprofiel binnen de ZDB-berichten is optioneel.
Een zender is niet verplicht het zorgprofiel mee te leveren.
Een ontvanger is niet verplicht het zorgprofiel te verwerken en op te slaan.
Zenders en ontvangers dienen in hun Conformance Statement aan te geven of deze functionaliteit ondersteund wordt.

De generieke respons van het ontvangende systeem bij deze trigger events is als volgt:

Vastlegging van nieuw zorgtraject (event ZD1)

Dit bericht wordt verzonden als een nieuw zorgtraject wordt geopend. In de meeste systemen zal dit samenhangen met het openen van een nieuw (eerste) DBC-traject. Het openen van het eerste DBC-traject is impliciet een gevolg van dit trigger event. Het meegestuurde ZDB segment bevat de gegevens van dit eerste DBC-traject.

Wijziging van lopend zorgtraject (of bijbehorende gegevens) (event ZD2)

Dit bericht wordt verzonden als een wijziging op een bestaand (lopend) zorgtraject plaatsvindt, inclusief wijzigingen van bijbehorende gegevens (waaronder DBC-trajecten). Als het zorgtraject­nummer, de patiënt of het specialisme van het zorgtraject wijzigt, dan dient het bestaande zorgtraject te worden ge­annu­leerd (event ZD5) en een nieuw zorgtraject (met de juiste gegevens) te worden doorgegeven (event ZD1).

Een ZD2 event kan alleen plaatsvinden zolang het zorgtraject niet is afgesloten. Een wijziging op een reeds afgesloten zorgtraject kan alleen plaatsvinden als het zorgtraject eerst wordt heropend (event ZD4) en vervolgens een nieuw zorgtraject (met de juiste gegevens) wordt doorgegeven (event ZD1).

Let op:

In deze versie van de DBC-berichten is er voor gekozen om geen afzonderlijke trigger events voor het openen en afsluiten van DBC-trajecten te definiëren. Het openen van een nieuw DBC-traject (en het afsluiten van het voorgaande DBC-traject) moet worden doorgegeven door bericht ZD2 te verzenden, waarin de actuele informatie van beide betreffende DBC-trajecten is opgenomen. Het ontvangende systeem kan het informatie van het zorgtraject integraal overnemen (en dus voorgaande informatie overschrijven) of op basis van een verschillenanalyse kijken welke relevante wijzigingen in de gegevens hebben plaatsgevonden.

Afsluiting van een lopend zorgtraject (event ZD3)

Dit bericht wordt verzonden als een lopend zorgtraject wordt afgesloten. Meestal zal dit samenhangen met het afsluiten van het laatste bijbehorende DBC-traject. Als dit bericht wordt verzonden terwijl het laatste DBC-traject nog niet is afgesloten, dan is het afsluiten daarvan impliciet een gevolg van dit trigger event.

Heropening van een afgesloten zorgtraject (ZD4)

Dit bericht wordt verzonden als een reeds afgesloten zorgtraject wordt heropend. Dit gebeurt bijv. als dezelfde zorgvraag na initiële uitbehandeling toch weer zorg vereist. Er kunnen dus geen wijzigingen op een eerder afgesloten zorgtraject plaatsvinden (inclusief mutaties op de onderliggende gegevens, zoals DBC-trajecten), voordat het is heropend via dit trigger event.

Annulering van lopend zorgtraject (correctie foutieve invoer) (ZD5)

Dit bericht wordt verzonden als een eerder vastgelegd zorgtraject ongeldig blijkt te zijn. Dit kan bijv. het gevolg zijn van tik- of selectiefouten of van verkeerde interpretatie van gegevens in de ‘echte wereld’.

Declaratie van een DBC-traject inclusief zorgprofiel (event ZD8)

Met dit bericht kan een DBC-declaratie verzonden worden vanuit het DBC-validatie systeem (het systeem dat met de landelijke Grouper communiceert) naar het Facturerings systeem. Hierbij wordt de generieke berichtopbouw gehanteerd, met de volgende extra beperkingen:

  • Alleen de te declareren DBC wordt in dit bericht opgenomen, dus geen eerdere en vervolg-DBC’s.
  • Het volledige zorgprofiel van de DBC (de gekoppelde verrichtingen, zoals deze aan de Grouper aangeboden zijn) dient meegestuurd te worden.
  • Het eerste FT1 segment binnen de herhaling bevat de DBC-declaratie, met de gegevens die normaliter in het FT1-segment in het DFT-P03 bericht verzonden worden. Hierbij dient in FT1-7.3 aangegeven te worden dat het de DBC-declaratie betreft.
    De hierna volgende FT1-segmenten bevatten de gekoppelde verrichtingen. In FT1-7.3 dient hierbij aangegeven te worden dat dit zorgprofiel-verrichtingen betreft.

DBC-opvraagberichten

Deze categorie berichten is bedoeld voor het opvragen van alle kerngegevens rondom zorg- en DBC-trajecten door een applicatie die deze gegevens zelf niet beschikbaar heeft of wil controleren. Het verzoek om gegevens heet de query en deze wordt beantwoord door een systeem dat de gevraagde gegevens beschikbaar kan stellen. Dit kan een “DBC vastleggende” applicatie zijn, maar ook een andere applicatie die de DBC-gegevens bijhoudt.

Het generieke berichtformaat van de query is als volgt:

Het systeem dat antwoord geeft op de query doet dat in het volgende formaat:

Opvragen van de zorgtrajecten van een patiënt (ZD6)

Dit bericht wordt verzonden als het opvragende systeem alle gegevens rond zorg- en DBC-trajecten voor een bepaalde patiënt wil ontvangen. Als identificatie voor de patiënt wordt het unieke patiëntnummer gebruikt, dat wordt geplaatst in QRD-8 Who subject filter. Het resultaat is een serie van nul, één of meer zorgtrajecten die optioneel worden gegroepeerd op basis van de bijbehorende verwijzing (zie ZD6 berichtstructuur hierboven).

Opvragen van de gegevens van een zorgtraject (event ZD7)

Dit bericht wordt verzonden als het opvragende systeem alle gegevens rond een bepaald zorgtraject wilt ontvangen. Als identificatie voor het zorgtraject wordt het unieke zorgtrajectnummer gebruikt, dat wordt geplaatst in QRD-9 What subject filter. Het resultaat is nul of één zorgtrajecten, optioneel voorafgegaan door de bijbehorende verwijzing. Dit is dus een restrictie op de algemene ZD6 berichtstructuur, zoals hierboven beschreven is.

DBC-declaratieberichten

Deze categorie berichten is bedoeld voor het verzenden van DBC-declaratiecodes aan de facturering.
Aangezien de DBC-gegevens in dat geval worden beschouwd als strikt financiële transacties, kan daarbij gebruik worden gemaakt van de DFT berichten die worden gedefinieerd in hoofdstuk 6. Wel is sprake van specifieke kenmerken bij het vullen van het FT1 segment, die worden beschreven in paragraaf A.9.11.

Per 1-1-2003 mocht voor elke afgesloten DBC een verrichting gedeclareerd worden (met een vaste code), die dienst doet als een zogenaamd ‘registratietarief’. Per 1-1-2005 is de daadwerkelijke facturering op basis van DBC-producten ingevoerd. De DBC-declaratieberichten zijn hierop gebaseerd.

Om een DOT-DBC (gestart vanaf 1-1-2012) inclusief zorgprofiel te declareren moet in plaats van het DFT^P03 bericht een ZDB Z08 bericht verstuurd worden. DOT-DBC’s kunnen ook zonder zorgprofiel gecommuniceerd worden via het DFT^P03 bericht.

Om een DOT-DBC zonder zorgprofiel te declareren kan zoals voorheen het DFT^P03 bericht gebruikt worden. Hierbij is het mogelijk om het nieuwe ZDH-segment (Hash) mee te geven in dit bericht, zie hierna.
Het advies is om DBC’s gestart voor 1-1-2012 zoals voorheen via het DFT^P03 bericht naar het factureringssysteem te blijven sturen.

Ook voor zelfstandig declarabele verrichtingen die aan een DOT-DBC gekoppeld zijn, is het advies deze via DFT^P03 berichten te blijven verzenden.

DFT/ACK – post detail financial transactions (event P03)

Het generieke berichtformaat van het DBC-declaratiebericht is als volgt:

De generieke respons van het ontvangende systeem bij dit trigger event is als volgt:

Niet alle mogelijke segmenten zijn in bovenstaand schema opgenomen. Voor een verdere beschrijving van dit bericht wordt verwezen naar hoofdstuk 2 van de implementatiegids.

De invulling van het DFT^P03 bericht is in principe conform de richtlijnen in hoofdstuk 6 van de Nederlandse implementatiegids voor HL7 Versie 2.4 (zie o.a. GT1 segment). Zie voor een beschrijving van het gebruik van het FT1-segment  in de context van DBC-declaratieberichten de toelichting in paragraaf A.9.

Aanbevolen wordt om het ZDB-segment in het P03-bericht mee te sturen om de relatie met de DBC waaruit de verrichting voortkomt eenduidig aan te geven.

Berichten met DBC-referenties

Deze categorie berichten is bedoeld voor het leggen van een verband tussen allerlei administratieve (en medische) gegevens en het DBC-traject waaraan deze gerelateerd zijn. Deze referentie kan meerdere doelen dienen:

Het doorgeven van een referentie bij in een order of bij een afspraak, zodat een gekoppeld deelsysteem (bv. lab of röntgen) bij rapportage van uitslagen of verrichten weet bij welk DBC-traject deze horen. Het is niet mogelijk om deze relatie op deze afdelingen te leggen, zodat deze al bij aanvraag bekend moet zijn.

Het bij de bron vastleggen van de exacte productie bij een specifiek DBC-traject. Dit kan als basis dienen voor management informatie bij bet bepalen van de ‘zorgprofielen’ per diagnose/behandeling. Dit levert een preciezer verband tussen DBC’s en activiteiten op dan (achteraf) in een data warehouse mogelijk is.

In het algemeen geldt dat de wijze waarop dergelijke DBC-referenties worden meegegeven, wordt beschreven in de implementatiegids voor het betreffende hoofdstuk. In deze paragraaf wordt alleen een algemene toelichting gegeven.

Afspraken, orders en resultaten

Als tijdens het medisch-administratieve proces rond een patiënt specifieke HL7 berichten ontstaan, dan kan het DBC-trajectnummer waaraan deze gerelateerd zijn doorgegeven worden door een ZDB segment toe te voegen aan het betreffende afspraak-, order- of resultaatbericht. Let op: omdat een afspraak, order of resultaat theoretisch bij meerdere DBC-trajecten kan horen, moet het ZDB segment optioneel herhalend zijn in de betreffende berichten.

Voor hoofdstuk 4 en hoofdstuk 7 heeft de werkgroep onder de Technische Commissie besloten het ZDB segment direct na het ORC segment op te nemen. Dus aan alle berichtdefinities in het betreffende hoofdstuk is volgend op ORC een optioneel [{ZDB}] element opgenomen, met een verwijzing naar “Bijlage 1-NL” in plaats van naar een bestaand hoofdstuk van de implementatiegids. Voor hoofdstuk 10 (Scheduling) volgt een vergelijkbare oplossing.

Activiteiten / verrichtingen

Activiteiten c.q. verrichtingen worden door afdelingssystemen door middel van DFT^P03 berichten doorgegeven aan met name het factureringssysteem. Als in het afdelingssysteem de activiteiten reeds aan een specifiek DBC-traject gekoppeld worden, dan kan het DBC-trajectnummer in het P03 bericht worden aangeduid door een ZDB segment toe te voegen. Let op: ook hier moet het ZDB segment optioneel herhalend zijn in de betreffende berichten.

Tags: , , ,

Soortgelijke Berichten

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Fill out this field
Fill out this field
Geef een geldig e-mailadres op.
Je moet de voorwaarden accepteren voordat je het bericht kunt verzenden.

Meest Bekeken Berichten

Menu