Van FB naar DBC Een architectuurontwerp voor de afhandeling van DBC s 6 november 2003

Van FB naar DBC Een architectuurontwerp voor de afhandeling van DBC’s 6 november 2003

Auteur: Opdrachtgever: Opleidingen: Vakgroepen: Begeleider faculteit EWI: Begeleider faculteit BBT: Begeleiders Deloitte & Touche:

Linda Terlouw (9804501) Deloitte & Touche Enterprise Risk Services Technische Informatica en Bedrijfsinformatietechnologie Informatiesystemen en E-business Prof. dr. R.J. Wieringa Prof. dr. R.A. Stegwee R. Drewes MIM, M.W. de Breed RE RI CISA

Samenvatting Vanaf juli 2004 zal in de gezondheidszorg begonnen worden met financiering op basis van Diagnose Behandel Combinaties (DBC’s). Een DBC is het geheel van activiteiten van ziekenhuis en medisch specialist voortvloeiend uit de zorgvraag waarvoor de pati¨ent het ziekenhuis consulteert. DBC’s en de daarvan afgeleide productgroepen zijn producten die ziekenhuizen aan verzekeraars kunnen verkopen. De nieuwe financiering op basis van DBC’s brengt grote veranderingen met zich mee in de strategie¨en en bedrijfsprocessen van ziekenhuizen en verzekeraars. Hierdoor moeten ook de informatiesystemen van beiden aangepast worden. Ziekenhuizen hebben drie nieuwe applicaties nodig: een DBC-registratie applicatie, een contractmanagementapplicatie en een datawarehouse1 . Daarnaast moet de bestaande facturatie-applicatie aangepast worden. De DBC-registratie-applicatie wordt hierbij de centrale applicatie. Deze registreert DBC’s, koppelt deze aan verrichtingen, valideert de DBC’s en zet de DBC’s om in productgroepen. De contractmanagementapplicatie houdt de afspraken bij die met verzekeraars gemaakt zijn. Ook houdt deze applicatie een actuele status bij van de hoeveelheid reeds gedeclareerde DBC’s. Het datawarehouse is, zoals gezegd, nodig om de kostprijs van DBC’s/productgroepen te bepalen en daarnaast om (andere) financi¨ele managementinformatie te verkrijgen. Eventueel kan dit datawarehouse ook gebruikt worden voor de generatie van medische managementinformatie. De facturatie-applicatie zal, in plaats van verrichtingen, productgroepen gaan declareren bij verzekeraars. Daarnaast zal de facturatie-applicatie anonieme DBC’s naar de verzekeraar sturen. De productgroepen hebben niet langer een vast tarief zoals bij verrichtingen het geval was. Hierdoor kan de facturatie-applicatie niet langer gebruik maken van de CTG-lijsten (dit zijn lijsten met verrichtingen en daaraan gekoppelde tarieven uitgegeven door het College Tarieven Gezondheidszorg), maar moet deze de met verzekeraars afgesproken tarieven uit de contractmanagementapplicatie halen. Verzekeraars hebben net als ziekenhuizen een contractmanagementapplicatie nodig. Daarnaast moeten de declaratie-applicatie en het managementinformatiesysteem aangepast worden. De contractmanagementapplicatie moet de afspraken die met de verschillende ziekenhuizen gemaakt zijn opslaan. Ook moet deze applicatie het aantal reeds gedeclareerde productgroepen bijhouden. De declaratie-applicatie kan declaraties niet langer controleren aan de hand van CTG-tarieven, maar moet in de contractmanagementapplicatie de tarieven die afgesproken zijn met een bepaald ziekenhuis opzoeken. In het managementinformatiesysteem kan de verzekeraar prijzen van verschillende ziekenhuizen met elkaar vergelijken en kijken of de gedeclareerde productgroepen overeenkomen met de geanoniemiseerde DBC’s. Ook behoudt het managementinformatiesysteem zijn huidige functie: het opstellen van financi¨ele managementinformatie.

1 Hoewel ziekenhuizen soms al een datawarehouse hebben, staat deze hier als nieuwe applicatie genoemd, aangezien dit er een belangrijke functie bij krijgt: het bepalen van kostprijzen.

1

Voorwoord Voor u ligt het resultaat van mijn afstudeeropdracht voor de studies Technische Informatica en Bedrijfsinformatietechnologie aan de Universiteit Twente. Deze scriptie is geschreven in opdracht van Deloitte & Touche Enterprise Risk Services (ERS). Deloitte & Touche ERS houdt zich bezig met het analyseren en inperken van risico’s die bedrijven en overheidsinstellingen lopen op het gebied van bedrijfsprocessen en informatiesystemen. Vanwege de uitbreiding van haar diensten in de gezondheidszorg had Deloitte & Touche ERS behoefte aan een analyse van de veranderingen in de gezondheidszorg die de invoering van DBC’s teweeg brengt. Hierbij had ERS vooral interesse in de veranderingen in de informatiesystemen. Het voorstel van ERS was dus het onderzoeken van de veranderingen in de informatiesystemen van ziekenhuizen en zorgverzekeraars die nodig zijn bij de invoering van DBC’s. Samen met mijn afstudeercommissie heb ik de opdracht verder uitgewerkt. Graag wil ik mijn begeleiders Roel Wieringa, Robert Stegwee, Richard Drewes en Theo de Breed bedanken voor de steun die zij mij de afgelopen maanden hebben geboden. Daarnaast wil ik graag alle ge¨ınterviewden die geheel belangeloos hun tijd beschikbaar stelden bedanken. Zij hebben mij een goed beeld gegeven van de manier van werken in de medische wereld en de veranderingen die DBC’s gaan brengen (of beter gezegd: zouden moeten gaan brengen). Tenslotte wil ik de Minister van VWS bedanken dat hij besloten heeft het DBC-project door te laten gaan, waardoor het werk dat ik de afgelopen maanden verricht heb niet voor niets is geweest. Linda Terlouw Amersfoort, 6 november 2003

2

Inhoudsopgave 1 Inleiding

5

2 Doelstelling, probleemstelling en onderzoeksvragen 2.1 Definities . . . . . . . . . . . . . . . . . . . . . . 2.2 Doelstelling . . . . . . . . . . . . . . . . . . . . 2.3 Probleemstelling . . . . . . . . . . . . . . . . . . 2.4 Onderzoeksvragen . . . . . . . . . . . . . . . . .

. . . .

7 7 7 7 7

3 Methodologie 3.1 Mogelijke bronnen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Ontsluiting van bronnen . . . . . . . . . . . . . . . . . . . . . . . . . . 3.3 Keuze bronnen en koppeling met onderzoeksvragen . . . . . . . . . . .

9 9 10 10

4 Literatuuronderzoek 4.1 Ontwikkeling van informatiesystemen . . . . . . . . . . . . . . . . . . . 4.2 Medische archieven en coderingen . . . . . . . . . . . . . . . . . . . . 4.3 Privacywetgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13 13 25 26

5 Ontwerpmethode 5.1 Probleemanalyse . . . 5.2 Requirements-analyse 5.3 Ontwerp . . . . . . . 5.4 Evaluatie . . . . . . .

. . . .

28 28 30 30 31

6 Probleemanalyse 6.1 Veranderingen in de zorg . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 Analyse huidige situatie . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3 Analyse gewenste situatie . . . . . . . . . . . . . . . . . . . . . . . . .

32 32 35 42

7 Requirements-analyse 7.1 Probleem . . . . . . . . 7.2 Doel product . . . . . . 7.3 Stakeholders . . . . . . 7.4 Randvoorwaarden . . . 7.5 Aannames . . . . . . . 7.6 Scope van het product 7.7 Programma van eisen .

. . . . . . .

45 45 45 45 46 46 48 48

8 Alternatieven 8.1 Applicaties ziekenhuizen . . . . . . . . . . . . . . . . . . . . . . . . . . 8.2 Verbinding tussen ziekenhuizen en verzekeraars . . . . . . . . . . . . . 8.3 Applicaties verzekeraars . . . . . . . . . . . . . . . . . . . . . . . . . .

54 55 57 57

9 Conceptueel model 9.1 Applicaties ziekenhuizen . . . . . . 9.2 Applicaties verzekeraars . . . . . . 9.3 Beveiligingsmaatregelen . . . . . . 9.4 Privacy-beschermende maatregelen

58 59 61 62 63

. . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

. . . .

. . . . . . .

3

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

. . . .

. . . . . . .

. . . .

. . . .

10 Gedetailleerd model 10.1 Applicaties ziekenhuizen . . . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Applicaties verzekeraars . . . . . . . . . . . . . . . . . . . . . . . . . . 10.3 Migratietraject . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64 64 73 79

11 Evaluatie 11.1 Koppeling activiteiten aan applicaties . . . . . . . . . . . . . . . . . . . 11.2 Overige eisen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 Toekomstig werk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

83 83 85 86

12 Conclusies

87

13 Aanbevelingen

89

Bibliografie

91

Interviews

94

Bijlage 1: afkortingenlijst

95

Bijlage 2: woordenlijst

96

Bijlage 3: financieringsproces huidige situatie

98

Bijlage 4: financieringsproces gewenste situatie

99

bijlage 5: medisch proces huidige situatie

100

Bijlage 6: medisch proces gewenste situatie

101

Bijlage 7: DFD medisch proces huidige situatie

102

Bijlage 8: DFD medisch proces gewenste situatie

103

Bijlage 9: declaratieproces huidige situatie

104

Bijlage 10: declaratieproces gewenste situatie

105

Bijlage 11: DFD declaratieproces huidige situatie (ziekenhuis)

106

Bijlage 12: DFD declaratieproces gewenste situatie (ziekenhuis)

107

Bijlage 13: DFD declaratieproces huidige situatie (verzekeraar)

108

Bijlage 14: DFD declaratieproces gewenste situatie (verzekeraar)

109

4

1. Inleiding Al enkele jaren zijn Diagnose Behandel Combinaties, oftewel DBC’s, een veel besproken onderwerp in de gezondheidszorg. Het idee van DBC’s is dat ziekenhuizen niet langer een Functiegericht Budget (oftewel FB) krijgen op basis van de productie van de vorige periode, maar dat ziekenhuizen hun producten gaan verkopen aan verzekeraars. Deze producten worden DBC’s genoemd. Het Ministerie van VWS wil ziekenhuizen op deze manier commerci¨eler laten denken. Minister Borst heeft in 2000 de stuurgroep DBC2003 samengesteld. In deze stuurgroep hebben bestuurders van het Ministerie van VWS, de Nederlandse Vereniging van Ziekenhuizen, de Vereniging van Academische Ziekenhuizen (VAZ), de Orde van Medisch Specialisten, Zorgverzekeraars Nederland, het College Tarieven Gezondheidszorg (CTG) en het College voor Zorgverzekeraars zitting. Het is dus een project waar vrijwel de gehele gezondheidszorg mee te maken heeft. De stuurgroep DBC2003 heeft Cap Gemini Ernst & Young gekozen voor de projectleiding van de projectgroep DBC2003 en de beleiding van de implementatie van de DBC’s tot 2004. Ondanks de nodige tegenslagen en veranderingen in het DBC-project, gaan DBC’s in juli 2004 ingevoerd worden. De afgelopen tijd stonden de medische tijdschriften vol met artikelen over DBC’s met onder andere de vragen of het project door zou gaan, wat de financi¨ele consequenties voor de verschillende partijen zouden zijn, wat voor impact het op de wachtlijsten zou hebben etc. De informatie is echter vrij versplinterd, aangezien de meeste artikelen vrij kort en algemeen zijn of juist heel diep op ´e´en aspect ingaan. In dit onderzoek is geprobeerd een zo volledig mogelijk overzicht te geven van de veranderingen die nodig zijn in de informatiesystemen van ziekenhuizen en verzekeraars voor de operationele afhandeling van DBC’s. De doelgroep van dit document bestaat enerzijds uit informatici, die interesse hebben in de gezondheidszorg, en anderzijds medewerkers van ziekenhuizen en verzekeraars, die interesse hebben in informatica. Enige kennis op het gebied van de gezondheidszorg en informatica maken het verslag gemakkelijker te lezen. Echt noodzakelijk is dergelijke kennis echter niet. Bijlage 1 en 2 bevatten respectievelijk een afkortingenlijst en een woordenlijst om u wegwijs te maken in de vele gebruikte afkortingen en ‘vreemde’ woorden. Hoofdstuk 2 van dit verslag zal de probleemstelling van dit onderzoek verder uitwerken. De probleemstelling zal opgesplitst worden in onderzoeksvragen, die in de verdere hoofdstukken behandeld zullen worden. Hoofdstuk 3 behandelt de gebruikte methodologie, oftewel de onderzoeksmethoden die gebruikt worden om de onderzoeksvragen te beantwoorden. In hoofdstuk 4 staan de resultaten van het uitgevoerde literatuuronderzoek. Dit literatuuronderzoek gaat in op verschillende ontwerpmethoden voor informatiesystemen en op enkele belangrijke coderingen die in de medische wereld gebruikt worden. De ontwerpmethoden die in het vorige hoofdstuk besproken zijn worden in hoofdstuk 5 gecombineerd tot de ontwerpmethode die in dit onderzoek gebruikt wordt. Hoofdstuk 6 beschrijft de veranderingen in de strategie¨en en bedrijfsprocessen van ziekenhuizen en verzekeraars die noodzakelijk zijn voor de invoering van DBC’s. Deze veranderingen worden in hoofdstuk 7 vertaald in eisen voor de te ontwikkelen architectuur. Hoofdstuk 8 geeft vervolgens enkele alternatieve structuren voor deze architectuur. 5

In hoofdstuk 9 wordt het conceptuele model besproken. Dit model laat zien hoe de verschillende applicaties met elkaar verbonden zijn. Ook behandelt dit hoofdstuk een aantal beveiligingsmaatregelen en privacy-beschermende maatregelen. Hoofdstuk 10 werkt het conceptuele model verder uit tot een gedetailleerd model. In dit hoofdstuk worden de applicaties die de grootste veranderingen ondergaan besproken en hiervan worden modellen opgesteld. In hoofdstuk 11 staat een evaluatie van de ontworpen architectuur. Dit wil zeggen dat er gekeken wordt of de architectuur voldoet aan de gestelde eisen. Tenslotte bespreken hoofdstuk 12 en 13 respectievelijk de conclusies en aanbevelingen.

6

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

2. Doelstelling, probleemstelling en onderzoeksvragen 2.1

Definities

In dit onderzoek zullen de volgende definities gebruikt worden (Franke & Zeef, 2003): Architectuur een hoog-niveau functionele beschrijving van applicatiecomponenten (zoals software, databases en netwerken) en de manier waarop deze samenwerken. Infrastructuur de hele verzameling van technische componenten die het aanbod aan ICT-gebaseerde services verzorgen (zowel aan werknemers als aan klanten). Applicatie een informatiesysteem dat ´e´en primaire functie binnen de organisatie vervult.

2.2

Doelstelling

Het doel van dit afstudeeronderzoek is: Deloitte & Touche een inzicht geven in hoe ziekenhuizen en verzekeraars hun bedrijfsprocessen, die gaan veranderen door de invoering van DBC’s, kunnen ondersteunen met behulp van IT door het ontwerp van een generieke architectuur.

2.3

Probleemstelling

De probleemstelling van dit afstudeeronderzoek luidt als volgt. Welke samenwerkende componenten (applicaties) dient een architectuur voor de correcte administratieve afhandeling van DBC’s van ziekenhuis tot verzekeraar te bevatten en welke informatie moeten deze componenten met elkaar uitwisselen?

2.4

Onderzoeksvragen

De probleemstelling zal aan de hand van de volgende onderzoeksvragen beantwoord worden. 1. Welke problemen dient de te ontwikkelen architectuur op te lossen? (a) Welke partijen hebben belang bij een nieuwe architectuur? (b) Welke doelen hebben deze belanghebbenden? (c) Welke problemen hebben de belanghebbenden met de huidige architectuur? (d) Welke eisen stellen de belanghebbenden aan een nieuwe architectuur? 2. Welke applicaties worden in de huidige situatie gebruikt door ziekenhuizen en verzekeraars?

7

3. Welke informatievoorziening is nodig in het proces van de administratieve afhandeling van DBC’s? (a) Welke stappen zijn er te onderscheiden in het proces van de administratieve afhandeling van DBC’s? (b) Welke informatie is nodig voor de uitvoering van deze processtappen? (c) Welke informatie leveren deze processtappen op? (d) Welke (soort) applicaties zijn geschikt voor ondersteuning van deze processtappen bij ziekenhuis en verzekeraar? 4. Welke informatie moet voor de afhandeling van DBC’s uitgewisseld worden tussen de applicaties van een ziekenhuis, tussen de applicaties van een verzekeraar en tussen de applicaties van een ziekenhuis en een verzekeraar? 5. Welke standaarden kunnen gebruikt worden voor de communicatie tussen de componenten? (a) Welke standaarden worden reeds gebruikt door ziekenhuizen? (b) Welke standaarden worden reeds gebruikt door verzekeraars? (c) Welke nieuwe standaarden zijn beschikbaar? 6. Welke ontwerpstappen zijn nodig voor het ontwerp van de architectuur? (a) Welke methoden kunnen gebruikt worden voor het ontwerp van een architectuur? (b) Wat zijn de ontwerpstappen van deze methoden? (c) Wat zijn de voor- en nadelen van deze methoden? (d) Welke stappen uit deze methoden kunnen gebruikt worden voor dit onderzoek? 7. Hoe ziet een architectuur die aan de gestelde eisen voldoet eruit? Het volgende hoofdstuk (‘Methodologie’) legt uit welke bronnen voor de beantwoording van de vragen gebruikt zijn en op welke manier deze bronnen ontsloten zijn. Het hoofdstuk ‘Literatuuronderzoek’ gaat in op een aantal methoden voor het ontwerp van informatiesystemen. Deze methoden worden in het hoofdstuk ‘Ontwerpmethode’ gecombineerd tot een ontwerpmethode voor dit onderzoek. Dit hoofdstuk geeft daarbij aan welke ontwerpstappen antwoord geven op welke onderzoeksvragen. Deze ontwerpmethode wordt gebruikt voor de constructie van de probleemanalyse, de requirementsanalyse, de alternatieven, het conceptueel model en het gedetailleerd model, respectievelijk hoofdstuk 6, 7, 8, 9 en 10. Het conceptueel en het gedetailleerd model geven hierbij samen een antwoord op de probleemstelling.

8

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

3. Methodologie Dit hoofdstuk maakt duidelijk op welke manier een antwoord verkregen zal worden op de onderzoeksvragen die gesteld zijn in het vorige hoofdstuk. Hiervoor maakt dit hoofdstuk eerst duidelijk welke bronnen gebruikt kunnen worden en hoe deze ontsloten kunnen worden. Vervolgens geeft dit hoofdstuk aan welke bronnen ik gebruikt heb voor de beantwoording van de onderzoeksvragen en waarom ik deze bronnen gebruikt heb.

3.1

Mogelijke bronnen

Verschuren & Doorewaard (2003) onderscheiden vijf soorten bronnen: ˆ personen ˆ media ˆ werkelijkheid ˆ documenten ˆ literatuur

Deze bronnen kunnen dienen als databronnen en kennisbronnen. Data wil hierbij zeggen losse gegevens, zoals leeftijd, gewicht en inkomen. Kennis duidt op inzichten en theorie¨en die in eerder onderzoek zijn ontwikkeld. Verschure & Doorewaard noemen de volgende voor- en nadelen van de vijf bovenstaande bronnen. Personen hebben als voordeel dat zij een grote diversiteit aan informatie kunnen bieden en dat zij deze informatie relatief snel kunnen leveren. Daarnaast zijn personen relatief stuurbaar, waardoor de onderzoeker een grote kans heeft dat zijn onderzoeksvragen beantwoord worden. Nadelen van personen als bron zijn dat zij over sommige zaken moeilijk praten, dat zij een erg subjectieve visie kunnen geven en dat zij over sommige zaken misschien nog nooit zo na hebben gedacht. Media, zoals kranten, tijdschriften en internet, hebben als voordeel dat ze doorgaans een hoge informatiedichtheid, een hoge mate van actualiteit en een breed geografisch bereik hebben. Nadelen van media zijn dat niet over alle onderwerpen informatie te vinden is en dat de geleverde gegevens een vluchtig karakter hebben. De werkelijkheid, ofwel die dingen die direct waarneembaar zijn, heeft als grootste voordeel dat de resultaten die verkregen zijn objectief zijn. Een nadeel van deze bron is dat deze bron slechts als databron kan dienen en niet als kennisbron. De werkelijkheid levert immers geen klant-en-klare theorie¨en. Documenten hebben veel overeenkomsten met media. Het verschil tussen media en documenten is dat media in principe publiekelijk beschikbaar zijn en documenten niet. Een groot voordeel van documenten is dat deze onbeperkt en op alle momenten geraadpleegd kunnen worden. Daarnaast zijn er doorgaans veel documenten beschikbaar en zijn deze bronnen relatief gemakkelijk te gebruiken. Een nadeel is dat door de grote hoeveelheid documenten het selecteren van nuttige informatie een tijdrovende bezigheid kan zijn. Literatuur kan vooral een goede kennisbron zijn. Vorige onderzoekers hebben immers waarschijnlijk serieus nagedacht over de stof. Een nadeel van literatuur is dat de onderzoeker er teveel vertrouwen in kan krijgen vanwege de ‘professionele’ uitstraling. 9

3.2

Ontsluiting van bronnen

De bron personen kan door middel van ondervraging en observatie ontsloten worden. De onderzoeker kan personen ondervragen door middel van interviews of enquˆetes. Deze twee verschillen in de mate van voorgestructureerdheid van de ondervraging en de mate van openheid van de vraagstelling. Observatie wil zeggen dat de onderzoeker de personen en hun gedrag waarneemt. De onderzoeker kan al dan niet aanwezig zijn tijdens deze waarneming. Media kunnen middels observatie en inhoudsanalyse ontsloten worden. Het tellen van een aantal keer dat een bepaalde politicus op het journaal van 8 uur verschijnt is een voorbeeld van observatie. Inhoudsanalyse wil zeggen dat de onderzoeker die delen uit media selecteert die een antwoord (kunnen) geven op zijn onderzoeksvragen. De onderzoeker kan de werkelijkheid ontsluiten via observatie, een meetinstrument of inhoudsanalyse. Er is sprake van observatie als de onderzoeker kijkt of een kogel of een veer als eerste de grond bereikt wanneer deze op een hoogte van een meter is losgelaten. Wanneer de onderzoeker een stopwatch gebruikt om te onderzoeken hoe lang een veer erover doet de grond te bereiken, gebruikt hij een meetinstrument als ontsluiting. Bij een inhoudsanalyse gaat de onderzoeker op zoek naar die elementen van de werkelijkheid die nuttig zijn voor zijn onderzoek en eventueel deelt hij deze in in categorie¨en. Een voorbeeld hiervan is het selecteren van voorwerpen die geschikt zijn voor het onderzoeken van de zwaartekracht op aarde. Zowel documenten als literatuur kunnen via inhoudsanalyse en een zoeksysteem ontsloten worden. Inhoudsanalyse houdt zoals gezegd in dat de onderzoeker nuttige stukken selecteert en eventueel indeelt in categorie¨en. Een zoeksysteem is in feite een indirecte ontsluiting. Het biedt de mogelijkheid documenten of literatuur te selecteren. Zoeksystemen zijn bijvoorbeeld de trefwoordenlijst van de bibliotheek, het elektronische PiCarta en in vaktijdschriften opgenomen aankondigingen van congressen en symposia.

3.3

Keuze bronnen en koppeling met onderzoeksvragen

Tabel 3.1 geeft aan welke bronnen en ontsluitingsmethoden gebruikt worden voor het beantwoorden van de onderzoeksvragen. Ik zal de werkelijkheid niet gebruiken als onderzoeksbron, aangezien ik niet de mogelijkheid heb voor langere tijd op locatie te werken bij een ziekenhuis en/of verzekeraar. Bron Personen Media Documenten Literatuur

Ontsluiting Ondervraging (interview) Inhoudsanalyse Inhoudsanalyse Zoeksysteem Inhoudsanalyse Zoeksysteem

Onderzoeksvragen 1, 2, 3, 4, 7 1, 3, 7 1, 3, 4, 7 1, 3, 4, 7 5, 6, 7 5, 6, 7

Figuur 3.1: Bronnen en hun ontsluiting in dit onderzoek Onderzoeksvraag 1 zal beantwoord worden met behulp van de bronnen personen, media en documenten. Literatuur is vanwege de nieuwheid van dit onderwerp nog niet beschikbaar. Media en documenten zullen gebruik worden om een overzicht te krijgen van welke stakeholders een rol spelen in de gezondheidszorg en wat hun belangrijkste belangen zijn. 10

Deze heb ik hiervoor als eerste middel gekozen, vanwege mijn onbekendheid met de materie. Media en documenten zijn namelijk onuitputbaar te benaderen in tegenstelling tot personen. Nadat ik een globaal overzicht heb verkregen, biedt ondervraging van personen de mogelijkheid specifiekere vragen voor dit onderzoek te stellen. Interviews hebben hierbij de voorkeur boven enquˆetes, aangezien een flexibele ondervraging nodig is vanwege de vele tussentijdse veranderingen die het DBC-project ondergaat. Vanwege de duur van het onderzoek, kan slechts een redelijk kleine selectie van de stakeholders voor interviews benaderd worden. Vraag 2 zal beantwoord worden aan de hand van interviews met ziekenhuizen, verzekeraars en softwareleveranciers. Softwareleveranciers kunnen hierbij aangeven wat voor applicaties zij leveren. Ziekenhuizen en verzekeraars kunnen hierbij aangeven welke applicaties zij gebruiken en welke stappen van de bedrijfsprocessen deze applicaties ondersteunen. Om dezelfde reden als reeds aangegeven bij onderzoeksvraag 1 is gekozen voor interviews en niet voor enquˆetes. Een antwoord op onderzoeksvraag 3 zal verkregen worden met behulp van documentatie geschreven door de projectgroep DBC2003, media en interviews met ziekenhuizen en verzekeraars. De documenten leveren een beeld van hoe de DBC-processen in theorie zouden moeten verlopen. Hoewel sommige van deze documenten reeds verouderd zijn, is het van belang deze door te nemen om op de hoogte te zijn van de ontwikkelingen die spelen rondom de DBC’s. Media geven een minder gedetailleerde beschrijving, maar wel een actueler overzicht. Na de bestudering van documenten en media kan een gedetailleerd overzicht van de actuele stand van zaken met behulp van interviews achterhaald worden. Tevens kan aan de hand van interviews worden nagegaan hoe de DBC-processen tot nu toe zijn ge¨ımplementeerd. Interviews met ziekenhuizen en verzekeraars en documenten van de projectgroep DBC2003 zullen gebruikt worden voor de beantwoording van vraag 4. De documenten van de projectgroep DBC2003 geven hierbij vooral gedetailleerd informatie over hoe de gegevensuitwisseling in de DBC-situatie zou moeten zijn. Uit de interviews kan informatie gehaald worden over de huidige informatie-uitwisseling wat betreft DBC’s en de toekomstige plannen van ziekenhuizen en verzekeraars. Voor de beantwoording van vraag 5 zal literatuur over de verschillende standaarden gezocht worden. Literatuur is hiervoor geschikter dan interviews, omdat deze vraag vrij technisch is en hierdoor veel tijd zou gaan zitten in het zoeken naar experts en het houden van interviews met deze experts. Voor de beantwoording van vraag 6 zal literatuur over verschillende ontwerpmethoden gebruikt worden. Deze ontwerpmethoden dienen zich te richten op de ontwikkeling van informatiesystemen aan de hand van het bedrijfsbeleid en/of op de ontwikkeling van interorganisationele informatiesystemen. Als methode voor informatie-vergaring wordt literatuuronderzoek gebruikt, aangezien dit slechts een klein deel van het onderzoek betreft en het teveel tijd zou kosten om de hiervoor benodigde experts te benaderen. Documenten en media bieden niet de diepgaande theorie¨en die literatuur biedt. Uit het vergelijk van deze methoden zal een eigen ontwerpmethode ontwikkeld worden. Er bestaan namelijk vele ontwerpmethoden die een informatiesysteem vanuit verschillende visies bekijken en bij het ontwerp ervan de nadruk op verschillende aspecten leggen. Voor dit onderzoek zullen dus die visie en die ontwerpaspecten gecombineerd worden die geschikt zijn voor dit specifieke onderzoek. De ontwikkelde ontwerpmethode geeft aan hoe onderzoeksvraag 7 in deze scriptie beantwoord zal worden. Aangezien onder11

zoeksvraag 7 voortbouwt op de antwoorden van onderzoeksvragen 1 tot en met 6, zal bij de beantwoording dus van alle genoemde bronnen gebruik worden gemaakt.

12

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

4. Literatuuronderzoek Dit hoofdstuk bevat de belangrijkste bevindingen van het uitgevoerde literatuuronderzoek. Dit onderzoek gaat in op de volgende terreinen: de ontwikkeling van informatiesystemen, Nederlandse medische archieven en coderingen en de Nederlandse privacywetgeving. De bevindingen over de ontwikkeling van informatiesystemen zullen als leidraad gebruikt worden voor het ontwerp van de architectuur voor de afhandeling van DBC’s. De medische archieven en coderingen geven informatie over welke informatie landelijk wordt verzameld en hoe deze (en andere) informatie wordt weergegeven. De privacywetgeving geeft een belangrijke randvoorwaarde aan waarmee rekening gehouden moet worden bij het architectuurontwerp.

4.1

Ontwikkeling van informatiesystemen

In deze paragraaf zal allereerst ingegaan worden op interorganisationele informatiesystemen. Vervolgens zal een overzicht gegeven worden van diverse methoden voor de ontwikkeling van informatiesystemen. Voor het uiteindelijke architectuurontwerp zal een combinatie van deze methoden gebruikt worden.

4.1.1

Interorganisationele informatiesystemen

Informatiesystemen hebben als functie het opslaan, structureren en leveren van informatie voor de ondersteuning van activiteiten van organisaties. Omdat organisaties (niet alleen bedrijven, maar ook bijvoorbeeld overheidsinstellingen) steeds vaker en nauwer gaan samenwerken, gaan informatiesystemen een steeds grotere rol spelen bij het uitwisselen van informatie tussen organisaties. Voor de ontwikkeling van interorganisationele informatiesystemen (IOS-en) moet rekening gehouden worden met (Gregor & Johnston, 2000): 1. externe invloeden Externe invloeden kunnen zowel beperkende als stimulerende invloeden hebben op de bedrijfstak en de individuele bedrijven. Deze invloeden zijn te verdelen in: marktinvloeden, technologische invloeden en invloeden vanuit de samenleving. Invloeden vanuit de samenleving zijn bijvoorbeeld wetten en de economische situatie. 2. de bedrijfstak Er dient een analyse gemaakt te worden van de gehele bedrijfstak. Dit betreft bijvoorbeeld gebruikte standaarden voor berichtuitwisseling, de invloeden van regulerende of co¨ordinerende organen en de cultuur van de bedrijfstak. 3. het individuele bedrijf Op bedrijfsniveau zijn onder andere de volgende aspecten van invloed op de ontwikkeling van een IOS: de bedrijfsgrootte, de financi¨ele middelen, de technische kennis en de beoogde voordelen in deelname. Hong (2002) verdeelt categorie¨en van interorganisationele informatiesystemen (IOS-en) in twee dimensies afhankelijk van de soort relatie tussen de samenwerkende organisa13

ties en het niveau van ondersteuning dat het systeem biedt. De relatie kan horizontaal en verticaal zijn, zoals te zien is in figuur 4.1. Verticaal wil zeggen dat de samenwerkende bedrijven opeenvolgende stappen in het totale productieproces verzorgen (zij zitten dus op verschillende posities in dezelfde value chain). Deze bedrijven zullen ook wel leveranciers/klanten worden genoemd, hoewel deze bedrijven niet per se diensten of producten aan elkaar hoeven te leveren. Horizontaal wil zeggen dat de bedrijven dezelfde stap in het totale productieproces verzorgen en dus concurrenten zijn (zij zitten dus op dezelfde positie in verschillende value chains). Value chain 1

bedrijf 1

bedrijf 2

bedrijf 3

----

bedrijf n

Value chain 2

bedrijf 1

bedrijf 2

bedrijf 3

----

bedrijf n

Value chain 3

bedrijf 1

bedrijf 2

bedrijf 3

----

bedrijf n

Figuur 4.1: Relaties tussen bedrijven (gebruikt met toestemming van Hong (2002)) In figuur 4.2 zijn de verschillende categorie¨en van IOS-en te vinden.

Horizontaal (concurrenten)

Verticaal (leveranciers/klanten)

Operational Cooperation

Resource Pooling

Operational Coordination

Complementary Cooperation

Operationeel

Strategisch

Figuur 4.2: Categorie¨en van IOS-en (gebruikt met toestemming van Hong (2002))

Resource pooling IOS Dit soort systemen worden gebruikt door organisaties die dezelfde activiteiten uitvoeren voor het behalen van winst (concurrerende organisaties). Zij werken samen om risico’s te verkleinen of kosten te besparen door hun middelen te verenigen. Meestal wordt een dergelijke samenwerking gevormd om een concurrentieblok te vormen tegenover grote organisaties. Een voorbeeld van een dergelijke samenwerking is funda.nl. Op deze website laten makelaars die aangesloten zijn bij de NVM (Nederlandse Vereniging van Makelaars) hun huizenaanbod zien. Deze site trekt vele bezoekers, aangezien mensen weten dat deze site een groot huizenaanbod bevat. De NVM makelaars vormen hierbij dus samen een blok tegen overige makelaars. Complementary cooperation IOS Deze informatiesystemen worden gebruikt door organisaties die verschillende rollen in de value chain hebben (leveranciers/klanten). Door de samenwerking kunnen de organisaties meer diensten en/of producten aan de 14

klant aanbieden dan wanneer ze alleen zouden opereren. De KLM bijvoorbeeld biedt de mogelijkheid op haar website hotels te boeken en auto’s te huren. Deze hotels en autoverhuurmaatschappijen hebben hierdoor een voordeel ten opzichte van hun concurrenten. De KLM kan haar klanten een uitgebreidere dienst aanbieden. Operational cooperation IOS Deze informatiesystemen worden gebruikt door concurrenten die samenwerken om de kwaliteit van diensten aan klanten te verhogen of om informatie te delen. Hierbij kan bijvoorbeeld gedacht worden aan banken die het die het voor klanten mogelijk maken bij andere banken geld te pinnen. Operational coordination IOS Dergelijke systemen worden gebruikt door organisaties met verschillende rollen in de value chain (leveranciers/klanten) om de operationele effici¨entie te vergroten. Een voorbeeld hiervan is een reisbureau dat direct de systemen van de organisator van de reizen kan benaderen. Hierdoor kan het reisbureau direct de reis van de klant inboeken, wat de klant wachttijd bespaart. De informatie-uitwisseling kan dus om hele verschillende redenen gewenst zijn. In veel gevallen brengt de informatie-uitwisseling ook gevaren met zich mee. Hierbij moet niet alleen gedacht worden aan concurrentiegevoelige informatie die per ongeluk aan de concurrent wordt doorgegeven, maar ook aan foutieve informatie of informatie die te laat geleverd is. Welke organisatie is verantwoordelijk voor een fout die gemaakt is door het gebruik van verkeerde informatie? De organisatie die de informatie geleverd heeft of de organisatie die de fout gemaakt heeft? Het is daarom belangrijk dat aan de volgende eisen voldaan wordt (Chaffey, 2002): ˆ authentication: de partijen die deelnemen aan de transactie zijn wie ze zeggen te zijn. ˆ privacy and confidentiality: de gegevens die uitgewisseld worden dienen beschermd te worden voor ‘meekijkers’. Dit kan onder andere door alle niet-essenti¨ele sporen van een transactie te verwijderen van het publieke netwerk en alle tussentijdse rapportages te wissen. ˆ integrity: het bericht dient compleet en na verzending onveranderd te zijn. ˆ non-repudiability: het moet voor de zender van een bericht onmogelijk zijn te ontkennen dat hij dit bericht gestuurd heeft. ˆ availability: het systeem moet beschikbaar zijn en de benodigde performance bieden.

Organisaties moeten dus duidelijk afspreken welke informatie wanneer uitgewisseld wordt en wie welke verantwoordelijkheid heeft. Daarnaast moet rekening gehouden worden met de privacy-wetgeving indien gegevens over personen uitgewisseld worden. Hierop zal teruggekomen worden in paragraaf 4.3. Hoewel verschillende organisaties met verschillende applicaties werken, is er toch op verschillende manieren samenwerking mogelijk. In figuur 4.3 zijn de mogelijkheden weergegeven. 15

Applicatie 1

Applicatie 2

Berichtuitwisseling

Applicatie 2

Applicatie 1

Gemeenschappelijke database

Applicatie 1

Applicatie 2

Procedure- en objectaanroepen

Figuur 4.3: Drie manieren van informatie-uitwisseling

Deze mogelijkheden zijn: ˆ gezamenlijke databases De applicaties kunnen samenwerken zonder ‘echt’ contact met elkaar te hebben. Beide applicaties schrijven gegevens naar en halen gegevens uit dezelfde databases. Deze toegang kan direct verlopen indien beide applicaties van dezelfde soort database gebruik kunnen maken of via database middleware zoals ODBC of JDBC. ˆ berichtuitwisseling De uit te wisselen informatie wordt in een bericht gezet en verzonden naar de andere partij. Berichten kunnen uitgewisseld worden via een netwerk of via een verplaatsbare informatiedrager, zoals een CD-ROM of een diskette. Indien de berichten via een netwerk verzonden worden kan de communicatie synchroon of asynchroon verlopen. Bij synchrone communicatie wordt een sessie tussen de applicaties opgezet, waaraan beide partijen actief deelnemen. Bij asynchrone communicatie wordt een bericht verstuurd, zonder dat een reactie afgewacht wordt. ˆ gebruik maken van elkaars procedures of objecten Dit is de meest directe vorm van samenwerking. Applicaties kunnen elkaars procedures of objecten gebruiken en werken dus samen alsof het ´e´en applicatie betreft. Hiervoor dienen de applicaties te weten, welke procedures en objecten beschikbaar zijn en op welke locatie deze zich bevinden. Hoewel applicaties dit meestal niet kunnen, kan er vaak een ‘schil’ om de applicaties heengebouwd worden die dit mogelijk maakt. Dit kan bijvoorbeeld met behulp van CORBA.

4.1.2

Methoden

In deze paragraaf zullen ISAC, IE, de startarchitectuur en de RSD Methodology besproken worden. ISAC ISAC (Information Systems Work and Analysis of Changes) is ontwikkeld in de jaren ’70 door door een onderzoeksgroep van het Koninklijk Instituut van Technologie (Zweden) en de Universiteit van Stockholm. Een probleem in de organisatie vormt het startpunt voor deze methode. Vervolgens wordt top-down te werk gegaan.

16

De fasen die doorlopen dienen te worden zijn (Blank, 1982; Wieringa, 1996): 1. Change Analysis In deze fase worden de huidige problemen van de organisatie geanalyseerd. Een probleem wil zeggen dat een zogenaamde probleemeigenaar niet tevreden is over een situatie en er voor deze situatie een mogelijkheid voor verbetering bestaat. Een onderdeel van deze analyse is het opzetten van oorzaak-gevolg-structuren. Voor elk probleem worden de oorzaken bepaald en de oorzaken van deze oorzaken etc. Vervolgens wordt een activiteitenmodel van de organisatie opgesteld. Het activiteitenmodel kan gebruikt worden voor de ontwikkeling en het vergelijk van alternatieven. Wanneer de problemen en activiteiten van de organisatie duidelijk zijn, worden de doelen beschreven. Een doel is hierbij een gewenste situatie. Vervolgens kan aangegeven worden wat moet veranderen en kunnen er alternatieve oplossingen geformuleerd worden. Deze oplossingen worden gemodelleerd tot een activiteitenmodel en ge¨evalueerd. Uiteindelijk wordt een oplossing gekozen. Indien een oplossing een informatiesysteem als onderdeel heeft, kan de volgende fase van de ISAC-methode uitgevoerd worden. 2. Activity Study In deze fase wordt het activiteitenmodel opgedeeld in subsystemen van informatiesystemen. Van elk subsysteem worden de gewenste eigenschappen gespecificeerd en de interfaces tussen de subsystemen worden ontworpen. Voor elk subsysteem van het informatiesysteem wordt vervolgens bepaald of het geautomatiseerd kan worden en of dit gewenst is. 3. Information Analysis Voor elk informatiesysteem wordt in deze fase aangegeven wat de input en output is, hoe de interne datastructuur opgebouwd is en hoe de processtructuren eruit zien. 4. Implementation In deze fase wordt het informatiesysteem gebouwd. IE De door James Martin Associates ontwikkelde ontwerpmethode Information Engineering (IE) is ge¨ıntroduceerd in 1981 en in de opvolgende jaren verder uitgebreid. De methode begint met het vaststellen van de doelen en strategie¨en in de organisatie en de kritieke succesfactoren (KSF’s) in de diverse organisatie-onderdelen. Daarnaast worden prioriteiten toegekend door gebruikers aan verschillende voorstellen voor te ontwikkelen informatiesystemen. Het uiteindelijke resultaat van de IE-methode zijn vier architecturen (By, 1999): ˆ informatie-architectuur: een beschrijving van de gegevensgebieden, de bedrijfsfuncties en een overzicht van welke gegevens worden gebruikt door de bedrijfsfuncties. ˆ IS-architectuur: een opdeling van het informatiesysteem in deelinformatiesystemen.

17

ˆ technische architectuur: een beschrijving van welke behoefte er is aan technische middelen en hoe deze verdeeld worden. ˆ organisatorische architectuur: een analyse van welke organisatie-vorm het meest geschikt is voor de bestaande drie architecturen.

In figuur 4.1.2 is de relatie tussen de verschillende architecturen aangegeven.

KSF's Doelen en strategieën Prioriteiten deel IS-en

Informatiearchitectuur

ISarchitectuur

Technische architectuur

Organisatiearchitectuur

Figuur 4.4: De architecturen gebruikt in IE

IE omvat de volgende fasen (By, 1999; Wieringa, 1996): 1. Business Strategy Planning (BSP) Deze fase levert een strategisch bedrijfsplan op. Aangezien deze fase geen onderdeel is van het ontwerpen van informatiesystemen zal deze verder buiten beschouwing worden gelaten. 2. Information Strategy Planning (ISP) In deze fase wordt gewerkt aan een strategisch informatieplan. Er wordt hier niet alleen gekeken naar geautomatiseerde informatievoorziening, maar ook naar handmatige informatievoorziening. Er wordt onder andere vastgesteld welke gegevensgebieden en bedrijfsfuncties bestaan en van welke gegevens de bedrijfsfuncties gebruik maken. Gegevensgebieden zijn hierbij klassen van entiteittypen. 3. Business Area Analysis (BAA) De gegevens en functies van de gegevensgebieden die in de ISP-fase zijn gedefinieerd, worden in deze fase verder uitgewerkt. De gegevens en gegevensstromen van het huidige informatiesysteem worden ge¨ınventariseerd. 4. Business System Design (BSD) In deze fase wordt het informatiesysteem ontworpen zonder daarbij te kijken naar specifieke hard- en software. Dit levert onder andere een logische gegevensstructuur, procedures en dialogen (een ontwerp van de schermen die de gebruiker te zien krijgt) op. 5. Technical Design (TD) In deze fase wordt een intern database-schema opgesteld dat afgeleid is van de logische gegevensstructuur. Er wordt gekozen voor een DBMS en besturingssysteem en de hardware-omgeving wordt ontworpen. 18

6. Construction In construction-fase wordt het ‘echte’ informatiesysteem gebouwd. Dit wil zeggen dat onder andere programma’s geschreven worden en databases ge¨ınitialiseerd worden. Tot deze fase behoort ook het testen en documenteren van het systeem. 7. Transaction Deze fase behelst de overgang van het oude naar het nieuwe systeem. Deze overgang verloopt op een strikt geplande manier. 8. Production Tenslotte wordt in deze fase het informatiesysteem gebruikt door de beoogde gebruikers. IE voor gedistribueerde systemen Tagg & Freyberg (1997) hebben een methode ontwikkeld voor het ontwerp van gedistribueerde en co¨ operatieve informatiesystemen. Deze methode bestaat uit de volgende fasen: 1. Aligning the information strategy to the business Tagg & Freyberg stellen hiervoor een aantal aanpassing aan de ISP-fase van IE voor. Zij breiden de analyse van de bedrijfsstrategie uit met de analyse van bedrijfsprocessen. Hiervoor identificeren zij de volgende extra taken: (a) het identificeren van de belangrijkste processen (die processen waar het bedrijf niet zonder kan). (b) het identificeren van technische mogelijkheden. (c) het benchmarken tegen andere organisaties. (d) het modelleren van de bestaande bedrijfsarchitectuur. (e) het herontwerpen van de belangrijkste processen. (f) het modelleren van de gewenste bedrijfsarchitectuur. (g) het formalizeren van de bedrijfsstrategie. Bij het formuleren van de benodigde informatie komt meer nadruk te liggen op de locatie van de benodigde informatie, omdat het informatiesysteem niet langer binnen de grenzen van een kantoor hoeft te vallen. De identificatie van informatiesystemen in verschillende gebieden wordt in deze methode gedaan op verschillende type clusters: ˆ Network Deze gebieden dienen op verschillende netwerken geplaatst te worden. Deze kunnen eventueel nog via een gateway met elkaar gekoppeld worden. ˆ Analysis Deze gebieden zijn voldoende logisch gescheiden om aparte deelprojecten voor verdere analyse te vormen. ˆ Shared Data Deze gebieden worden beschouwd als aparte databases. ˆ Sub-systems Deze gebieden stellen subsystemen voor waarvan het logisch is ze samen te ontwerpen als een systeem of subsysteem.

19

2. Preparing a technical architecture plan In deze fase wordt de technische architectuur opgesteld. Dit houdt in dat software, hardware en communicatiemiddelen gekozen worden. 3. Network design In deze fase wordt het netwerk ontworpen. Tot deze fase behoren onder andere: het opstellen van een geografische kaart, het analyseren van de te versturen berichten, het inschatten van het toekomstige netwerkverkeer en het vergelijken van verschillende soorten netwerken. 4. Designing shared data Deze fase gaat in op het ontwerpen van een gedeelde datastuctuur. Hierbij moet er rekening gehouden worden met de performance van verschillende soorten query’s. 5. Design within an individual system or sub-system In deze fase worden de daadwerkelijke systemen en subsystemen ontwikkeld. Hiervoor stellen Tagg & Freyberg een aanpak voor die een combinatie is van de volgende vier stijlen: ˆ Top-down ˆ Bottom-up ˆ Component engineering. Deze methode gebruikt zowel de top-down- als bottom-up-aanpak. Het idee hierbij is om de delen van het te ontwerpen systeem te koppelen aan de ‘standaardstructuur’ (een boomstructuur) van applicatietypen. ˆ Cooperative agreement Deze aanpak kan gebruikt worden indien er geen nieuwe functionaliteiten nodig zijn, maar er ‘slechts’ ge¨ısoleerde systemen ge¨ıntegreerd moeten worden. De belangrijkste taken die hiervoor uitgevoerd moeten worden zijn:

– het bereiken van overeenstemming over de doelen van het gecombineerde systeem. – het opstellen van contracten en verantwoordelijkheden van alle deelnemende partijen. – het bereiken van overeenstemming over de interfaces. – het samenvoegen van de systemen volgens de vastgestelde interfaces. – het bouwen van overkoepelende maatregelen die bijvoorbeeld zorgen voor beveiliging en privacy. DOSEE Rauch (1996) heeft als directeur van de Emerging Technologies Group de DOSEE-methode (Distributed Open Systems Engineering) beschreven. Deze methode gaat in op het ontwerp van informatiesystemen bestaande uit verschillende applicaties die door middel van open standaarden met elkaar communiceren. Tot deze methode behoren de volgende fasen: 1. Business-Oriented Phase In deze fase wordt een missie voor het te ontwikkelen systeem opgesteld en worden de bedrijfsdoelen geformuleerd. Zowel de richting die het bedrijf op korte als op 20

lange termijn op wil zijn hierbij van belang. Aan de hand van deze bedrijfsdoelen worden de technologische doelen op hoog niveau gedefinieerd. In deze fase ligt veel nadruk op het verkrijgen van commitment op topmanagementniveau. 2. Application-Expert Phase Toekomstige gebruikers geven in deze fase in interviews de requirements aan. Deze interviews dienen onder andere als input voor het opstellen van een tabel met de bedrijfsfuncties en de activiteiten die deze functies uitvoeren. Vervolgens wordt een matrix opgesteld van de activiteiten en de applicaties die deze activiteiten ondersteunen. Tenslotte worden de mogelijkheden voor client/server computing onderzocht. 3. Architectural Phase De bedrijfsdoelen, het bedrijfsbeleid, de eisen van de gebruikers en de technologische trends zijn in deze fase een input voor het ontwerpen van een abstract referentiemodel. Dit model wordt onder andere gebruikt voor het communiceren van idee¨en van de ontwerpers naar andere personen in de organisatie. 4. Infrastructure Phase In deze fase wordt een matrix opgesteld van de applicaties die met elkaar moeten kunnen samenwerken. Van deze applicaties en de interacties van deze applicaties worden de attributen vastgesteld. Attributen van applicaties zijn bijvoorbeeld het beveiligingsniveau en de manier waarop de gebruiker input kan geven. Attributen van interacties tussen applicaties zijn bevoorbeeld het type verbinding en de benodigde snelheid van de interactie. De ontwerpers stellen gewenste services vast. Een service is een hoog-niveau beschrijving van een bepaalde functionaliteit die in software ge¨ımplementeerd kan worden om aan een bepaalde eis voor een applicatie te voldoen. Applicaties benaderen een service via een interface. De waarden van de attributen worden gekoppeld aan de services. Een kalenderapplicatie kan bijvoorbeeld gekoppeld worden aan de printservice of de authenticatieservice. Vervolgens worden de services gekoppeld aan de specificaties van interfaces en standaarden. 5. Standards-Selection Phase Deze fase levert een overzicht op van welke onderdelen van de architectuur (zoals services, interfaces en protocollen) moeten worden gestandaardiseerd. Verder wordt er een overzicht gemaakt van verschillende beschikbare standaarden en wordt er een standaard geselecteerd. 6. Implementation-Planning Phase In deze fase wordt een vertaalslag gemaakt van de conceptuele wereld naar de echte wereld. Tot de werkzaamheden behoren onder andere: het berekenen van de kosten, het bepalen hoe de applicaties gedistribueerd worden en het bepalen van de volgorde van implementatie van de verschillende applicaties. 7. Migration-and-Deployment Phase Deze fase sluit het ‘papieren’ ontwerp af en start de migratie naar een echt systeem. Hiertoe behoren onder andere het maken van een planning, het kiezen van een migratie-strategie en het beslissen wat er gedaan wordt met de investering van de

21

legacy-systemen. Het resultaat van deze fase is een werkend systeem dat gebruikt kan worden door de beoogde gebruikers. 8. Feedback-and-Maintenance Phase Na oplevering van het systeem begint deze fase waarin het systeem continu verbeterd wordt. Start-architectuur De door de Belastingdienst ontworpen startarchitectuur gaat uit van drie situaties: huidig, ooit en straks (Belastingdienst, 2000). De ooit-situatie geeft de gewenste situatie op de lange termijn aan en de straks-situatie geeft de gewenste situatie aan het eind van het project aan. Door een ooit-situatie te defini¨eren wordt nagedacht over toekomstige ontwikkelingen en wordt niet slechts een korte termijn oplossing bedacht. Een startarchitectuur (het product dat gemaakt wordt door toepassing van de startarchitectuur) bestaat uit een systeemconcept en een applicatie-architectuur voor de huidige situatie en de straks- en ooitsituatie. Het systeemconcept bestaat uit een contextdiagram, behandelingscategoriediagrammen en procesdiagrammen. Het contextdiagram geeft aan welke partijen betrokken zijn bij het informatiesysteem. De bedrijfsprocessen worden in de behandelingscategoriediagrammen gesorteerd: soortgelijke bedrijfsprocessen komen in dezelfde categorie te staan. De procesdiagrammen worden gebruikt voor de specificatie van de bedrijfsprocessen. De applicatie-architectuur bestaat uit een contextdiagram dat de samenhang tussen de verschillende applicaties laat zien en een compositiediagram dat laat zien hoe de applicaties opgebouwd zijn. Een detaildiagram kan eventueel aangeven uit welke onderdelen de deelapplicaties bestaan. De applicatie-architectuur kan pas ontwikkeld worden als het systeemconcept van de betreffende situatie afgerond is. Daarnaast kan het systeemconcept van de ooit-situatie pas gemaakt worden zodra die van de huidige situatie afgerond is. Het systeemconcept van de straks-situatie kan pas gemaakt worden als die van de ooit-situatie afgerond is. Rapid Service Development Methodology De Rapid Service Development Methodology, ontwikkeld door het Telematica Instituut (2000), is zoals de naam al aangeeft een methodologie en geen methode voor de ontwikkeling van informatiesystemen. Een methodologie wil zeggen een verzameling van principes die voor een specificieke situatie gereduceerd moet worden tot een methode die geschikt is voor die specifieke situatie. De methodologie richt zich op de ontwikkeling van interorganisationele bedrijfsprocessen en informatiesystemen door het hergebruik van softwarecomponenten. De methodologie is daarnaast tool-supported: er wordt ondersteuning voor de ontwikkeling van processen en informatiesystemen geboden met software tools. Het hergebruik van softwarecomponenten en het gebruik van tools maakt een snelle ontwikkeling mogelijk. Het framework dat wordt gebruikt voor de RSD is weergegeven in figuur 4.5. Het framework geeft links de bedrijfskundige aspecten en rechts de technische aspecten weer. Het onderscheidt de volgende zeven verschillende aspecten, zogenaamde hoekstenen: ˆ Ambition & Scope Deze hoeksteen gaat in op waarom de interactie tussen verschillende bedrijven nodig is en een aantal andere hoog-niveau aspecten, zoals de problemen in de huidige situatie, de stakeholders en de reden waarom nieuwe services ontwikkeld

22

Ambition & Scope

Networked Enterprise

Systems

Transaction Scenario's

Systems Components

Procedures

Protocols

Figuur 4.5: Het RSD framework (gebruikt met toestemming van het Telematica Instituut (2000))

moeten worden. Deze aspecten worden op hoog-niveau beschreven in natuurlijke taal. ˆ Networked Enterprise Models Hierin wordt geschreven welke partijen op welke manier samenwerken. Zowel de rollen die de partijen spelen in de samenwerking als de informatie- en goederenstromen tussen hen worden geanalyseerd. Hiervoor kan zowel een model als natuurlijke taal gebruikt worden. ˆ Transaction Scenario’s Dit zijn de interorganisationele bedrijfsprocessen en -transacties. Procesmodellen of natuurlijke taal worden gebruikt om het gedrag van actoren te beschrijven. ˆ Procedures Hierin wordt gedetailleerd beschreven hoe de berichtuitwisseling plaatsvindt, welk formaat het bericht heeft en welk datamodel gebruikt wordt. Hiervoor worden onder andere DFD’s, datamodellen en control-flow-modellen gebruikt. ˆ Protocols Dit is een laag niveau beschrijving van de netwerkprotocollen en programmacode voor de uitwisseling van berichten. ˆ System Components Dit is een beschrijving van de componenten die nodig zijn voor de samenwerking. Elk component heeft een duidelijke interface en is goed gedocumenteerd. Het gedrag van elk component kan bijvoorbeeld in UML beschreven worden. ˆ Systems Dit is een hoog-niveau beschrijving van de systemen die gebruikt worden voor de ondersteuning van de samenwerking. Er wordt onder andere omschreven welke componenten gebruikt worden en hoe deze verbonden zijn.

Het framework kan op verschillende manieren doorlopen worden voor de ontwikkeling van informatiesytemen. De methoden die gebruikt kunnen worden zijn: 23

ˆ Top-down approach Deze aanpak is van oudsher alleen op technologie gericht. Ook al is het mogelijk bedrijfskundige aspecten in deze methode te verwerken, is deze niet echt geschikt voor e-business engineering. ˆ Evolutionary approach Deze methode is incrementeel en iteratief: zowel de processen als de systemen worden steeds verbeterd. ˆ Emerging approach Deze aanpak is gebaseerd op de werkwijze die gebruikt is in reeds behandelde cases en die in zichzelf in het verleden bewezen hebben. ˆ Legacy system integration Deze methode is geschikt voor het hergebruik en de integratie van legacy systemen in nieuwe situaties.

4.1.3

Evaluatie methoden

Hoewel ISAC en IE oude methoden zijn, geven zij nog steeds een compleet beeld van de stappen die uitgevoerd moeten worden voor de ontwikkeling van informatiesystemen. Deze methoden zijn echter gericht op de ontwikkeling van organisationele informatiesystemen en niet van interorganisationele informatiesystemen. Ze missen de stap van het analyseren van het bedrijfsnetwerk. De methode van Tagg & Frey richt op het ontwerp van gedistribueerde systemen. Deze methode kan ook gebruikt worden voor het ontwerp van interorganisationele informatiesystemen. De nadruk zal dan vooral komen te liggen op hoe de applicaties tussen verschillende bedrijven verdeeld (gedistribueerd) worden en niet zozeer op wat de bedrijven samen met het informatiesysteem proberen te bereiken. De methode richt zich sterk op de qua performance optimale distributie van applicaties en data. Bij interorganisationele informatiesystemen spelen vaak echter andere redenen voor bepaalde manieren van distribueren een rol, zoals de privacy van klanten en de concurrentiegevoeligheid van informatie. Er wordt ook geen analyse gemaakt van het bedrijfsnetwerk. Desalniettemin is deze methode geschikter voor het ontwerp van interorganisationele informatiesystemen dan ISAC of IE. De DOSEE-methode is duidelijk gericht op het ontwerp van informatiesystemen bestaande uit redelijk los gekoppelde applicaties. Er ligt een duidelijke nadruk op welke informatie op welke manier tussen applicaties moet worden uitgewisseld. Deze methode is goed bruikbaar voor het ontwerp van interorganisationele informatiesystemen, indien er ook een bedrijfsnetwerkanalyse aan toe wordt gevoegd. De startarchitectuur legt de nadruk op de afstemming van bedrijfsprocessen en applicaties. Omdat processen over afdelingsgrenzen en dus mogelijk ook over organisatiegrenzen heengaan, is het mogelijk deze methode ook voor de ontwikkeling van IOS-en te gebruiken. Het is hierbij wel van belang dat hiervoor niet alleen een analyse uitgevoerd wordt van de doelen en strategie¨en van ´e´en bedrijf, maar van alle bedrijven in het contextdiagram. Daarnaast moet goed duidelijk gemaakt worden waarom de samenwerking gewenst is. De RSD Methodology geeft een duidelijk overzicht van welke aspecten een rol spelen in de ontwikkeling van informatiesystemen. Zij geeft ook een handvat voor de analyse van 24

het bedrijfsnetwerk en de analyse van de interacties van de verschillende partijen. De RSD Methodology geeft echter geen stappenplan voor de ontwikkeling.

4.2

Medische archieven en coderingen

In deze paragraaf zullen de voornaamste Nederlandse medische archieven en coderingen besproken worden. De archieven worden onder andere gebruikt voor het verkrijgen van statistische informatie. De coderingen worden gebruikt voor het weergeven van een bepaalde soort informatie op een eenduidige manier. In sommige gevallen bestaan er verschillende coderingen voor dezelfde soort informatie. LAZR De LAZR (Landelijke Ambulante Zorg Registratie) bevat poliklinische gegevens en wordt bijgehouden sinds 1992. Circa 75% van de ziekenhuizen levert LAZR-informatie aan Prismant. Prismant is een non-for-profit organisatie ontstaan uit een fusie van SIG (Stichting Informatiecentrum voor de Gezondheidszorg) en NZi (Nationaal Ziekenhuisinstituut), organisaties die tientallen jaren in de zorgsector werkzaam waren. De meeste ziekenhuizen geven hierbij alleen eerste polikliniekbezoeken door, d.w.z. het eerste consult bij een bepaald specialisme (Ministerie van VWS, 2001a). De LAZR is bedoeld als een administratief systeem en bevat derhalve geen medische informatie. Prismant levert aan de hand van deze gegevens adherentiegetallen en spiegelinformatie aan ziekenhuizen. De adherentiegetallen worden naar het Ministerie van VWS gestuurd en mede op basis van deze getallen wordt het budget bepaald. De spiegelinformatie stelt ziekenhuizen in staat zichzelf te vergelijken met andere ziekenhuizen. De registratie is opgebouwd uit drie gegevensssets: de Basisgegevensset, Alle Contacten en Spreekuren. De Basisgegevensset is bedoeld als landelijke gegevensverzameling die nodig is voor de berekening van de poliklinische adherentie op basis van eerste polikliniekbezoeken. Van de gegevensset Alle Contacten kan informatie worden afgeleid over onder meer de poliklinische productie, waaronder informatie over herhalingsfrequentie. De gegevensset Spreekuren levert informatie over planning en realisatie van de poliklinische bereikbaarheid. In 2001 leverden 108 van de 120 ziekenhuizen de Basisgegevensset, 46 ziekenhuizen de gegevensset Alle contacten en 8 ziekenhuizen de gegevensset Spreekuren (Ministerie van VWS, 2001a). De frequentie van levering is afhankelijk van de afspraken die het ziekenhuis met Prismant heeft gemaakt. LMR De LMR (Landelijke Medische Registratie) is opgezet ten behoeve van onderzoek en beleid. Deze registratie bevat zowel medische als administratieve gegevens over klinische behandelingen en dagverplegingen. Ziekenhuizen leveren LMR-gegevens aan Prismant en Prismant levert ziekenhuizen aan de hand van deze gegevens adherentiegetallen en spiegelinformatie. De registratie vindt plaats bij het ontslaan van een pati¨ent. Vrijwel 100% van de ontslagen wordt geregistreerd. (Ministerie van VWS, 2001a) De LMR maakt gebruikt van de CvZ (Classificatie van Ziekten) en de CvV (Classificatie van Verrichtingen). Deze classificaties zullen in de subparagraaf Codestelsels nader toegelicht worden. Statistiek Informatiesysteem Het Statistiek Informatiesysteem heeft als doel het leveren van gestandaardiseerde informatie ten behoeve van beleid en planning van particuliere zorgverzekeraars en koepelorganisaties. VEKTIS, de standaardisatiekoepel van verzekeraars, beheert dit archief. Het bevat de schade-, verzekerings- en verzekerden25

kenmerken van de Nederlandse particuliere zorgverzekeraars. Er wordt gebruikt gemaakt van de Classificatie van het College Tarieven Gezondheidszorg (CTG) voor verrichtingen en de AGB-Z codering (Ministerie van VWS, 2001a). Farmacie Informatiesysteem Dit door VEKTIS beheerde systeem bevat maandelijks door ziekenfondsverzekeraars aangeleverde gegevens over het aantal geleverde medicijnen, de kosten ervan, welke artikelen het betreft, wie de leverancier is, wie de voorschrijver is en welke verzekerde de afnemer is. Het is de bedoeling dat particuliere verzekeraars op termijn ook hun gegevens leveren (Ministerie van VWS, 2001a).

4.2.1

Codestelsels

Codestelsel zijn lijsten met codes en een bijbehorende omschrijving, waarmee informatie eenduidig kan worden vastgelegd. In de Nederlandse gezondheidszorg worden de volgende codestelsels gebruikt: CBV-bestanden Het CBV (Centraal Bureau Verrichtingen) beheert enkele bestanden voor medische en paramedische verrichtingen waaronder de Classificatie van Medisch Specialistische Verrichtingen (CMSV). Deze bestanden zijn bedoeld voor intern gebruik in ziekenhuizen. Door het CBV wordt een relatie onderhouden tussen de CvV-codering voor de LMR en de CTG-codering voor facturatie. CvV De door Prismant beheerde CvV (Classificatie van Verrichtingen) bevat medisch specialistische verrichtingen die gebruikt worden voor de LMR. Dit bestand is minder uitgebreid van de bestanden van het CBV. CTG Het College Tarieven Gezondheidszorg stelt de tarieven voor instellingen en individuele beroepsbeoefenaars vast. Het CTG-bestand bevat offici¨ele tariefcodes met omschrijving en de, bij de betreffende tariefcode, relevante specialismen. Bij elk tarief is de ingangsdatum van het betreffende tarief opgenomen (Stichting CBV, 2003). CTGcodes worden gebruikt voor facturatie aan de verzekerde (bij particulier verzekerden) of declaratie aan de ziekenfondsverzekeraar. LMR specialisme codering Deze codering bevat medische specialismen en wordt gebruikt in de LMR. AGB-Z De AGB-Z-codering (Algemeen Gegevensbeheer Zorgverleners) is ook een codering voor medische specialismen. Deze codering wordt gebruikt voor de declaraties van ziekenhuizen naar verzekeraars en voor de aanlevering van statistische informatie van verzekeraars aan VEKTIS. CvZ De Classificatie van Ziekten is gebaseerd op ICD9-CM, een standaard beheerd door de World Health Organization. Deze tabel wordt gebruikt voor de registratie van diagnoses van ziekten.

4.3

Privacywetgeving

Deze paragraaf schetst een wettelijk kader aangaande de privacy van de pati¨ent. De invoering van DBC’s zal namelijk als gevolg hebben dat ziekenhuizen en verzekeraars meer informatie over de pati¨ent uitgewisselen. De Wet Bescherming Persoonsgegevens Sinds 1 september 2001 is de Wet Bescherming Persoonsgegevens van kracht. Deze wet geeft burgers recht op inzage en correctie van zijn persoonsgegevens, recht op een motivatie op beslissingen die zijn 26

gemaakt op basis van zijn persoonsgegevens en een recht op verzet indien de burger het oneens is met het gebruik van zijn persoonsgegevens. Daarnaast mogen organisaties alleen persoonsgegevens verzamelen indien zij van tevoren een duidelijk omschreven doel hebben geformuleerd. Dit doel moet een goede reden bevatten en/of de burger moet toestemming hebben gegeven voor de overname van zijn persoonsgegevens. Daarnaast moet de burger ge¨ınformeerd worden over waarvoor zijn gegevens gebruikt gaan worden. Gegevensverwerkers hebben de plicht persoonsgegevens buiten bereik van onbevoegden en personen die geen rol hebben in de verwerking te houden. De organisaties moeten de verwerking van persoonsgegevens aanmelden bij het College bescherming persoonsgegevens Enkele organisaties en soorten registraties hebben vrijstelling van deze wet (Ministerie van Justitie, 2003). De Wet Geneeskundige BehandelOvereenkomst De Wet op de Geneeskundige BehandelingsOvereenkomst is een specifieke wetgeving die op het terrein van de gezondheidszorg. Deze wet is van toepassing op pati¨entdossiers die worden aangelegd en bijgehouden voor/door medische hulpverleners. Deze dossiers bevatten medische gegevens, dit wil zeggen alle gegevens betreffende iemands lichamelijke of geestelijke gezondheid in het verleden, heden of in de toekomst, alsmede genetische gegevens. De WBP en WGBO zijn ook geen lex specialis (dit wil zeggen dat de bepalingen van de ene wet geprevaleerd worden boven die van de andere wet) ten opzichte van elkaar, maar vullen elkaar aan. De medische gegevens van een pati¨ent mogen niet aan derden worden verstrekt, tenzij de pati¨ent hier toestemming voor gegeven heeft. Wel mogen de gegevens gebruikt worden voor het opstellen van statistieken of het doen van onderzoek, tenzij de pati¨ent dit verboden heeft. De pati¨ent heeft zowel recht op inzage als het recht om niet ge¨ınformeerd te worden. Daarnaast moet informatie die de gezondheid van de pat¨ıent ernstig kan benadelen niet aan de pati¨ent worden versterkt (Oderendorff, 1999). Medisch Beroepsgeheim Het medisch beroepsgeheim bepaalt dat individuele hulpverleners geen informatie over hun pati¨enten aan derden mogen verstrekken. Deze geheimhoudingsplicht is sterker dan de geheimhoudingsplicht op basis van de WGBO. Op grond van een wettelijk voorschrift of met toestemming van de pati¨ent kan deze zwijgplicht doorbroken worden (Oderendorff, 1999).

27

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Requirementsanalyse

Probleemanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

5. Ontwerpmethode Dit hoofdstuk toont de ontwerpmethode die gebruikt zal worden voor het ontwerp van de architectuur. Dit hoofdstuk bevat dus een antwoord op onderzoeksvraag 6 (“Welke ontwerpstappen zijn nodig voor het ontwerp van de architectuur?”). Het vorige hoofdstuk heeft een overzicht gegeven van enkele ontwerpmethoden en het heeft de ontwerpstappen van deze methoden behandeld. Dit hoofdstuk filtert de stappen uit de verschillende methoden die voor dit specifieke onderzoek gebruikt kunnen worden.

5.1

Probleemanalyse

De regering is net als in de ISAC-methode van een probleem-situatie uitgegaan. Zij heeft geanalyseerd wat de problemen zijn in de FB-situatie en wat de oorzaken van deze problemen zijn. De problemen, de oorzaken ervan en de oplossingsrichting zullen eerst in het volgende hoofdstuk besproken worden om een overzicht te geven van de achtergrond van het DBC-project. Na de bespreking van de globale veranderingen, zal een probleemanalyse uitgevoerd worden aan de hand van de piramide in figuur 5.1. Deze piramde wordt tweemaal top-down doorlopen: ´e´enmaal voor de huidige situatie en ´e´enmaal voor de gewenste situatie.

Doelen netwerk

Strategieën netwerk

Doelen ziekenhuis

1

Strategieën ziekenhuis

Doelen verzekeraar

2

Strategieën verzekeraar

Interorganisationele bedrijfsprocessen

Bedrijfsprocessen ziekenhuis

Informatie ziekenhuis

Interactieprocessen

Applicaties ziekenhuis

Bedrijfsprocessen verzekeraar

Applicaties verzekeraar

Informatie verzekeraar

3

Figuur 5.1: Analysepiramide Voor de analyse van de huidige situatie zal naar de volgende aspecten gekeken worden (aangegeven in figuur 5.1 met niveau 1): 1. het bedrijfsnetwerk Dit deel beschrijft de doelen en strategie¨en van het bedrijfsnetwerk. Dit zijn dus de doelen en strategie¨en die de bedrijven samen proberen te bereiken. Deze stap is overgenomen van de enige in hoofdstuk 4 besproken methode die ingaat op de samenwerking tussen bedrijven: RSD. Voor de ontwikkeling van samenwerkende informatiesystemen is het natuurlijk belangrijk te weten waarom er een samenwerking bestaat. 28

2. de bedrijven In dit stuk worden de doelen en strategie¨en van de afzonderlijke bedrijven beschreven. Ook zal duidelijk gemaakt worden welke partijen binnen de bedrijven een rol spelen bij de overgang van de huidige naar de gewenste situatie. Het in 1981 ge¨ıntroduceerde IE beschreef deze stap al en deze stap is in vele andere ontwerpmethoden overgenomen. Deze stap is erg belangrijk om het bedrijfsbeleid aan te laten sluiten op het IT-beleid en niet vanuit twee verschillende visies te werken. 3. de bedrijfsprocessen De bedrijfsprocessen die vallen binnen de scope van de opdracht zullen hier gemodelleerd worden. Deze processen modelleren onder andere welke interacties er zijn tussen ziekenhuizen en verzekeraars. Alle in hoofdstuk 4 besproken ontwerpmethoden gaan in meer of mindere mate in op de activiteiten die de applicaties moeten ondersteunen. In een methode als de start-architectuur worden bijvoorbeeld complete bedrijfsprocessen gemodelleerd, terwijl in bijvoorbeeld DOSEE slechts activiteiten van bedrijfsfuncties ge¨ıdentificeerd worden. RSD stelt dat bedrijfsprocessen ook in natuurlijke taal specificeerd kunnen worden in plaats van in procesmodellen (zoals Petri-nets en UML activity diagrammen). Aangezien in dit onderzoek vele activiteiten zullen veranderen en veel nieuwe activiteiten ingevoerd zullen worden, zullen complete bedrijfsprocessen gemodelleerd worden in plaats van alleen losse activiteiten. De processen zullen gemodelleerd worden in UML activity diagrammen, aangezien deze exacter zijn dan natuurlijke taal. 4. de informatie Dit deel geeft de in- en outputinformatie van de verschillende processtappen weer in Data Flow Diagrams (DFD’s). DFD’s worden in oude methoden als IE, maar ook in hele moderne methoden als RSD gebruikt. DFD’s maken het mogelijk informatiestromen grafisch weer te geven. De activiteiten worden hierbij overgenomen uit de UML activity diagrammen die de bedrijfsprocessen modelleren. Vervolgens worden de in- en outputinformatie van die activiteiten vastgesteld en wordt vastgesteld welke informatie opgeslagen dient te worden in zogenaamde data stores. De modelleren van informatie is erg belangrijk, aangezien applicaties doorgaans niets anders zijn dan informatieverwerkende systemen. 5. de applicaties Per processtap worden de ondersteunende applicaties aangegeven. Daarnaast zal er een korte omschrijving van deze applicaties gegeven worden. Voor het ontwerp van een nieuwe applicatie-architectuur is het natuurlijk altijd nodig te weten welke applicaties in de huidige situatie gebruikt worden, aangezien het meestal niet de bedoeling is dat ‘from scratch’ begonnen wordt. Deze stap geeft antwoord op onderzoeksvraag 2 (“Welke applicaties worden in de huidige situatie gebruikt door ziekenhuizen en verzekeraars?”) Vervolgens zal de gewenste situatie geanalyseerd worden op die aspecten aangegeven met niveau 2 in figuur 5.1. Deze aspecten vallen namelijk buiten de ontwerpscope van dit onderzoek, met andere woorden: deze worden beschreven aan de hand van documenten, media, literatuur en interviews en als vaststaand aangenomen. Deze analyse geeft een 29

gedeeltelijk antwoord op onderzoeksvraag 3 (“Welke informatievoorziening is nodig in het proces van de administratieve afhandeling van DBC’s?”). Er wordt namelijk beschreven welke processtappen (activiteiten) zijn te onderscheiden in het proces van de afhandeling van DBC’s. Daarnaast wordt een overzicht gegeven van de in- en outputinformatie van de verschillende processtappen. Niveau 3 in figuur 5.1 geeft aan wat binnen de ontwerpscope van dit onderzoek valt. De volgende paragrafen gaan hier verder op in.

5.2

Requirements-analyse

De requirements-analyse zal een antwoord geven op onderzoeksvraag 1 (“Welke problemen dient de te ontwikkelen architectuur op te lossen?”). Allereerst maakt de requirements-analyse hiervoor duidelijk welke stakeholders er zijn en welke belangen deze hebben. Een informatiesysteem wordt immers vrijwel nooit gemaakt voor ´e´en partij. Meestal bestaan er verschillende groepen gebruikers en bestaan er daarnaast partijen die op andere manieren belang hebben bij een nieuw informatiesysteem. Een eigenaar van een bedrijf moet het informatiesysteem bijvoorbeeld financieren, een beveiligingsmedewerker moet het beveiligen en de EDP-auditor moet de werking ervan controleren. De eisen van de verschillende stakeholders worden net als in DOSEE achterhaald aan de hand van interviews. Indien nodig zullen ook nog media en documenten gebruikt worden. De eisen bestaan uit functionele eisen en niet-functionele eisen. Functionele eisen gaan over de functionaliteit van het systeem en niet-functionele eisen gaan over overige kenmerken, zoals performance, gebruiksvriendelijkheid en uitbreidbaarheid. De niet-functionele eisen zullen ingedeeld worden aan de hand van een ISO/IEC framework. Het gebruik van een bestaand framework zorgt ervoor dat bepaalde categorie¨en nietfunctionele eisen niet vergeten worden. Tenslotte zal dit onderdeel aangeven welke eisen tegenstrijdig zijn en welke prioriteiten de eisen hebben.

5.3

Ontwerp

Het ontwerp bestaat uit de volgende drie stappen: het genereren van alternatieven, het ontwerp van een conceptueel model en het ontwerp van een gedetailleerd model. In dit deel zullen aan de hand van het programma van eisen enkele alternatieve oplossing besproken worden. Deze alternatieven verschillen in hun manier van communiceren. De manier van communiceren van applicaties heeft namelijk een grote invloed op het verdere architectuurontwerp. Het genereren van alternatieven zal hiermee een antwoord geven op onderzoeksvraag 5 (“Welke standaarden kunnen gebruikt worden voor de communicatie tussen de componenten?”) Het conceptueel model geeft vervolgens een overzicht van welke applicaties nodig zijn in de gewenste situatie. Dit geeft een antwoord op de laatste subvraag van onderzoeksvraag 5 (“Welke informatievoorziening is nodig in het proces van de administratieve afhandeling van DBC’s?”). Deze subvraag is “Welke (soort) applicaties zijn geschikt voor ondersteuning van deze processtap bij ziekenhuis en verzekeraar?”). Het conceptueel model beschrijft de functies van deze applicaties tekstueel. Tevens worden de belangrijkste beveiligingsconcepten behandeld. Dit komt overeen met het systeemontwerp, de hoogniveau beschrijving van de systemen die gebruikt worden voor de ondersteuning van de samenwerking, van onder andere IE en RSD.

30

De applicaties uit het conceptueel model die de grootste veranderingen ondergaan worden vervolgens in een gedetailleerd model verder uitgewerkt. Dit is een subsysteem- of systeemcomponentbeschrijving, zoals dit in IE respectievelijk RSD genoemd wordt. Het gedetailleerd model legt de nadruk op welke functies de subsystemen uitvoeren, welke informatie de verschillende subsystemen (ofwel applicaties) uitwisselen en welke informatie in de subsystemen opgeslagen wordt. Van de geselecteerde applicaties zullen hiervoor een Function Refinement Tree (FRT) en een Data Flow Diagram (DFD) opgesteld worden. Communicatiediagrammen zullen duidelijk maken welke informatie de applicaties met elkaar uitwisselen. Deze diagrammen geven dus samen met de conceptuele architectuur een antwoord op onderzoeksvraag 7 (“Hoe ziet een architectuur die aan de gestelde eisen voldoet eruit?”)

5.4

Evaluatie

Het ontwerp zal getoetst worden aan de eisen die in de requirements-analyse opgesteld zijn. Dit hoofdstuk is hiermee eigenlijk het opstapje naar de conclusies, waarin resultaten van het onderzoek worden besproken.

31

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

6. Probleemanalyse Dit hoofdstuk zal aangeven voor welke veranderingen in de gezondheidszorg DBC’s zorgen. Hierbij wordt met name ingegaan op de veranderingen voor ziekenhuizen en verzekeraars.

6.1 6.1.1

Veranderingen in de zorg Aanbodgerichte zorg

Wat zijn de kosten van een niertransplantatie, het bezet houden van een ziekenhuisbed voor een week of een spoedoperatie aan het hart? Niemand kan hier een precies antwoord op geven. Hoewel ziekenhuizen zeer sterk aan wetten en regels gebonden zijn, hebben zij zeer weinig inzicht in de werkelijke kosten van de geleverde producten. Deze vreemde tegenstelling wordt voornamelijk veroorzaakt door de de aanbodgerichtheid van het Nederlandse zorgstelsel. Pati¨enten, zorgaanbieders en zorgverzekeraars staan ten opzichte van elkaar in een driehoeksverhouding gereguleerd door een sterk sturende overheid (zie figuur 6.1). Verzekerde/ patiënt

Overheidsregulering Zorgaanbieder

Zorgverzekeraar

Figuur 6.1: Verhoudingen in aanbodgerichte gezondheidszorg (Ministerie van VWS, 2001b) Deze sturing door de overheid is ingevoerd door de noodzaak van kostenbeheersing; er werd voornamelijk gestreefd de loonkostenontwikkeling te beheersen gedurende een periode van stijgende werkloosheid en beperkte economische groei (Ministerie van VWS, 2001b). Voor alledrie de partijen in de driehoek is de overheidsinvloed goed te merken. Zorgaanbieders hebben toestemming van de overheid nodig hun bedrijf te starten. De overheid bepaalt per regio wat de benodigde ziekenhuiscapaciteit is en laat op basis van die gegevens ziekenhuizen toe. Het jaarlijkse volume aan zorg dat een ziekenhuis biedt, wordt in onderhandelingen met de zorgverzekeraars bepaald. Het College Tarieven Gezondheidszorg (CTG) bepaalt de prijs die het ziekenhuis in rekening brengt. Zorgverzekeraars zijn te onderscheiden in ziekenfondsen en particuliere verzekeraars (deze zijn vaak wel ondergebracht in ´e´en ondernemening). Ziekenfondsen hebben een acceptatie- en zorgplicht. Dit wil zeggen dat zij verplicht zijn pati¨enten te verzekeren en van zorg te voorzien. Om aan de zorgplicht te voldoen sluiten te ziekenfondsen contracten over de hoeveelheid te leveren zorg af met zorgaanbieders. Particuliere ver-

32

zekeraars werken op basis van het restitutiestelsel: de verzekerde heeft recht op schadevergoeding. Zij hebben geen acceptatie- of zorgplicht en sluiten zelf in principe geen overeenkomsten af met zorgaanbieders over te leveren zorg. De particuliere verzekeraar heeft dus de plicht de kosten die de verzekerde heeft gemaakt te vergoeden. De verzekeringspremie is afhankelijk van het risicoprofiel van de verzekerde en de hoogte van het gekozen eigen risico. Verzekerden/pati¨enten hebben een beperkte keuze wat betreft de verzekering en de verzekeraar. Zo hebben ziekenfondsverzekerden geen invloed op het pakket en het eigen risico. Particulier verzekerden hebben beperkte mogelijkheden over te stappen van verzekeraar, omdat zij niet beschermd zijn door een acceptatieplicht. Vooral oudere personen of personen met een ernstige aandoening kunnen vaak alleen van verzekeraar wisselen wanneer zij een zeer hoge premie bij de nieuwe verzekeraar betalen. Enkele van de belangrijkste negatieve effecten van de streng gereguleerde aanbodsturing zijn (DBC2003, 2003b; Deloitte & Touche, 2002; Jochemsem, 2002; Ministerie van VWS, 2001b): ˆ Het zorgaanbod voldoet onvoldoende aan de behoefte van de pati¨ent. De huidige manier van financieren zorgt er namelijk voor dat zorgaanbieders bepalen wat voor zorg er verleend kan worden. Pati¨enten kunnen de aanboden zorg aannemen of weigeren, maar zij kunnen deze niet aan hun wensen aanpassen. ˆ De ruimte voor ondernemerschap, flexibiliteit en innovatie is gering. Regels beperken de handelingsruimte van verzekeraars en zorgaanbieders en nemen de prikkel weg tot vraaggericht handelen. Innoveren heeft vooral voor de zorgaanbieders weinig nut, aangezien dit toch nauwelijks zorgt voor meer opbrengsten. ˆ De doelmatigheid is gering. Omdat er een garantie bestaat dat zorgaanbieders gefinancierd worden ontbreken prikkels om doelmatig te werken. ˆ Er is weinig transparantie in het zorgaanbod: de relatie tussen werkelijke kosten, de werklast en de opbrengst daarvan is onvoldoende duidelijk.

33

6.1.2

Vraaggerichte zorg

Aangezien de sterke aanbodsturing een kwalitatief goed en doelmatig functionerende zorgsector in de weg staat, streeft de overheid naar een vraaggericht systeem. De rollen van de partijen in de driehoek zullen dus gaan veranderen (zie figuur 6.2). Verzekerde/ patiënt

zorgverzekeringsmarkt

zorgverleningsmarkt

Overheidsregulering Zorgaanbieder

Zorgverzekeraar zorginkoopmarkt

Figuur 6.2: Verhoudingen in vraaggerichte gezondheidszorg (Ministerie van VWS, 2001b) Zorgvragers Pati¨enten dienen kritisch te worden ten opzichte en van prijs en kwaliteit van de geleverde gezondheidsdiensten. Een eigen bijdrage kan bijvoorbeeld voor deze kritische houding zorgen. Een nog directere vraagsturing kan verkregen worden door de invoering van een persoonsgebonden budget, dat de pati¨ent in staat stelt de gewenste zorg in te kopen (Ministerie van VWS, 2001b). Zorgverzekeraars Voor zorgverzekeraars moet het mogelijk worden een prijs- en kwaliteitsvergelijking te maken tussen verschillende zorgaanbieders. Zorgverzekeraars en zorgaanbieders zullen moeten gaan onderhandelen over de prijs, het volume en de kwaliteit van de te leveren zorg. Hierdoor dient er meer concurrentie tussen zowel zorgverzekeraars als zorgaanbieders te ontstaan. Zorgaanbieders De opbrengsten van zorgaanbieders zullen afhankelijk zijn van de hoeveelheid geleverde producten, de prijs en kwaliteit ervan. Vanwege de concurrentie zullen zij aan verzekeraars duidelijk moeten aangegeven welke producten zij voor welke prijs leveren en zorgaanbieders zullen moeten weten wat de kostprijs daarvan is (Schaepkens, 2002). Hierdoor zullen ziekenhuizen ook een beter inzicht krijgen in hun eigen processen.

6.1.3

Van FB naar DBC

De huidige bekosting van ziekenhuizen vindt plaats met behulp van een Functiegericht Budget (FB). Het jaarlijks toegewezen budget bepaalt het zorgaanbod. De medisch specialisten krijgen ook jaarlijks een bedrag (het zogenaamde lumpsum) toegewezen. Voor de conversie naar een meer vraaggestuurde zorgmarkt, zal vanaf 2003 een bekostiging op basis van DBC’s ingevoerd worden. Een DBC is het geheel van activiteiten van ziekenhuis en medisch specialist voortvloeiend uit de zorgvraag waarvoor de pati¨ent het ziekenhuis consulteert (Orde van Medisch Specialisten et al., z.j.). De DBC-typeringslijsten (deze lijsten geven de inhoud van de DBC’s weer) worden vast-

34

gesteld door diverse medisch wetenschappelijke verenigingen. Deze DBC’s geven dus weer wat er aan zorg wordt geleverd.

6.2

Analyse huidige situatie

In deze paragraaf zal de huidige situatie beschreven worden. Met de huidige situatie wordt de situatie bedoeld waarin nog geen financiering op basis van DBC’s plaatsvindt. Om de huidige situatie in beeld te brengen worden allereerst de doelstellingen en strategie¨en van het bedrijfsnetwerk in beeld gebracht. Vervolgens worden de doelstellingen en strategie¨en op bedrijfsniveau duidelijk gemaakt. Een verdere analyse van de situatie zal plaatsvinden voor het hypothetisch ziekenhuis Medisch Centrum Oost en de hypothetische verzekeraar Drienerlo Verzekeringen. De bedrijfsprocessen en applicaties verschillen namelijk per ziekenhuis en verzekeraar. In deze analyse wordt getoond hoe de bedrijfsprocessen zouden kunnen verlopen en welke applicaties ter ondersteuning gebruikt zouden kunnen worden.

6.2.1

Bedrijfsnetwerk

De doelstelling van de Nederlandse gezondheidszorg is: onnodige sterfte en vermijdbaar gezondheidsverlies voorkomen en gelijke kansen op gezondheid bevorderen (Ministerie van VWS, 2002) Dit onderzoek zal zich richten op de curatieve (genezende) gezondheidszorg en hierbij met name op ziekenhuizen en zorgverzekeraars. De doelstelling van de curatieve gezondheidszorg luidt: pati¨entgerichte curatieve en palliatieve zorg realiseren voor pati¨enten met lichamelijke aandoeningen, inclusief de genees- en hulpmiddelenvoorziening (Ministerie van VWS, 2002) Palliatief wil hierbij zeggen het verzachten van de verschijnselen van een ziekte zonder de ziekte zelf tot genezing te brengen. De overheid past een sterk aanbodgerichte en gecentraliseerde strategie toe. Dit wil zeggen dat de overheid een sterk sturende functie heeft en dat de overheid het budget, dat voor de gezondheidszorg beschikbaar is, bepaalt aan de hand van de productie van de vorige periode en op basis van de prioriteit die de regering geeft aan bepaalde aspecten van de gezondheidszorg zoals bijvoorbeeld wachtlijsten.

6.2.2

Bedrijven

Deze paragraaf zal de doelstellingen en strategie¨en van ziekenhuizen en verzekeraars in de huidige situatie bespreken. Ziekenhuizen Het doel van ziekenhuizen is: het uitvoeren van medische behandelingen

35

Ziekenhuizen zijn op te delen in de volgende categorie¨en (Raad voor de Volksgezondheid, 2003): ˆ academische ziekenhuizen. Deze ziekenhuizen verlenen pati¨entenzorg die mede ten dienste staat van het wetenschappelijk geneeskundig onderwijs en onderzoek. Tevens verzorgen zij gedeelten van de opleiding tot medisch specialist. ˆ algemene ziekenhuizen. Deze ziekenhuizen richten zich op de levering van medische specialistische zorg op verschillende vakgebieden. Zij leveren het grootste deel van de Nederlandse specialistische zorgproductie. Algemene ziekenhuizen kunnen ingedeeld worden in basisziekenhuizen, grote algemene ziekenhuizen en topklinische ziekenhuizen. Basisziekenhuizen richten zich op de regio en voeren relatief eenvoudige verrichtingen uit. Grote algemene ziekenhuizen hebben een groter afzetgebied dan basisziekenhuizen en bieden meer diensten aan dan basisziekenhuizen. Topklinische ziekenhuizen richten zich op een beperkte pati¨entenpopulatie en voeren dure en gespecialiseerde verrichtingen uit. Deze ziekenhuizen richten zich niet op een bepaalde regio. ˆ categorale ziekenhuizen. Deze ziekenhuizen richten zich op een specifiek deel van de medische specialistische zorg. Deze ziekenhuizen specialiseren zich dus nog verder dan topklinische ziekenhuizen.

Ziekenhuizen passen de volgende drie strategie¨en toe (Raad voor de Volksgezondheid, 2003): 1. fusievorming. De laatste jaren zijn veel kleine algemene en categorale ziekenhuizen gefuseerd. De belangrijkste reden voor deze fusies is kostenbesparing. Fusies tussen ziekenhuizen en andere gezondheidsinstellingen, zoals verpleeg- en verzorgingshuizen, eerstelijnszorg etc, hebben nauwelijks plaatsgevonden. Veel academische ziekenhuizen zijn vanaf midden jaren ’90 gefuseerd met de medische faculteiten. 2. profilering. De verschillende categorie¨en ziekenhuizen profileren zich verschillend. Academische ziekenhuizen combineren complexe pati¨entenzorg met onderzoek en opleiding. De verschillende academische ziekenhuizen hebben elk hun eigen onderzoekszwaartepunten. Enkele topklinische en categorale ziekenhuizen specialiseren zich op landelijk niveau op enkele complexe pati¨entenzorgfuncties. Basisziekenhuizen proberen een zo breed mogelijk zorgaanbod te leveren en richten zich vooral op de regio. 3. concurrentie. Hoewel ziekenhuizen nauwelijks concurreren om klanten, vindt er wel een hevige concurrentie plaats op de arbeidsmarkt. Topklinische ziekenhuizen kunnen het gemakkelijkst personeel aantrekken, vanwege de complexe werkzaamheden en 36

de goede arbeidsvoorwaarden. Basisziekenhuizen hebben vaak moeite met het aantrekken van specialisten, aangezien zij relatief eenvoudige zorg aanbieden. Academische ziekenhuizen bieden specialisten wel complexe werkzaamheden, maar vaak minder goede arbeidsvoorwaarden dan topklinische ziekenhuizen. arbeidsvoorwaarden. Dit onderzoek zal zich richten op academische en algemene ziekenhuizen. Deze voeren namelijk ongeveer dezelfde zorgprocessen uit, wat zorgt voor een zelfde behoefte aan informatiesystemen. De zorgprocessen van categorale ziekenhuizen zijn veel gespecialiseerder op ´e´en bepaald vakgebied en vereisen dus gespecialiseerde informatiesystemen. Een Elektronisch Pati¨enten Dossier (EPD) van een brandwondencentrum of een kankercentrum zal bijvoorbeeld een minder breed scala aan mogelijk diagnoses en behandelingen bieden dan dat van een algemeen ziekenhuis. Dit hoeft bijvoorbeeld niet aan te kunnen geven dat een pati¨ent een gebroken been heeft. Daarnaast zullen informatiesystemen van categorale ziekenhuizen ook geschikt moeten zijn voor het verwerken van gegevens voor zeer specialistisch onderzoek, aangezien categorale ziekenhuizen vaak dergelijk onderzoek uitvoeren. Verzekeraars Het doel van verzekeraars is: het financieren van medische behandelingen met opbrengsten verkregen uit het dragen van financi¨ele risico’s van een groep mensen Verzekeraars zijn op te delen in de volgende categorie¨en: ˆ ziekenfondsverzekeraars. Deze nemen de rol aan van uitvoerder van de ziekenfondswet. Dit type verzekeraars heeft een zorgplicht (de verplichting verzekerden zorg te bieden) en een acceptatieplicht (de verplichting iedereen die zich aanmeldt te verzekeren). ˆ particuliere verzekeraars. De particuliere verzekeraars hebben de rol van schadeverzekeraar. Dit type verzekeraars is minder aan banden gelegd door de overheid. Deze hebben geen acceptatieplicht en kunnen verschillende premies voor verschillende klanten rekenen.

Hoewel deze verzekeringsvormen formeel strikt gescheiden zijn, bieden de meeste verzekeraars beide soorten verzekeringen aan. Deze verzekeringsvormen zijn dan ondergebracht bij verschillende rechtspersonen binnen ´e´en concern (Ministerie van VWS, 2001b). Ziekenfondsverzekeraars passen de volgende strategie¨en toe: 1. volging van overheidsregels. Ziekenfondsverzekeraars moeten voldoen aan de in de Ziekenfondswet gestelde toelatingseisen om de markt te betreden. Vanwege hun acceptatieplicht kunnen ziekenfondsverzekeraars zich maar in beperkte mate op een bepaalde doelgroep richten. De zorgplicht verplicht de ziekenfondsverzekeraars contracten af te sluiten met zorgaanbieders, zodat er voldoende zorg voor de verzekerden beschikbaar is.

37

Particuliere verzekeraars maken gebruik van de volgende strategie¨en: 1. risico-vermijding. Particuliere verzekeraars hebben geen acceptatieplicht. Hierdoor kunnen zij verzekerden, die hoge risico’s lopen op een bepaalde aandoening, uitsluiten voor vergoeding van zorg aan deze aandoening of een hele hoge premie laten betalen. De particuliere verzekeraars lopen hierdoor zo min mogelijk financieel risico. 2. concurrentie. Hoewel het voor ziekenfondsverzekerden mogelijk is van ziekenfondsverzekeraar te wisselen, zijn de financi¨ele prikkels voor de verzekerde dermate beperkt dat er geen sprake is van echte concurrentie. De premies van verschillende particuliere verzekeraars daarentegen kunnen behoorlijk uiteenlopen. Hierdoor bestaat er meer concurrentie tussen particuliere verzekeraars dan tussen ziekenfondsverzekeraars.

6.2.3

Bedrijfsprocessen

Deze paragraaf zal duidelijk maken hoe de belangrijkste bedrijfsprocessen van het hypothetisch ziekenhuis Medisch Centrum Oost en de hypothetische verzekeraar Drienerlo Verzekeringen verlopen. Deze processen zijn opgesteld aan de hand van de antwoorden die in interviews gegeven zijn. Ziekenhuizen Bijlage 3 geeft weer hoe het Medisch Centrum Oost aan het FB-budget komt. Dit gebeurt door twee parallelle processen. Het ziekenhuis registreert LAZR- en LMRgegevens. Deze gegevens levert het ziekenhuis aan Prismant. Nadat Prismant de gegevens ontvangen heeft, bepaalt deze aan de hand hiervan de adherentiegetallen en spiegelinformatie. Deze gegevens levert Prismant aan het Ministerie van VWS, waarna deze het FB-budget vaststelt. Bijlage 5 laat een versimpelde weergave van het medische proces van het Medisch Centrum Oost in de huidige situatie zien. Het proces begint zodra een pati¨ent (verzekerd bij Drienerlo Verzekeringen) een afspraak maakt. Dit gebeurt doorgaans na een verwijzing van de eerstelijns gezondheidszorg. Vervolgens wordt de afspraak voorbereid, dit wil zeggen dat alle benodigde gegevens voor de afspraak worden geregistreerd. De specialist vraagt het medisch dossier van de pati¨ent op en de specialist onderzoekt de pati¨ent. Vervolgens stelt de specialist een diagnose. De benodigde capaciteit wordt ingepland en benodigde hulpmiddelen worden besteld. Vervolgens voert de specialist de behandeling uit en schrijft deze eventueel medicatie voor. De specialist registreert de behandeling en medicatie in het medisch dossier van de pati¨ent. De verrichtingen worden geregistreerd en deze worden gecontroleerd. Hierna factureert het ziekenhuis deze verrichtingen aan de verzekeraar Drienerlo Verzekeringen als de pati¨ent een ziekenfondsverzekering heeft en aan de pati¨ent als de pati¨ent een particuliere verzekering heeft. In deze analyse zal alleen gekeken worden naar de facturaties aan de verzekeraar. Verzekeraars Bijlage 9 toont hoe Drienerlo Verzekeringen declaraties in de huidige situatie afhandelt. Declaraties kunnen op papier of elektronisch aangeleverd worden. De papieren declaraties zijn meestal afkomstig van particulier verzekerden en de elektronische declaraties van ziekenhuizen die deze namens ziekenfondsverzekerden leveren. De papieren declaraties 38

worden overgetypt, zodat deze ook in elektronisch formaat beschikbaar zijn. Vervolgens worden de declaraties batchgewijs gecontroleerd aan de hand van CTG-lijsten (sommige kleine verzekeraars controleren overigens alleen steeksproefgewijs). Deze lijsten bevatten onder andere gegevens over instellingen en prijzen van verrichtingen. Wanneer de uitval hoger dan een bepaald percentage is, wordt deze alsnog met de hand gecontroleerd. Vervolgens worden alle goedgekeurde declaraties uitbetaald aan de verzekerde dan wel het ziekenhuis. Zoals gezegd worden betalingen aan de pati¨ent in dit onderzoek verder buiten beschouwing gelaten. Daarnaast wordt er een bericht gestuurd naar de afzenders van de incorrecte declaraties. Het ziekenhuis kan een afwijzing accepteren waarna het proces stopt, de incorrecte declaratie verbeteren of contact opnemen met Drienerlo Verzekeringen. Verbeterde declaraties controleert de verzekeraar opnieuw, waarna weer een goedkeuring of afwijzing volgt. Wanneer het ziekenhuis contact opneemt met de verzekeraar volgt een uitleg over de reden van de afwijzing. Hierna kan het ziekenhuis de afwijzing accepteren of de incorrecte declaraties verbeteren.

6.2.4

Gegevens

Deze paragraaf geeft in DFD’s (Data Flow Diagrams) weer wat de input- en outputinformatie van de verschillende activiteiten van het Medisch Centrum Oost en Drienerlo Verzekeringen is. Ziekenhuizen Bijlage 7 geeft in een DFD weer welke informatiestromen er bij Medisch Centrum Oost lopen bij het uitvoeren van het medisch proces. Bijlage 11 toont een DFD van het declaratieproces gezien vanuit het ziekenhuis. Verzekeraars In bijlage 13 is een DFD van het declaratieproces te zien vanuit de kant van de verzekeraar.

6.2.5

Applicaties

In deze paragraaf wordt in tabelvorm weergegeven welke applicaties gebruikt worden voor de ondersteuning van de verschillende processen. De taken van de applicatie zijn die taken die de applicatie voor de betreffende activiteit uitvoert. Deze taakomschrijvingen zijn opgesteld aan de hand van antwoorden die gegeven zijn in interviews en folders van diverse ZIS-leveranciers. Ziekenhuizen De onderstaande tabel toont de applicaties die het Medisch Centrum Oost gebruikt. Activiteit Maken afspraak

Applicatie Afsprakenregistratie-applicatie

Pati¨entenregistratie-applicatie Voorbereiden afspraak

Afsprakenregistratie-applicatie

39

Taken applicatie Het geven van een overzicht van beschikbare data Het vastleggen van de afspraak Het opvragen van de pati¨entgegevens Het geven van een overzicht van beschikbare data Het vastleggen van de afspraak

Pati¨entenregistratie-applicatie

Opvragen medisch dossier

Archiveringsapplicatie (bij gebruik fysieke dossiers)

EPD1 (bij gebruik elektronische dossiers) Documentatie-applicatie

Het opvragen van de pati¨entgegevens en verzekeringsgegevens Het lokaliseren van fysieke medische dossiers Het registreren van uitleeninformatie van fysieke dossiers Het opvragen van medische gegevens Het opvragen van brieven, faxen, notities e.d. die betrekking hebben op de pati¨ent

Onderzoeken pati¨ent Stellen diagnose Registreren diagnose in medisch dossier Inplannen capaciteit

EPD (bij gebruik elektronische dossiers)

Het opslaan gegevens

Capaciteitsplanningapplicatie

Plaatsen orders

Logistieke applicaties

Uitvoeren behandeling

EPD

Het opvragen en reserveren van beschikbare capaciteit van OK’s, bedden etc. Het aanvragen van (middelen benodigd voor) de behandeling, labonderzoeken etc. Het opvragen van r¨ ontgenfoto’s

Voorschrijven medicatie Registreren behandeling/medicatie in medisch dossier Vastleggen verrichtingen Uitvoeren controle

Medicatie-applicatie EPD (bij gebruik elektronische dossiers)

van

medische

Het opvragen van labuitslagen etc. Het registreren van voorgeschreven medicatie Het opslaan van medische gegevens

Verrichtingenregistratieapplicatie Verrichtingenregistratieapplicatie Factureringsapplicatie

Het vastleggen van verrichtingen Het controleren van verrichtingen Factureren Het opstellen van facturen aan verrichtingen pati¨enten en zorgverzekeraars Tabel 6.1: Applicaties Medisch Centrum Oost in de huidige situatie 1

Een EPD (Elektronische Pati¨enten Dossier) wordt hierbij gezien als een samenstel van applicaties

40

Verzekeraars De onderstaande tabel laat de applicaties zien die Drienerlo Verzekeringen gebruikt. Activiteit Ontvangen papieren declaraties Overtypen declaraties Ontvangen elektronische declaraties Uitvoeren batchgewijze controle m.b.v. CTG-lijsten

Applicatie

Taken applicatie

Declaratie-applicatie

Het invoeren van declaraties

Declaratie-applicatie

Het invoeren van declaraties

Declaratie-applicatie

Het controleren van declaraties

Polisregistratie-applicatie

Het opvragen van de polissen van verzekerden Het controleren van declaraties Het opvragen van de polissen van verzekerden Het uitbetalen van correcte declaraties

Controleren uitval

Declaratie-applicatie Polisregistratie-applicatie

Uitbetalen goedgekeurde declaraties

Financi¨ele applicatie

Klantenregistratie-applicatie

Het opvragen van klantgegevens Afwijzen incor- Financi¨ele applicatie Het opstellen en/of versturen recte declaraties van afwijzingen Klantenregistratie-applicatie Het opvragen van klantgegevens Tabel 6.2: Applicaties Drienerlo Verzekeringen in de huidige situatie

41

6.3

Analyse gewenste situatie

In deze paragraaf zal de gewenste situatie beschreven worden. Met de gewenste situatie wordt de situatie bedoeld waarin financiering op basis van onderhandelbare DBC’s plaatsvindt, zoals gespecificeerd door de projectgroep DBC2003. Hiervoor wordt dezelfde opbouw gebruikt als in de analyse van de huidige situatie.

6.3.1

Bedrijfsnetwerk

Hoewel de doelen van de gezondheidszorg hetzelfde blijven, verandert de strategie van het bedrijfsnetwerk sterk. De zorgsector zal decentraal en vraaggericht te werk gaan. De overheid zal een stuk minder sturen en sturing zal plaatsvinden op zorgaanbieders-, zorgverzekerings- en pati¨entniveau. De hoeveelheid zorg en het beschikbare budget zal dus afhankelijk worden van de vraag van pati¨enten.

6.3.2

Bedrijven

In deze paragraaf worden de doelstellingen en strategie¨en van ziekenhuizen en verzekeraars in de gewenste situatie uiteengezet. Ziekenhuizen Ziekenhuizen blijven hetzelfde doel nastreven, namelijk het uitvoeren van medische behandelingen. Ziekenhuizen zullen dit doel in de toekomst op een hele andere wijze bereiken dan in de huidige situatie. Ziekenhuizen zullen niet langer op basis van het verkregen budget produceren, maar op basis van de vraag naar zorg. Ziekenhuizen gaan in de toekomst de volgende strategie¨en toepassen: 1. concurrentie en specialisatie. Naast personeel zullen ziekenhuizen ook om klanten (voornamelijk zorgverzekeraars en via de zorgverzekeraars pati¨enten) gaan concurreren. Ziekenhuizen zijn immers voor hun financiering afhankelijk van het aantal behandelde pati¨enten en het soort behandeling dat pati¨enten ontvangen. Ziekenhuizen kunnen zich hierbij specialiseren op wensen die zorgverzekeraars hebben (bijvoorbeeld een lage prijs of een hoge kwaliteit). 2. effici¨entie. Ziekenhuizen hebben nooit een goed inzicht in de kosten van hun producten gehad, omdat de kosten niet direct aan een product gekoppeld waren. Bij financiering op basis van DBC’s zal de kostprijs van een DBC duidelijk moeten worden. Ziekenhuizen krijgen hierbij meer inzicht in hun eigen processen en producten. Op basis van deze gegevens kunnen ziekenhuizen zelf een beleid bepalen en effici¨enter te werk gaan. Verzekeraars Het doel van verzekeraars blijft hetzelfde, namelijk het financieren van medische behandelingen met opbrengsten verkregen uit het dragen van financi¨ele risico’s van een groep mensen. Dit doel zal echter op een andere manier gerealiseerd worden. In het toekomstige stelsel bestaat er ´e´en verplichte basisverzekering voor alle Nederlanders. Verzekeraars zijn dan verplicht iedereen die zich aanmeldt te verzekeren. De financiering zal zo ingericht worden dat zij zich vooral op zorgregie gaan richten en niet op het selecteren van verzekerden op basis van gezondheidsvooruitzichten (Ministerie 42

van VWS, 2001b). Verzekeraars gaan in de toekomst de volgende strategie¨en toepassen (Deloitte & Touche, z.j.): 1. regie. Verzekeraars zullen een regierol krijgen. Zij moeten voor de verzekerden zorg inkopen en dus als vertegenwoordiger van de verzekerden optreden. De zorgverzekeraars zijn klanten van de zorgaanbieders. De zorgaanbieders zullen zoveel mogelijk ingaan op de wensen van deze klanten en de zorgverzekeraars krijgen dus een sturende rol. De financiering van zorgverzekeraars wordt zo ingericht dat zij zich vooral op de zorgregie gaan richten en niet op het selecteren van verzekerden op basis van hun gezondheidsvooruitzichten. 2. concurrentie en specialisatie. Verzekeraars zullen moeten concurreren om hun klanten. Voor het verkrijgen en behouden van klanten kunnen verzekeraars zich richten op een bepaald soort productaanbod. Verzekeraars kunnen hierbij gaan concurreren op kwaliteit/service, pakketsamenstelling/assortiment, marktsegmentatie of prijs/premie. 3. (inter)nationalisering. Verzekeraars zullen zich door specialisatie meer op de (inter)nationale markt gaan richten dan op de regionale markt.

6.3.3

Bedrijfsprocessen

Deze paragraaf laat zien hoe de bedrijfsprocessen van het Medisch Centrum Oost en Drienerlo Verzekeringen in de gewenste situatie verlopen. De processen zijn opgesteld aan de hand van informatie die in interviews is verkregen en uit documenten en media. De donker gekleurde activiteiten zijn hierbij veranderd. Ziekenhuizen Bijlage 4 geeft het gewenste financieringsproces weer. Het Medisch Centrum selecteert een aantal representatieve DBC’s. Deze verzendt het ziekenhuis naar Drienerlo Verzekeringen. Vervolgens onderhandelen het ziekenhuis en de verzekeraar over het volume, de inhoud en prijs van de DBC’s. De uitkomsten van deze onderhandelingen worden vastgelegd in een contract. Op basis van dit contract ontvangt het ziekenhuis financiering van de verzekeraar. Of de betaling van de zorg voor of na de levering van de zorg plaatsvindt dient ook in het contract vastgelegd te worden. In bijlage 6 staat het gewenste medische proces weergegeven. Hierin zijn alleen de administratieve activiteiten veranderd. Zoals te zien is lopen de medische activiteiten heel erg parallel aan het administratieve activiteiten. Deze activiteiten komen dus dichter bij elkaar te staan. Net als in de huidige situatie maakt de pati¨ent (verzekerd bij Drienerlo Verzekeringen) een afspraak en wordt deze afspraak voorbereid. Tijdens het spreekuur opent de specialist een DBC. Tijdens het zorgtraject wordt de DBC getypeerd. Hierbij worden tevens verrichtingen vastgelegd. Wanneer de specialist het zorgtraject afsluit, wordt de definitieve DBC geregistreerd en wordt deze gesloten. Met deze sluiting geeft de specialist toestemming voor verdere verwerking van de DBC. De DBC wordt, indien deze correct is, omgezet in een productgroep en deze wordt gefactureerd aan de verzekeraar. De DBC en productgroep worden tevens (batchgewijs) verzonden naar het datawarehouse. 43

Verzekeraars Bijlage 10 toont het declaratieproces in de gewenste situatie. Drienerlo Verzekeringen ontvangt dan alleen nog elektronische declaraties. Deze declaraties hebben een ander formaat dan de declaraties in de huidige situatie. De declaraties worden gecontroleerd aan de hand van DBC-contracten. Deze contracten geven de tariefafspraken per instelling aan. Indien er geen prijsafspraken met de betreffende instelling gemaakt zijn, geldt het standaardtarief van de instelling. De uitval wordt, boven een bepaald uitvalspercentage, handmatig gecontroleerd. Vervolgens betaalt de verzekeraar de goedgekeurde declaraties uit en stuurt de afzenders van afgekeurde declaraties afwijzingen. Het enige wat hier wezenlijk in verandert is de controle van de declaratie. De declaratie wordt namelijk niet langer aan de hand van CTG-tarieven gecontroleerd, maar aan de hand van contracten. Daarnaast verandert natuurlijk het formaat van de declaratie.

6.3.4

Gegevens

Deze paragraaf geeft in DFD’s (Data Flow Diagrams) weer wat de input- en outputinformatie van de verschillende activiteiten van het Medisch Centrum Oost en Drienerlo Verzekeringen is. De donker gekleurde activiteiten zijn hierbij veranderd. Ziekenhuizen Bijlage 8 geeft in een DFD weer welke informatiestromen er bij Medisch Centrum Oost lopen bij het uitvoeren van het medisch proces. Bijlage 12 toont een DFD van het declaratieproces gezien vanuit het ziekenhuis. Verzekeraars In bijlage 14 is een DFD van het declaratieproces te zien vanuit de kant van de verzekeraar.

6.3.5

Applicaties

Welke applicaties nodig zijn in de gewenste situatie zal besproken worden in de hoofdstukken 9 en 10.

44

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

7. Requirements-analyse In dit hoofdstuk zullen de eisen waaraan de architectuur moet voldoen uitgewerkt worden. Deze eisen zijn opgesteld met behulp van informatie die in interviews is verkregen.

7.1

Probleem

Het samenstel van applicaties dat verzekeraars en ziekenhuizen in de FB-situatie gebruikten is niet geschikt voor de DBC-situatie.

7.2

Doel product

Het administratief afhandelen van DBC’s voor zowel ziekenhuis als verzekeraars.

7.3

Stakeholders

7.3.1

Ziekenhuizen

De belangrijkste eis van het ziekenhuis is een eis van de specialisten, namelijk het altijd kunnen inzien van pati¨entgegevens. Het onbeschikbaar zijn van deze gegevens kan fatale gevolgen hebben. Specialisten willen zich doorgaans zoveel mogelijk op hun vakinhoudelijke taken richten en zo weinig mogelijk op de administratie daaromheen. Voor hen is het dus van belang dat de applicaties zo snel en gemakkelijk mogelijk te bedienen zijn. Een andere belangrijke eis van de specialisten is de bescherming van de privacy van de pati¨ent, de specialist zich immers houden aan de WGBO. De directie/het management hecht ook grote waarde aan de bescherming van de privacy van de pati¨ent. Het onzorgvuldig omgaan met pati¨entgegevens is een strafbaar feit en kan hoge boetes als gevolg hebben. Een goede beveiliging is daarom van groot belang. Deze beveiliging kan gerealiseerd worden door implementatie van de norm NEN-7510. De directie/het management wil in de toekomst gebruik maken van de DBC-gegevens om inzicht te krijgen in de kosten, de doorlooptijden van processen te bepalen en de verkoopprijs te bepalen. De IT-afdeling van ziekenhuizen willen systemen die gemakkelijk te onderhouden en uit te breiden zijn. Daarnaast moeten ze zo gemakkelijk mogelijk in gebruik zijn, zodat de IT-afdeling niet continu wordt belast met vragen.

7.3.2

Verzekeraars

Verzekeraars willen zoveel mogelijk informatie ontvangen van ziekenhuizen om enerzijds de polissen aan te kunnen passen aan de wensen van verzekerden en anderzijds de prijs en inhoud van DBC’s van verschillende ziekenhuizen te vergelijken. Verzekeraars zouden het liefst zowel de productgroepen, de DBC’s als de verrichtingen van ziekenhuizen ontvangen. Het is echter niet de bedoeling van het DBC-project dat verzekeraars ook de verrichtingen bij de declaraties krijgen. Verrichtingen kunnen wel gebruikt worden voor de onderhandelingen over DBC’s. Verzekeraars willen managementinformatie gebruiken om zichzelf te kunnen vergelijken met concurrenten, de producten en kwaliteit hiervan van verschillende ziekenhuizen en specialisten te kunnen vergelijken en risicoprofielen op te stellen. Het opstellen van risicoprofielen kan in sommige gevallen conflicteren met de bescherming van de privacy 45

van de verzekerde. Verzekeraars willen declaraties zoveel mogelijk geautomatiseerd afhandelen en willen zo min mogelijk ingrijpende veranderingen in hun informatiesystemen. Door de onzekerheid over de te ontvangen declaratiegegevens moeten de systemen namelijk in korte tijd aangepast worden.

7.3.3

Pati¨ enten/verzekerden

Pati¨enten/verzekerden willen zo snel mogelijk behandeld worden in de zorginstelling naar hun keuze. Zij willen dus zien of hun verzekeraar een behandeling daar ook vergoedt. Ook willen pati¨enten zien hoe lang de wachtlijsten van instellingen zijn, wat de poliskosten van verzekeraars zijn en wat er binnen deze polissen vergoed wordt. Kortom pati¨enten/verzekerden willen inzicht in wat de verschillende zorginstellingen en verzekeraars aan producten bieden. De pati¨enten/verzekerden willen daarnaast dat er zeer zorgvuldig met hun medische gegevens wordt omgegaan.

7.3.4

Overheid

De overheid probeert momenteel de wachtlijsten terug te dringen en de kosten van de gezondheidszorg zo laag mogelijk te maken. Om de wachtlijsten terug te dringen is het van belang dat ziekenhuizen inzicht krijgen in de duur van hun behandeling met behulp van een datawarehouse. Om de kosten zo laag mogelijk te houden is het van belang dat er een marktwerking ontstaat. Hiervoor is het noodzakelijk dat zorgverzekeraars inzicht hebben in de prijzen van alle Nederlandse zorginstellingen.

7.4

Randvoorwaarden

Verrichtingen kunnen nog niet direct in een zorgtraject of DBC-traject worden geregistreerd. Daarom is het noodzakelijk dat verrichtingen achteraf aan een DBC gekoppeld worden. Hierdoor kan de specialist DBC’s niet direct na afsluiting valideren. Hij zal de DBC’s op een later tijdstip batchgewijs moeten valideren.

7.5

Aannames

Aanname 1 Het DBC-registratie- en declaratiemodel 2004 (versie 1.0, juli 2003) wordt in gebruik genomen. Consequentie 1 van aanname 1 In het DBC-systeem, dat versie 1.0 van het DBCregistratie- en declaratiemodel 2004 introduceert, is er sprake van de drie functionele niveaus: 1. de uitgebreide registratie. Deze bevat ten minste de minimale dataset gespecificeerd in het DBC-registratieen declaratiemodel. Daarnaast kan het ziekenhuis deze uitbreiden met verwijsgegevens, gerelateerde zorgactiviteiten, relaties met andere zorg, complicaties etc. 2. de DBC-declaratieset. Dit is een samenvatting van het DBC-traject, die gemaakt wordt bij het afsluiten van de DBC bij het einde van de behandeling, bij wijziging van het zorgtype of aan het einde van de maximale duur van de DBC. Deze samenvatting bevat daarnaast nog informatie die is vastgelegd in andere basisregistraties die over dezelfde periode 46

een typering geen van de diagnose en de uitgevoerde controle. Deze declaratieset dient de specialist te autoriseren. 3. de DBC-productgroep (de DB¿) Op basis van de DBC declaratie dataset wordt een productgroep, de DB¿, vastgesteld. Hoe de afleiding plaats zal vinden wordt bepaald aan de hand van de CGAO-analyses. Deze productgroep zal het ziekenhuis declareren bij de verzekeraar. Consequentie 2 van aanname 1 Ziekenhuizen en verzekeraars hoeven alleen prijsafspraken te maken over productgroepen en niet over DBC’s. Dit verkleint het aantal prijsafspraken. Aanname 2 Er worden sluitende controlemechanismen opgezet waardoor gegarandeerd kan worden dat uitsluitend rechtmatige declaraties kunnen worden ingediend. Dit gebeurt in de vorm van een validatiemodule die door een bevoegde instantie wordt uitgegeven (bijvoorbeeld NICTIZ). Deze instantie garandeert dat de functionaliteit volledig is en de werking correct. De specialist kan dus met hulp van een dergelijke module de uitgebreide DBC omzetten in een DBC-declaratieset, die vervolgens weer omgezet wordt in een DB¿. Consequentie 1 van aanname 2 De zorgverzekeraar kan de correctheid van DBC’s bepalen en heeft voldoende gegevens voor het voeren van onderhandelingen als hij beschikt over de volgende gegevens: ˆ de DBC-productgroepcode op pati¨ent- en specialismeniveau ˆ de casemix van de DBC-productgroep per specialist/me ˆ gemiddelde zorgprofielen per DBC-code per specialisme en per ziekenhuis

Consequentie 2 van aanname 2 De zorgverzekeraar kan DBC’s niet direct aan pati¨enten koppelen, aangezien de verzekeraar slechts productgroepen met pati¨entgegevens binnenkrijgt. De anonieme DBC-gegevens kunnen daarom slechts gebruikt worden voor het verkrijgen van managementinformatie en niet voor het controleren van declaraties. Aanname 3 De HL7-standaard wordt aangepast aan het DBC registratie-en declaratiemodel 2004. Consequentie 1 van aanname 3 Applicaties kunnen DBC-informatie uitwisselen door middel van de HL7-standaard. Aanname 4 Medische pati¨entgegevens staan in het EPD. Consequentie 1 van aanname 4 Er is geen archiveringsapplicatie nodig. Aanname 5 Het EPD is een samenstel van applicaties. Consequentie 1 van aanname 5 Voor het opvragen van medische pati¨entinformatie zijn meerdere applicaties nodig. 47

Aanname 6 VEKTIS ontwikkelt een nieuwe EI-standaard, die het mogelijk maakt declaratieberichten op te stellen die voldoen aan de voorwaarden gesteld in het DBC registratie- en declaratiemodel 2004. Consequentie 1 van aanname 6 DB¿’s (productgroepen) kunnen gedeclareerd worden met behulp van de VEKTIS EI-standaard.

7.6

Scope van het product

De te ontwerpen architectuur zal zich beperken tot die applicaties die gaan veranderen door de invoering van DBC’s.

7.7

Programma van eisen

In deze paragraaf worden de belangrijkste eisen van de verschillende stakeholders besproken. De functionele eisen zijn afgeleid van de stakeholderanalyse en de bedrijfsprocessen, die opgesteld zijn aan de hand van informatie verkregen uit interviews, media en documenten. Voor de indeling van de niet-functionele eisen is gebruik gemaakt van een framework van ISO/IEC (1991). De eisen komen hierbij uit de interviews. De applicatieafhankelijke en infrastructuurafhankelijke eisen zullen in het ontwerp niet meegenomen worden. Dit gaat namelijk te diep voor dit onderzoek.

48

7.7.1

Functionele eisen

Stakeholder Specialisten

Afdeling Medische Administratie Management

Afdeling IT

Stakeholder Afdeling Zorginkoop

Afdeling Polisverkoop Management

Afdeling IT

Eis F1: Een specialist kan een DBC van zijn pati¨ent openen. F2: Een specialist kan een DBC-gegevens van zijn pati¨ent invoeren. F3: Een specialist kan een DBC van zijn pati¨ent wijzigen. F4: Een specialist kan een DBC van zijn pati¨ent sluiten. F5: Een specialist kan een DBC van zijn pati¨ent autoriseren voor facturatie. F6: Een specialist kan medische managementinformatie uit het datawarehouse opvragen. F7: Een specialist kan medische gegevens van alle pati¨enten in noodgevallen opvragen. F8: Een medewerker van de afdeling Medische Administratie kan productgroepen facturen. F9: Een manager kan kostprijzen bepalen. F10: Een manager kan respresentatieve DBC’s selecteren voor contractonderhandeling. F11: Een manager kan DBC-contracten opslaan. F12: Een manager kan managementinformatie uit het datawarehouse opvragen. F13: Een medewerker van de afdeling IT kan gebruikers aanmaken. F14: Een medewerker van de afdeling IT kan gebruikersrechten veranderen. Tabel 7.1: Eisen ziekenhuis

Eis F15: Een medewerker van de Afdeling Zorginkoop kan de prijzen en inhoud van de DBC’s van verschillende ziekenhuizen met elkaar vergelijken F16: Een medewerker van de Afdeling Zorginkoop kan de prestaties van verschillende ziekenhuizen en specialisten met elkaar vergelijken F17: Een medewerker van de Afdeling Polisverkoop kan per pati¨ent zorgprofielen opstellen F18: Een manager kan DBC-contracten opslaan. F19: Een manager kan managementinformatie uit het managementinformatiesysteem opvragen. F20: Een medewerker van de afdeling IT kan gebruikers aanmaken. F21: Een medewerker van de afdeling IT kan gebruikersrechten veranderen. Tabel 7.2: Eisen verzekeraar

49

Stakeholder Pati¨ent

Eis F22: Een pati¨ent wil zien welke DBC’s verzekeraars bij een bepaald ziekenhuis vergoeden. Tabel 7.3: Eisen pati¨ent

Stakeholder Overheid

Eis F23: De overheid wil dat ziekenhuis inzicht krijgen in de duur en kosten van hun processen. F24: De overheid wil dat verzekeraars inzicht krijgen in de verkoopprijzen van de zorginstellingen. Tabel 7.4: Eisen overheid

7.7.2

Niet-functionele eisen

Categorie Functionality

Subcategorie Accuracy

Compliance Interopability Security

Reliability

Suitability Fault tolerance Maturity Recoverability

Usability

Learnability Operability

Eis NF1: In het datawarehouse van het ziekenhuis staan correcte gegevens. NF2: In het managementinformatiesysteem van de verzekeraar staan correcte gegevens. NF3: De declaratiegegevens die het ziekenhuis aan de verzekeraar zendt zijn correct. NF4: De declaratieberichten voldoen aan de EIstandaard van VEKTIS NF5: Alle applicaties die gebruik maken van DBC’s kunnen indien nodig DBC-informatie met elkaar uitwisselen. NF6: De privacy van de pati¨ent wordt beschermd. NF7: Fraude met DBC’s wordt zoveel mogelijk tegengegaan. NF8: Ongeautoriseerde gebruikers kunnen het systeem niet gebruiken. NF9: Geautoriseerde gebruikers kunnen alleen gebruik maken van de functionaliteiten en gegevens waarvoor zij geautoriseerd zijn. NF10: Het systeem voldoet aan de functionele eisen. NF11: Medische pati¨entgegevens zijn altijd beschikbaar. [Infrastructuur-afhankelijk] [Applicatie-afhankelijk] NF12: Bij uitval van een component (zowel hardware als software), kan het systeem snel herstellen. [Infrastructuur-afhankelijk] [Applicatie-afhankelijk] NF13: De applicaties van het ziekenhuis zijn met zo min mogelijk handelingen te bedienen. 50

Efficiency

Maintainability

Portability

7.7.3

NF14: De applicaties van de verzekeraar zijn met zo min mogelijk handelingen te bedienen. Understandability [Applicatie-afhankelijk] Resource be- NF15: Applicaties maken zo min mogelijk gebruik van haviour centrale resources. [Infrastructuur-afhankelijk] Time behaviour [Applicatie-afhankelijk] Analysability NF16: De bron van een softwarefout kan achterhaald worden. [Infrastructuur-afhankelijk] Changability NF17: Defecte componenten (zowel hardware als software) kunnen gemakkelijk vervangen worden. [Infrastructuur-afhankelijk] Stability [Applicatie-afhankelijk] Testability [Applicatie-afhankelijk] Adaptability [Niet van belang] Conformance [Niet van belang] Installability [Applicatie-afhankelijk] Replaceability NF18: De applicaties van ziekenhuizen zijn gemakkelijk te vervangen. [Infrastructuur-afhankelijk] Tabel 7.5: Niet-functionele eisen

Tegenstrijdige eisen Niet-functionele eis Functionele eis NF7 F1 t/m F5 NF6 F6, F7, F12, F17, F19 NF9 F7 NF13 F6, F12 NF14 F19 Tabel 7.6: Tegenstrijdige eisen

In tabel 7.6 is te zien welke eisen tegenstrijdig met elkaar zijn. NF7 stelt dat fraude met DBC’s zoveel mogelijk tegengegaan moet worden. Dit is tegenstrijdig met F1 t/m F5, aangezien daarin gesteld wordt dat een specialist het gehele DBC-traject zelf verwerkt. De fraude kan voor een deel voorkomen worden door de administrateur de mogelijkheid te geven de DBC’s te controleren. Verder kan het systeem controleren of de verrichtingen overeenkomen met de DBC’s. Deze fraude is lastig te voorkomen in het systeem zelf. Oplossing hiervoor zullen vooral in de procedurele richting gezocht moeten worden. NF6 stelt dat de privacy van de pati¨ent beschermd moet worden. Deze eis kan tegenstrijdig zijn met F6. F6 stelt dat de specialist medische managementinformatie uit het systeem moet kunnen halen. Deze tegenstrijdigheid kan voorkomen worden door alleen anonieme gegevens in het datawarehouse te zetten. Hetzelfde geldt voor F19, die stelt dat een manager van een verzekeraar managementinformatie uit het managementinformatiesysteem moet kunnen halen. F7 stelt dat een 51

specialist in noodgevallen medische gegevens van alle pati¨enten kan opvragen. Dit schendt natuurlijk de privacy van de pati¨ent. In dat geval weegt het belang van de gezondheid van de pati¨ent zwaarder dan de privacy van de pati¨ent. F7 dient dus ingebouwd te worden, ondanks de tegenstrijdigheid met NF6. F12 stelt dat een ziekenhuismanager managementinformatie uit het datawarehouse kan opvragen. Net als met de medische managementinformatie hoeft dit geen problemen op te leveren met de privacy van pati¨enten, wanneer het datawarehouse anonieme gegevens bevat. F17 stelt dat een medewerker van de Afdeling Polisverkoop van een verzekeraar per pati¨ent zorgprofielen op kan stellen. Aan de hand hiervan zouden per pati¨ent risicoprofielen opgesteld kunnen worden en premies vastgesteld kunnen worden. Aangezien verzekeraars in principe niet door het DBC-project meer informatie over de gezondheid van pati¨enten mogen krijgen, zal F17 daarom niet in dit ontwerp meegenomen worden. NF9 stelt dat gebruikers van het systeem alleen gebruik mogen maken van functionaliteiten en gegevens waarvoor zij autorisatie hebben. Dit is in strijd met eis F7 die stelt dat specialisten in noodgevallen de gegevens van elke pati¨ent mogen opvragen. Zoals reeds eerder gezegd weegt in dit geval de gezondheid van de pati¨ent zwaarder dan de privacy van de pati¨ent of de beveiliging van het systeem. NF13 stelt dat het systeem van het ziekenhuis met zo min mogelijk handeling bediend dient te worden. Bij het opvragen van medische managementinformatie (F6) of van algemene managementinformatie (F12), moet daarom goed gelet te worden op welke informatie het datawarehouse dient te leveren. Wanneer dit datawarehouse veel functionaliteit bevat levert het de gebruiker weliswaar veel informatie, maar het systeem wordt al snel onoverzichtelijk en moeilijk in gebruik. Dit zelfde geldt voor de eisen NF14 en F19. NF14 stelt namelijk dat de applicaties van verzekeraars met zo min mogelijk handeling bediend moeten kunnen worden en F19 stelt dat een manager managementinformatie uit het managementinformatiesysteem moet kunnen halen.

7.7.4

Prioriteit eisen Prioriteit Must have

Functionele eis F1, F2, F3, F4, F5, F7, F8, F9, F10, F11, F13, F14, F15, F18, F20, F21, F23, F24 Could have F6, F12, F16, F19, F22 Want to have, but will not have F17 Tabel 7.7: Prioriteit eisen Figuur 7.7 geeft aan welke prioriteiten de verschillende eisen hebben. De ‘must have’ categorie bevat die eisen waaraan het systeem moet voldoen om de operationele afhandeling van DBC’s mogelijk te maken. De specialist moet dus de DBC’s kunnen registreren en ziekenhuizen en verzekeraars moeten de mogelijkheid hebben prijsafspraken te maken en te registreren. Daarnaast moeten de kostprijzen bepaald kunnen worden en moeten de van de DBC’s afgeleide productgroepen gefactureerd kunnen worden. Verder zitten in deze categorie een aantal beveiligingseisen. Deze zijn per se nodig om enerzijds de privacy van de pati¨ent te beschermen en anderzijds zijn gezondheid. 52

De ‘could have’ eisen zijn die eisen die niet per se noodzakelijk zijn voor de operationele afhandeling van DBC’s, maar die wel een belangrijke bijdrage kunnen leveren aan het werken met DBC’s. Hieronder valt het opvragen van managementinformatie (zowel voor het ziekenhuis als voor de verzekeraar). Deze informatie is met name interessant op tactisch niveau. Zoals reeds bij de tegenstrijdigheden vermeld is, zal F17 niet in het ontwerp meegenomen worden, omdat het niet de intentie van het DBC-project is de verzekeraar meer mogelijkheden te geven gezondheidsinformatie van pati¨enten te verkrijgen.

53

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

8. Alternatieven Dit hoofdstuk zal enkele verschillende manieren behandelen waarop de benodigde applicaties samen kunnen werken. De communicatie tussen ziekenhuizen en verzekeraars zal verlopen via de EI-standaard van VEKTIS, aangezien dit in Nederland verreweg de meest gebruikte standaard hiervoor is. De technologiekeuze voor interne communicatie van ziekenhuizen en verzekeraars is onafhankelijk van elkaar, zoals in figuur 8.1 te zien is. Ziekenhuizen kunnen kiezen tussen een monolithisch systeem (een systeem dat uit ´e´en geheel bestaat), communicatie door directe berichtuitwisseling of communicatie m.b.v. middleware. Ziekenhuizen kunnen hierbij ‘direct’ gebruik maken van de middleware of via het HL7 (Health Level 7) formaat. HL7 is een syntaxtische en sematische standaard die gebruik kan maken van verschillende onderliggende technologie¨en, zoals XML MOM, CORBA en COM1 . Verzekeraars hebben net als ziekenhuizen de keuze tussen een monolithisch systeem, directe berichtuitwisseling en communicatie via middleware. In de volgende paragrafen zullen de voor- en nadelen van de verschillende communicatiemogelijkheden uitgelegd worden.

Ziekenhuis

Verzekeraar

Monolithisch

Monolithisch

Directe berichtuitwisseling

Directe berichtuitwisseling Communicatie via middleware

Communicatie via middleware XML MOM

XML MOM

Corba

Corba

COM

COM

DHE

….

HL7 XML MOM Corba COM

Figuur 8.1: Alternatieven

1

Het gebruik maken van DHE als onderliggende technologie zou weinig nut hebben, aangezien DHE zelf al een hoog-niveau gezondheidszorgspecifieke API bevat. Dit zou dus dubbelop zijn.

54

8.1

Applicaties ziekenhuizen

Deze paragraaf zal vier verschillende communicatiemogelijkheden behandelen voor ziekenhuisapplicaties. De systemen van ziekenhuizen kunnen ofwel monolithisch ofwel componentgebaseerd zijn. Monolithisch wil zeggen dat het systeem bestaat uit ´e´en geheel; er is dus in wezen geen sprake van communicatie tussen verschillende applicaties. Componentgebaseerd wil zeggen dat het systeem bestaat uit verschillende deelsystemen (vaak geleverd door verschillende fabrikanten). Deelsystemen van componentgebaseerde systemen kunnen direct met elkaar communiceren, via middleware zonder HL7 en via middleware met HL7.

8.1.1

Monolithisch

Een monolithisch systeem wordt geleverd door ´e´en fabrikant en bestaat (vrijwel) uit ´e´en geheel. Het voordeel van een dergelijk systeem is de hoge mate van uniformiteit van het systeem: alle userinterfaces hebben dezelfde stijl en alle data hebben hetzelfde formaat. Een nadeel van een monolithisch systeem is het ontbreken van een keuze van de deelsystemen. Daarnaast ontstaat er een sterke afhankelijkheid van de leverancier.

8.1.2

Directe berichtuitwisseling

De op het eerste gezicht eenvoudigste methode om applicaties met elkaar te verbinden is de het tot stand brengen van directe verbindingen. Wanneer veel applicaties via deze methode aan elkaar gekoppeld worden ontstaat er een wirwar aan verbindingen, waardoor onderhoud en uitbreiding lastig wordt. Wanneer er 4 applicaties zijn moeten er namelijk 6 verbindingen2 gemaakt worden om alle applicaties te verbinden. Zijn er 15 applicaties dan zijn er 105 verbindingen nodig om alle applicaties te verbinden. Kortom deze manier van communiceren is alleen aan te raden wanneer er slechts weinig applicaties met elkaar hoeven te communiceren.

8.1.3

Communicatie via middleware zonder HL7

Communicatie via middleware heeft als voordeel dat het systeem gemakkelijker uit te breiden en te onderhouden is dan bij directe berichtuitwisseling. Daarnaast wordt het systeem als geheel een stuk overzichtelijker. Een nadeel is dat de implementatie ervan lastig kan zijn. Daarom is dit vooral aan te raden als er veel verschillende applicaties met elkaar moeten communiceren. In deze paragraaf worden drie soorten middleware besproken: XML Message-Oriented Middleware, CORBA en DHE. XML Message-Oriented Middleware XML Message-Oriented Middleware (XML MOM) zorgt ervoor dat de XML-berichten van verschillende applicaties via een centraal punt worden verstuurd. Een belangrijk voordeel van deze methode is dat berichten die niet direct afgeleverd kunnen worden, opgeslagen kunnen worden totdat de ontvanger weer beschikbaar is. XML specificeert echter alleen de vorm van het bericht en niet de inhoud. De inhoud van de berichten moet dus nog door het ziekenhuis worden gedefinieerd. Een voordeel van dergelijke middleware is de mogelijkheid om medische applicaties met allerlei niet-medische applicaties te laten communiceren, aangezien XML een algemene standaard is in plaats van een gezondheidsspecifieke standaard. 2

Dit is uit te rekenen met de formule (n*(n-1))/2.

55

CORBA CORBA is een object-georienteerde middleware die veelvuldig in het bedrijfsleven gebruikt wordt. CORBA biedt naast algemene middleware-diensten ook domeinspecifieke diensten voor de gezondheidszorg. Een groot nadeel van de CORBA-technologie is het gebrek aan ervaring hiermee in de Nederlandse gezondheidszorg. Daarnaast is de CORBA redelijk complex en zal de IT-afdeling van het ziekenhuis dus de nodige tijd moeten besteden aan het inwerken van personeel en het implementeren van de technologie (Linden, Boers & Tange). DHE DHE (Distributed Health Environment) is gezondheidsspecifieke middleware. Deze is ontwikkeld in de Europese projecten RICHE en EDITH (Hansa, z.j.). DHE is procesgebaseerde middelware en bevat onder andere de volgende gezondheidszorgspecifieke componenten (Blobel & Holena, 1997): ˆ patient manager Deze zorgt voor de identificatie van de pati¨ent en voor beheer van persoonlijke, klinische en epidemiologische informatie over pati¨enten benodigd voor onder andere administratieve en statische informatie. ˆ act manager Deze zorgt voor de ondersteuning van de interacties tussen afdelingen en individueel personeel en voor de co¨ ordinatie van activiteiten. ˆ health data manager De verantwoordelijkheid van deze manager is het beheren gedetailleerde pati¨entinformatie en de uitwisseling hiervan met andere systemen. ˆ users and authorisation manager Deze manager zorgt voor de autorisatie van de verschillende gebruikers voor de verschillende functionaliteiten en data. ˆ resource manager Deze is verantwoordelijk voor de registratie van de beschikbaarheid, eigenschappen en statussen van resources, zoals instrumenten, bedden en personeel. ˆ costs and performance manager Deze manager beheert informatie over de ontwikkeling van de organisatie, wat betreft de hoeveelheid en kosten van de gebruikte resources en de hoeveelheid en kosten van de uitgevoerde activiteiten.

Net als met CORBA hebben Nederlandse ziekenhuizen geen ervaring met DHE.

8.1.4

Communicatie via middleware zonder HL7

Zoals reeds gezegd kan het ziekenhuis gebruik maken van een laag bovenop de middleware: HL7 (Health Level 7). HL7 is een internationale gezondheidsspecifieke standaard. Deze standaard beschrijft, in tegenstelling tot XML, zowel de inhoud als de opmaak van het bericht. In Nederland is reeds veel ervaring opgedaan met de Nederlandse variant van deze standaard (Stichting HL7, z.j.). Als onderliggende middlewaretechnologie kan bijvoorbeeld XML MOM, CORBA of COM gebruikt worden.

56

8.1.5

Keuze

Aangezien een afhankelijkheid van ´e´en leverancier niet gewenst is (dit blijkt uit de interviews), wordt de architectuur componentgebaseerd. In deze architectuur zal gebruik gemaakt worden van HL7 in combinatie met MessageOriented Middleware. Hiervoor is XML Message-Oriented Middleware aan te raden, aangezien er een complete mapping bestaat voor HL7 versie 3 naar XML. In ziekenhuizen worden relatief veel verschillende applicaties gebruikt die veel informatie met elkaar uitwisselen. Het onderhouden van vele directe verbindingen zou veel tijd kosten. Daarrom is het gebruik van middleware aan te raden. CORBA en DHE worden in de Nederlandse gezondheidszorg niet of nauwelijks gebruikt. XML zonder HL7 heeft als nadeel dat de opbouw van de berichten nog helemaal gespecificeerd zou moeten worden. Vooral omdat de projectgroep DBC2003 in samenwerking met de Stichting HL7 Nederland bezig is met een voor DBC’s geschikte nieuwe specificatie van HL7 (DBC2003, 2003e) is het gebruik HL7 een logische keuze.

8.2

Verbinding tussen ziekenhuizen en verzekeraars

Ziekenhuizen en verzekeraars gebruiken al enige tijd de VEKTIS EI-standaard voor het uitwisselen van berichten. Deze standaard zal aangepast worden aan de nieuwe eisen die DBC’s met zich meebrengen (DBC2003, 2003a).

8.3

Applicaties verzekeraars

Verzekeraars kunnen hun systemen ook verbinden via een monolithisch systeem, een directe verbinding of middleware. Qua middleware kunnen zij hierbij onder andere kiezen uit Message-Oriented Middleware, RPC’s of ORB’s (zoals CORBA en COM).

8.3.1

Keuze

In deze architectuur zullen de applicaties direct verbonden worden. Uit de interviews is gebleken dat verzekeraars relatief weinig, maar wel vrij omvangrijke applicaties hebben (vrijwel nooit monolithische systemen). Het zou veel tijd kosten deze systemen geschikt te maken voor het gebruik van middleware. De systemen hebben doorgaans namelijk standaard geen middleware-interface. Vanwege de relatief kleine hoeveelheid verbindingen, kunnen deze verbindingen nog vrij gemakkelijk onderhouden worden.

57

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

9. Conceptueel model Z IEKENHUIS

V ERZEKERAAR Logistieke applicatie (s)

Contractmanagementapplicatie

Logistieke informatie

DBC-afspraakinformatie

Contracten MIS DBC-registratieapplicatie Identity protector Authenticatieapplicatie

Autorisatieapplicatie

Verrichtingenregistratieapplicatie

Datawarehouse Logmodule

Verrichtingen

HL7 Message Broker

Contracten Contractmanagementapplicatie

Managementinformatie Financiële applicatie

Afsprakenregistratieapplicatie

Afspraken

Autorisatiegegevens Documentatieapplicatie

Medicatie-applicatie

Patiëntenregistratieapplicatie

Medische applicaties (EPD)

Facturatie-applicatie

Managementinformatie

DBC's/ Zorgtrajecten

DBC-afspraakinformatie

Financiële gegevens

Klantenregistratieapplicatie

Klanten

Polisregistratieapplicatie

Polissen

Declaratieapplicatie

Declaraties

Documenten

Medicatiegegevens

NAW-gegevens patiënt

Medische patiëntgegevens

Facturen

Figuur 9.1: Conceptuele architectuur Figuur 9.1 toont het conceptuele model. Een DBC begint zijn leven in de DBCregistratie-applicatie. Aan de DBC kunnen in principe afspraken, documenten en medische gegevens (zoals r¨ontgenfoto’s) gekoppeld worden door in deze applicaties een referentie van een DBC’s mee te geven. Het zal niet mogelijk zijn deze applicaties in ´e´en keer aan te passen. Dit zal moeten gebeuren in de periode van nu tot 2006. In dit model wordt ervanuit gegaan dat DBC’s en verrichtingen nog niet bij het aanmaken van een DBC aan elkaar gekoppeld worden (zoals in het registratie- en declaratiemodel 2004). De volgende ziekenhuisapplicaties zijn het belangrijkst voor de verwerking van DBC’s: de DBC-registratie-applicatie, de contractmanagementapplicatie, de facturatieapplicatie en het datawarehouse. De facturatie-applicatie levert de declaraties aan de declaraties van de verzekeraar. Dit kan gaan via een internetverbinding of directe lijnverbinding, maar ook via een cd-rom of een tape. De applicaties van de verzekeraar zijn direct met elkaar verbonden. De facturen van het

58

ziekenhuis komen binnen bij de declaratie-applicatie. Deze controleert de declaratie met behulp van gegevens uit de klantenregistratie-applicatie, polisregistratie-applicatie en de contractmanagementapplicatie. De betalingsgegevens stuurt de declaratie-applicatie vervolgens door naar de financi¨ele applicatie, die zorgt voor uitbetaling. Het managementinformatiesysteem haalt gegevens uit alle applicaties. Het zorgt ervoor dat het management voldoende informatie krijgt om tactische beslissingen te nemen.

9.1

Applicaties ziekenhuizen

Figuur 9.2 laat zien welke stappen de applicaties uit moeten voeren om van registratie tot facturatie te komen. Allereerst registreert het ziekenhuis zowel verrichtingen als DBC’s. Deze verrichtingen en DBC’s worden volgens een algoritme aan elkaar gekoppeld. In ongeveer 2006 zullen verrichtingen al bij registratie aan een bepaalde DBC gekoppeld worden, maar deze verandering is nog te ingrijpend om voor 1 juli 2004 door te voeren. Na de koppeling vindt een validatieslag plaats. Dit wil zeggen dat de DBC-registratieapplicatie controleert of de DBC consistent is met de uitgevoerde verrichtingen. Vervolgens zet de DBC-registratie-applicatie de DBC om in een productgroep en geeft de DBC en de productgroep door aan de facturatie-applicatie.

9.1.1

Verrichtingenregistratie-applicatie

Hoewel het ziekenhuis verrichtingen niet meer factureert aan de verzekeraar, blijft het noodzakelijk verrichtingen te registreren. Aan de hand van deze verrichtingen kan het ziekenhuis namelijk de inhoud van een DBC specificeren en de DBC’s controleren. Daarnaast is de specificatie van DBC’s met behulp van verrichtingen nodig voor de onderhandelingen met verzekeraars. Het ene ziekenhuis kan namelijk een hele ‘kale’ DBC aanbieden voor een hele lage prijs, terwijl het andere ziekenhuis een hele ‘volledige’ DBC biedt tegen een hogere prijs. Zonder te laten zien welke verrichtingen een bepaalde DBC gemiddeld bevat, zou het voor de verzekeraars appels met peren vergelijken zijn.

9.1.2

DBC-registratie-applicatie

De DBC-registratie-applicatie speelt een centrale rol in de nieuwe applicatie-architectuur. Deze applicatie registreert namelijk de DBC’s, koppelt verrichtingen aan DBC’s en valideert de DBC’s.

Registratie DBC

Verrichtingen

Koppelen DBC + Verrichtingen

Validatie

Facturatie

Figuur 9.2: DBC-verwerkingsstappen (DBC2003, 2003f) 59

De specialist is verantwoordelijk voor de registratie van DBC’s in de DBC-registratieapplicatie. Wanneer de specialist een DBC sluit, autoriseert hij deze DBC. Vervolgens koppelt de DBC-registratie-applicatie de DBC’s en de verrichtingen batchgewijs aan elkaar. In de validatieslag kijkt de applicatie of de verrichtingen overeenstemmen met de geregistreerde DBC’s. Wanneer dit niet het geval is worden de betreffende DBC’s en/of verrichtingen teruggestuurd naar de verantwoordelijke specialist. De registratieapplicatie deelt vervolgens de DBC’s in in productgroepen. Deze productgroepen stuurt de registratie-applicatie door aan de facturatie-applicatie. De DBC-registratie-applicatie zorgt er dus voor dat aan de eisen F1 tot en met F5 voldaan is (eisen die betrekking hebben op de registratie van DBC’s). De DBC-registratie-applicatie kan zo gebruiksvriendelijk mogelijk gemaakt worden door gebruik te maken van de tabel ‘DBC-componenten frequentie’ en de tabel ‘DBC-componenten afhankelijkheid’. De eerstgenoemde tabel geeft de meest gekozen zorgvraag van een bepaald zorgtype weer, vervolgens de meest gekozen diagnose en de meest gekozen behandeling. De tabel ‘DBC-componenten afhankelijkheid’ bevat zogenaamde onmogelijke DBC-combinaties. Dit zijn combinaties van zorgtype, zorgvraag, diagnose en behandeling die volgens de Wetenschappelijke Verenigingen in theorie niet voor kunnen komen. Indien deze tabellen in de registratie-applicatie verwerkt zijn, daalt de registratielast van de specialist aanzienlijk.

9.1.3

Facturatie-applicatie

De facturatie-applicatie zorgt, zoals de naam al suggereert, voor de facturatie. Deze zorgt dus voor een invulling van eis F8. In plaats van verrichtingen, die het ziekenhuis in de FB-situatie factureerde, krijgt de facturatie-applicatie te maken met productgroepen. Deze productgroepen hebben echter geen vaste prijs zoals verrichtingen. Het ziekenhuis heeft namelijk enerzijds vaste standaardtarieven voor deze productgroepen en anderzijds met verzekeraars onderhandelde tarieven. De facturatie-applicatie moet dus kunnen achterhalen of het ziekenhuis productgroepen aan een bepaalde verzekeraar nog mag declareren voor het onderhandelde tarief of dat het standaardtarief gerekend moet worden (ervanuitgaande dat wanneer het aantal onderhandelde productgroepen van een bepaalde soort gedeclareerd is, het standaardtarief gerekend wordt). Hiervoor moet de facturatieapplicatie dus beschikken over de statussen van de verschillende DBC-afspraken van verzekeraars.

9.1.4

Datawarehouse

Het datawarehouse heeft als belangrijkste taak het bepalen van de kostprijs van DBC’s/ productgroepen (F9). Het datawarehouse heeft hiervoor meer informatie nodig dan alleen de DBC’s en de verrichtingen. Hierbij moet gedacht worden aan de tijdsbesteding van medisch personeel, de gebruikte faciliteiten, alle gebruikte medicatie etc. Het datawarehouse extraheert dus gegevens uit (de databases van) de afsprakenapplicatie, de documentatie-applicatie, de logistieke applicaties etc. In de toekomst is het handig deze applicaties meteen een DBC-referentienummer mee te geven, in plaats van de activiteiten en materialen achteraf via het datawarehouse aan DBC’s te koppelen. Zoals reeds eerder gezegd zijn dergelijke veranderingen op dit moment nog te ingrijpend. Daarnaast heeft het datawarehouse als functie het ontdekken van trends in de afname van bepaalde DBC’s. Op deze manier kan het ziekenhuis de toekomstige vraag voor60

spellen en de benodigde capaciteit inplannen (F12, F23). Eventueel kunnen medisch specialisten het datawarehouse gebruiken om medische informatie te krijgen. Hierbij kan gedacht worden aan het percentage pati¨enten jonger dan 40 met een bepaalde aandoening, het aantal pati¨enten uit een bepaalde regio met een bepaalde aandoening etc (F6). Een andere belangrijke taak van het datawarehouse is het selecteren van representatieve DBC’s voor de onderhandelingen met verzekeraars.

9.1.5

Contractmanagementapplicatie

De overgang van vaste CTG-tarieven naar variabele, onderhandelbare tarieven heeft, zoals gezegd, een grote invloed op de facturatie. Om de actuele tarieven bij te houden is het aan te raden een contractmanagementapplicatie te gebruiken. Deze applicatie slaat de opgestelde contracten digitaal op (F11), zodat deze altijd gemakkelijk op te vragen zijn. Daarnaast houdt deze applicatie de actuele status van de DBC-afnames bij. Deze applicatie dient verbonden te zijn met de DBC-registratie-applicatie en de facturatie-applicatie. Zodra de DBC-registratie-applicatie een DBC opent, moet deze bij de contractmanagementapplicatie controleren of dit nog binnen de hoeveelheid afgesproken productgroepen valt. Is dit niet het geval dan moet de gebruiker een signaal krijgen, zodat het ziekenhuis de verzekeraar eventueel kan benaderen om nieuwe afspraken te maken. Overigens kan de verzekeraar ook zeggen dat hij voor de teveel uitgevoerde productgroepen het standaardtarief van het ziekenhuis wil betalen. De verbinding met de facturatie-applicatie zorgt ervoor dat altijd duidelijk is of een bepaalde productgroep voor de onderhandelde prijs gedeclareerd mag worden of voor het standaardtarief.

9.1.6

Autorisatie-applicatie

De autorisatie-applicatie heeft niet direct met de invoering met DBC’s te maken. Deze applicatie kan er wel voor zorgen dat de administratieve last beperkt wordt. Ziekenhuizen gebruiken namelijk veel verschillende applicaties. Wanneer deze applicaties door verschillende leveranciers zijn ontwikkeld, moeten gebruikers relatief vaak inloggen soms zelfs met verschillende inloggegevens. De autorisatie-applicatie zorgt ervoor dat alle benodigde inloggegevens van alle gebruikers voor alle applicaties in een centrale (goed beveiligde) database staan. De applicatie heeft verbindingen met alle andere applicaties en kan zorgen voor een automatische login, zodra de gebruiker eenmaal ingelogd heeft in de autorisatie-applicatie. De autorisatie-applicatie zorgt er ook voor dat specialisten in noodtoestanden altijd met een wachtwoord in kunnen loggen in plaats van met een chipcard (F7). Daarnaast biedt het medewerkers van de IT-afdeling de mogelijkheid gebruikers aan te maken en gebruikersrechten te veranderen (F13 en F14).

9.2

Applicaties verzekeraars

Zoals gezegd krijgt de verzekeraar van het ziekenhuis productgroepen op pati¨entniveau binnen en anonieme DBC’s.

9.2.1

Declaratie-applicatie

Het controleren van declaraties wordt in de DBC-situatie lastiger dan dit in de FBsituatie was. In de FB-situatie diende alleen gecontroleerd te worden of een zorginstelling

61

bepaalde verrichtingen mocht declareren, of de polis van de pati¨ent dit dekte en of het tarief overeenkwam met het CTG-tarief. In de DBC-situatie wordt er geen gebruik meer gemaakt van CTG-tarieven, wat ervoor zorgt dat de controle lastiger wordt. Er moet namelijk uitgezocht worden of er een contract is met de betreffende zorginstelling, hoeveel productgroepen van een bepaalde soort nog gedeclareerd mogen worden, wat de onderhandelde prijs is en wat het standaardtarief is.

9.2.2

Contractmanagementapplicatie

Net als het ziekenhuis wil de verzekeraar natuurlijk op de hoogte zijn van de status van de prijsafspraken. De verzekeraar kan hiervoor een soortgelijke applicatie gebruiken als het ziekenhuis (hiermee wordt dus aan F18 voldaan). Deze applicatie dient verbonden te zijn met de declaratie-applicatie en het managementinformatiesysteem.

9.2.3

Managementinformatiesysteem

Het managementinformatiesysteem levert diverse managementinformatie, zoals welke instellingen de meeste productgroepen van een bepaalde soort leveren, van welke instellingen veel DBC’s tegen standaardtarief worden afgenomen, wat de prijs van een bepaalde productgroep gemiddeld is etc (F15, F16, F19, F24). Een andere belangrijke taak van deze applicatie is om periodiek te controleren of de anonieme DBC’s consistent zijn met de op pati¨entniveau geleverde productgroepen.

9.3 9.3.1

Beveiligingsmaatregelen Rollen

Het gebruik van functionaliteiten en de inzage en wijziging van gegevens wordt gekoppeld aan rollen. Veel gebruikers hebben namelijk dezelfde soorten toegangsrechten. Het gebruik van rollen voorkomt dus onnodig ingewikkelde autorisatieregels. De rol van een gebruiker is enerzijds afhankelijk van zijn beroep en anderzijds van zijn relatie met de pati¨ent. Er is bijvoorbeeld ook een verschil in de rol van een behandelend specialist van een bepaalde pati¨ent en een willekeurige andere specialist.

9.3.2

Smart card

Gebruikers maken gebruik van een smart card om toegang tot de applicaties te krijgen. Indien gewenst kan op deze smart card ook nog een pincode gezet worden. Op deze smart card dient een certificaat van de gebruikers te staan. Wellicht zouden hiervoor in de toekomst UZI (Unieke Zorgverleners Identificatie) certificaten gebruikt kunnen worden.

9.3.3

Noodtoegang

Hoewel de authenticatie van personeel in het ziekenhuis officieel via de chipkaart verloopt, blijft de mogelijkheid bestaan om via een wachtwoord in te loggen. In noodgevallen moeten de pati¨entgegevens immers altijd beschikbaar zijn. Toegang die op deze manier verkregen wordt, wordt door de log-applicatie altijd gemeld aan de verantwoordelijke(n) voor het beveiligingsbeleid. Het gebruik van deze manier van toegang dient achteraf altijd verantwoord te worden.

62

9.3.4

Beperkt functionaliteitenoverzicht

Applicaties kunnen op basis van de rol van de gebruiker een aantal functionaliteiten bieden. Een specialist zal bijvoorbeeld in een medische applicatie meer gegevens kunnen zien en veranderen dan een verpleegkundige.

9.4 9.4.1

Privacy-beschermende maatregelen Gecodeerd pati¨ entnummer

De pati¨entgegevens worden gesplitst in twee groepen: het identiteitsdomein en het pseudo-identiteitsdomein. Het identiteitsdomein bevat direct tot de pati¨ent herleidbare gegevens, zoals NAW- en verzekeringsgegevens. Het pseudodomein bevat alle medische gegevens van de pati¨ent. De identity protector codeert het pati¨entnummer van het identiteitsdomein tot het pati¨entnummer van het pseudo-identiteitsdomein. Alleen via deze identity protector kunnen de pati¨entgegevens dus aan elkaar gekoppeld worden. Op database-niveau kunnen de identiteitsgegevens dus niet aan de pseudo-identiteitsgegevens gekoppeld worden (Hooghiemstra, 2002).

9.4.2

Informeren pati¨ ent bij inzage

In noodgevallen kunnen artsen via een noodoptie bij gegevens komen waar zij eigenlijk geen toegang toe hebben. Dit noodgebruik wordt geregistreerd in de log-applicatie. Van een dergelijk noodgebruik wordt de pati¨ent na afloop op de hoogte gesteld.

9.4.3

Datawarehouse anoniem

Gegevens die in het datawarehouse opgeslagen worden, krijgen niet het pati¨entnummer van de identiteit of pseudo-identiteit mee, maar een geheel nieuw nummer. Voor het genereren van managementinformatie hoeft de informatie immers niet op pati¨entniveau herleidbaar te zijn en de WBP verbiedt de verwerking van persoonsgegevens voor doelen die vallen buiten de uitdrukkelijk door het ziekenhuis omschreven en gerechtvaardigde doelen.

9.4.4

Wissen oude gegevens

In de applicaties kunnen gegevens het verstrijken van de bewaartermijn gewist worden. Hoewel deze maatregel de privacy van de pati¨ent vergroot, is hier onder de specialisten behoorlijk wat discussie over. Voor het vaststellen van erfelijke ziekten, kunnen bijvoorbeeld medische gegevens van reeds overleden familieleden nodig zijn. Hierbij komt dus het grote dilemma van de gezondheidszorg terug: is de privacy van de pati¨ent of de gezondheid van de pati¨ent het belangrijkst?

63

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

10. Gedetailleerd model Dit hoofdstuk zal de veranderingen in een aantal geselecteerde applicaties verder uitwerken. De geselecteerde applicaties zijn: de DBC-registratie-applicatie, de facturatie-applicatie, de contractmanagementapplicatie (zowel van de ziekenhuizen als van de verzekeraars), het datawarehouse, de declaratie-applicatie en het managementinformatiesysteem. Van deze applicaties wordt een Function Refinement Tree (FRT) gegeven. Dit is een hi¨erarchische opsplitsing van de functies die de applicatie dient te vervullen. Vanuit deze FRT wordt een hoog-niveau Data Flow Diagram (DFD) opgesteld. Deze DFD laat zien welke informatie de verschillende functies als in- en output hebben. Ook wordt aangegeven welke informatie de verschillende applicaties minimaal met elkaar uit moeten wisselen.

10.1

Applicaties ziekenhuizen

De volgende paragrafen zullen de bovengenoemde door ziekenhuizen gebruikte applicaties beschrijven.

10.1.1

DBC-registratie-applicatie

Figuur 10.1 toont de FRT van de DBC-registratie-applicatie. De hoofdfuncties zijn het registreren van DBC’s, het koppelen van DBC’s aan verrichtingen, het valideren van DBC’s en het gereedmaken van DBC’s voor de facturering. Onder het registreren van DBC’s vallen alle registratiefuncties die vermeld worden in het DBC-registratiemodel van de projectgroep DBC2003 (2003c). Het koppelen van DBC’s aan verrichtingen gebeurt niet direct bij de registraties van DBC’s, maar achteraf. Dit gebeurt, zoals reeds in het vorige hoofdstuk vermeld, omdat het direct koppelen van verrichtingen aan DBC’s te ingrijpende veranderingen in de informatiesystemen zou vergen. De verrichtingen worden dus aan een DBC gekoppeld, zodra de betreffende DBC afgesloten is. Het valideren van DBC’s houdt in dat de DBC-registratie-applicatie controleert of de DBC’s overeenkomen met de daaraan gekoppelde verrichtingen. Na de validatie dienen de DBC’s gereed gemaakt te worden voor facturatie. De DBCregistratie-applicatie moet hiervoor de DBC’s omzetten in productgroepen. Figuur 10.2 toont een DFD van de DBC-registratie-applicatie. De figuren 10.3 tot en met 10.6 geven aan welke informatie de DBC-registratie-applicatie met de andere applicaties uit moet wisselen. Registreren DBC’s Voor het openen van zorgtrajecten en DBC’s maakt de DCB-registratie-applicatie gebruik van typeringslijsten. Dit zijn lijsten die codes bevatten van zorgvragen, diagnoses, behandelingen etc. Deze lijsten zijn opgesteld door de wetenschappelijke verenigingen van specialisten. Eventueel kan er voor het vastleggen van de diagnose ook gebruik gemaakt worden van de ICD-9 codering. Er bestaat namelijk een omzettingstabel van de ICD-9 code naar de DBC-diagnosetyperingscode (DBC2003, 2002). Voor het openen van zorgtrajecten en DBC’s wordt daarnaast gebruik gemaakt van de tabel DBC-componenten frequentie en de tabel DBC-componenten afhankelijkheid. 64

Afhandelen DBC's

A: Registreren DBC's

B: Koppelen DBC's aan verrichtingen

C: Valideren DBC's

D: Gereedmaken DBC's voor facturering

A1: Openen zorgtrajecten

B1: Opvragen verrichtingen

C1: Omzetten verrichtingencode in CTG-code

D1: Indelen DBC's in productgroepen

A2: Wijzigen/aanvullen zorgtrajecten

B2: Uitvoeren koppelingsalgoritme

C2: Bepalen zorgprofielklasse

D2: Verzenden DBC's en productgroepen naar facturatie-applicatie

A3: Sluiten zorgtrajecten

B3: Genereren uitvallijst

C3: Bepalen uitgevoerde behandeling

A4: Corrigeren zorgtrajecten

C4: Autoriseren uitgevoerde behandeling C5: Notificeren specialist bij incorrecte zorgtrajecten/DBC's

A5: Openen DBC's A6: Wijzigen/ aanvullen DBC's A7: Sluiten DBC's

A8: Corrigeren DBC's A9: Doorgeven status DBC aan contractmanagentapplicatie

Figuur 10.1: FRT DBC-registratie-applicatie Deze tabellen maken de applicatie gemakkelijker in gebruik, omdat vaak voorkomende combinaties sneller te registreren zijn en onmogelijk voorkomende combinaties niet te registreren zijn (DBC2003, 2003f). Gedurende het zorgtraject zal de specialist de zorgtrajecten en DBC’s verder invullen met behulp van de typeringslijsten. Bij sluiting van de zorgtrajecten en DBC’s geeft de specialist impliciet toestemming voor de verdere verwerking. Wanneer bij de koppeling van de verrichtingen aan DBC’s of de validatie van de DBC’s blijkt dat er fouten zijn gemaakt, dan krijgt de specialist de uitval terug. Vervolgens moet de specialist deze DBC’s corrigeren. Het kan ook zijn dat hij verrichtingen moet corrigeren. Dit moet gebeuren in de verrichtingenregistratie-applicatie. De DBC-registratie-applicatie moet de status van de DBC doorgeven aan de contractmanagementapplicatie, zodat het ziekenhuis weet hoeveel onderhanden werk er is. Koppelen DBC’s aan verrichtingen Allereerst importeert de DBC-registratie-applicatie de verrichtingen uit de verrichtingenregistratie-applicatie. De DBC-registratie-applicatie koppelt de DBC’s en verrichtingen aan elkaar volgens het algoritme gespecificeerd door de projectgroep DBC2003. Dit koppelingsalgoritme heeft de volgende uitval (DBC2003, 2003f): ˆ parallelle DBC’s. Parallelle DBC’s zijn DBC’s die tegelijkertijd in ´e´en zorgtraject open staan. Aan de datum van de verrichting is dus niet te zien bij welke DBC de verrichting hoort. In plaats van deze DBC’s als uitval terug te sturen naar de specialist, kunnen de verrichtingen ook aan de eerst geopende (of laatst geopende) DBC gekoppeld

65

Patiëntenregistratieapplicatie

Tabel DBC-componenten afhankelijkheid

Verrichtingenregistratieapplicatie

Open DBC's

Tabel DBC-componenten frequentie

Open zorgtrajecten

Gesloten zorgtrajecten Typeringslijsten Gesloten DBC's B: Koppelen DBC's aan verrichtingen

A: Registreren DBC's

Verrichtingen

Uitgevallen DBC's Tabel voor indeling DBC's in productgroepen Uitgevallen verrichtingen

Gevalideerde DBC's Zorgprofielklassen

D: Gereedmaken DBC's voor facturatie

C: Valideren DBC's

Productgroepen Tabel voor indeling verrichtingen in zorgprofielklassen

Tabel voor omzetting zorgprofielklassen in behandeling

Tabel voor omzetting verrichtingencodes in CTG-codes

Facturatie-applicatie

Figuur 10.2: DFD DBC-registratie-applicatie worden. Dit zorgt voor minder correcte DBC’s, maar ook voor minder handmatig werk. ˆ verrichtingen zonder DBC’s. In principe hoeven deze verrichtingen niet verkeerd te zijn. Het kan immers zijn dat de betreffende DBC nog niet afgesloten is. Daarom worden deze DBC’s voorlopig gebufferd. Wanneer verrichtingen lang in de buffer zitten is dit een indicatie dat de verrichting niet overeenkomt met een DBC. ˆ DBC’s zonder verrichtingen Er bestaan enkele DBC’s die ‘leeg’ mogen zijn. De meeste DBC’s moeten echter wel verrichtingen bevatten. De specialist moet bij deze uitval nagaan of er werkelijk

66

Verrichtingenapplicatie (Ziekenhuis)

DBC-registratie-applicatie (Ziekenhuis)

patiëntcode verrichtingencode verrichtingenomschrijving datum verrichting

Figuur 10.3: Informatie-uitwisseling tussen verrichtingenregistratie-applicatie en DBC-registratie-applicatie Patiëntenregistratieapplicatie (Ziekenhuis)

DBC-registratie-applicatie (Ziekenhuis)

patiëntcode naw-gegevens verzekeraargegevens

Figuur 10.4: Informatie-uitwisseling tussen pati¨entenregistratie-applicatie en DBCregistratie-applicatie DBC-registratie-applicatie (Ziekenhuis)

Facturatie-applicatie (Ziekenhuis)

patiëntcode DBC-code DBC-omschrijving productgroepcode productgroepomschrijving specialisme specialist begindatum DBC/productgroep einddatum DBC/productgroep

Figuur 10.5: Informatie-uitwisseling tussen DBC-registratie-applicatie en facturatieapplicatie geen verrichtingen bij de DBC horen. Wanneer het een werkelijk lege DBC betreft, moet deze verwijderd worden. Valideren DBC’s Voor de validatie van de DBC’s zet de DBC-registratie-applicatie verrichtingencodes van de verrichtingen om in CTG-codes. De verrichtingen moeten aan de hand hiervan ingedeeld worden in zorgprofielklassen. De tabel die deze indeling mogelijk maakt gaat namelijk uit van CTG-codes en niet van verrichtingencodes. De zorgprofielklassen geven 67

DBC-code status Contractmanagementapplicatie (Ziekenhuis)

DBC-registratie-applicatie (Ziekenhuis)

productcode status

Figuur 10.6: Informatie-uitwisseling contractmanagement-applicatie

tussen

DBC-registratie-applicatie

en

aan wat de werkelijk uitgevoerde behandeling is. Per specialisme is namelijk een tabel opgesteld die de uitgevoerde behandeling afleidt van de zorgprofielklassen. Indien de werkelijk uitgevoerde behandeling overeenkomt met de voorgenomen behandeling, dan wordt de DBC automatisch geautoriseerd. Wanneer deze twee niet overeenkomen, wordt de DBC teruggestuurd naar de specialist. De specialist moet vervolgens de betreffende DBC of de bijbehorende verrichtingen corrigeren en DBC handmatig autoriseren. Gereedmaken DBC’s voor facturering De gevalideerde DBC’s worden ingedeeld in productgroepen met behulp van een hiervoor opgestelde tabel. Tenslotte zendt de DBC-registratie-applicatie de DBC’s en de productgroepen door naar de facturatie-applicatie.

10.1.2

Facturatie-applicatie

Figuur 10.7 geeft de FRT van de facturatie-applicatie weer. In figuur 10.8 is de bijbehorende DFD te zien. Deze applicatie heeft als taken het opstellen en verzenden van facturen. De figuren 10.10 tot en met 10.11 geven de informatie-uitwisseling met andere applicaties weer. De informatie-uitwisseling met de DBC-registratie-applicatie is reeds in de vorige paragraaf besproken. Factureren productgroepen

B: Verzenden facturen

A: Opstellen facturen

A1: Ontvangen productgroepen en DBC's

B1: Op tape zetten facturen

A2: Koppelen tarieven aan productgroepen

B2: Verzenden facturen via internet

A3: Factuurgegevens conformeren aan VEKTIS EI-standaard

B3: Op tape zetten anonieme DBC's

A4: Corrigeren facturen

B4: Verzenden anonieme DBC's via internet B5: Doorgeven status DBC aan contractmanagementapplicatie

Figuur 10.7: FRT facturatie-applicatie

68

Contractmanagementapplicatie

DBC-registratie-applicatie

Patiëntenregistratieapplicatie

EI-standaard syntax

DBC's

Ongefactureerde productgroepen

A: Opstellen facturen

Gefactureerde productgroepen

B: Verzenden facturen

Facturen

Declaratie-applicate

Figuur 10.8: DFD facturatie-applicatie Contractmanagementapplicatie (Ziekenhuis)

Facturatie-applicatie (Ziekenhuis)

verzekeraargegevens productgroepcode tarief

Figuur 10.9: Informatie-uitwisseling tussen contractmanagementapplicatie en facturatie-applicatie Opstellen facturen Nadat de facturatie-applicatie de DBC’s en productgroepen van de DBC-registratieapplicatie ontvangen heeft, koppelt de facturatie-applicatie de actuele tarieven aan de productgroepen. Deze tarieven worden uit de contractmanagementapplicatie gehaald. De factuur wordt daarna opgesteld het formaat van de VEKTIS EI-standaard. Indien het ziekenhuis bericht krijgt van de verzekeraar over een incorrecte factuur, moet het ziekenhuis controleren of dit inderdaad een incorrecte factuur betreft. Is dit het geval dat moet deze gecorrigeerd worden. Verzenden facturen De facturatie-applicatie zet de facturen vervolgens op tape of verstuurt deze via internet naar de verzekeraars. Ook de DBC’s worden via tape of via internet aan de verzeke69

naw-gegevens patiënt ziekenhuisgegevens productgroepcode productgroepomschrijving tarief specialisme specialist begindatum productgroep einddatum productgroep Facturatie-applicatie (Ziekenhuis)

Declaratie-applicatie (Verzekeraar)

DBC-code DBC-omschrijving specialisme specialist

Figuur 10.10: Informatie-uitwisseling tussen facturatie-applicatie en declaratieapplicatie DBC-code status Contractmanagementapplicatie (Ziekenhuis)

Facturatie-applicatie (Ziekenhuis)

productcode status

Figuur 10.11: Informatie-uitwisseling tussen facturatie-applicatie en contractmanagementapplicatie raars geleverd. Deze DBC’s zijn niet aan pati¨enten gekoppeld. Indien het ziekenhuis slechts weinig declaraties aan een bepaalde verzekeraar stuurt, is het van belang de DBC’s met een lagere frequentie te sturen dan de facturen. Anders zou het voor de verzekeraar alsnog mogelijk zijn de DBC’s via productgroepen aan pati¨enten te koppelen. De facturatie-applicatie dient het ook aan de contractmanagementapplicatie door te geven wanneer een productgroep/DBC gefactureerd wordt. Op deze manier kan de contractmanagementapplicatie de status van de DBC’s bijhouden.

10.1.3

Contractmanagementapplicatie

Figuur 10.12 toont de FRT de contractmanagementapplicatie van het ziekenhuis. Figuur 10.13 geeft de bijbehorende DFD weer. Welke informatie de contractmanagementapplicatie uit moet wisselen met de DBC-registratie-applicatie en de facturatie is in de twee vorige paragrafen behandeld. De contractmanagement houdt kort gezegd de afspraken bij die het ziekenhuis met de 70

Bijhouden DBC-/ productgroepafspraken

B: Registreren afspraken

A: Registreren verzekeraars

C: Bijhouden status afspraken

A1: Opslaan nieuwe verzekeraar

B1: Opslaan contract

C1: Registreren open DBC's

A2: Wijzigen gegevens verzekeraar

B2: Opslaan afspraken

C2: Registreren gesloten DBC's

A3: Verwijderen verzekeraar

B3: Wijzigen afspraken

C3: Registreren gefactureerde productgroepen

Figuur 10.12: FRT contractmanagementapplicatie

DBC-registratie-applicatie

Facturatie-applicatie

Contracten

B: Registreren afspraken

A: Registreren verzekeraars

Actuele afspraken

C: Bijhouden status afspraken Verzekeraars

Figuur 10.13: DFD contractmanagementapplicatie diverse verzekeraars heeft gemaakt. Hiervoor moeten de gegevens van de verzekeraars geregistreerd worden, de gemaakte afspraken en de status van de gemaakte afspraken. Registreren verzekeraars De contractmanagementapplicatie moet actuele gegevens van verzekeraars en hun contactpersonen bevatten. Deze gegevens kunnen in een database van de applicatie zelf opgeslagen of in een met andere applicaties gedeelde database. Het verdient de voorkeur een gedeelde database te gebruiken, zodat de gegevens van de verzekeraars altijd consistent zijn.

71

Registreren afspraken Afgesloten contracten worden elektronisch (ingescand) opgeslagen, zodat deze altijd gemakkelijk bereikbaar zijn. Aangezien de ingescande contracten in een grafisch formaat opgeslagen worden, dat verder voor de applicatie niet te verwerken is, dienen de afspraken ook nog apart in tekstformaat opgeslagen te worden. Bijhouden status afspraken Wanneer de specialist in de DBC-registratie-applicatie een DBC opent of sluit, wordt dit doorgegeven aan de contractmangementapplicatie. Zo ontstaat er een beeld van het onderhanden werk ten opzichte van het aantal te declareren productgroepen. De facturatie-applicatie geeft gedeclareerde productgroepen door, waarna deze afgetrokken worden van het aantal beschikbare productgroepen. Het kan zijn dat een nieuwe DBC van een bepaald type geopend wordt, terwijl er geen afspraak over gemaakt is of het aantal afgesproken bijbehorende productgroepen al gedeclareerd is. In dit geval moeten het ziekenhuis en de verzekeraar nieuwe afspraken maken of het ziekenhuis moet zijn standaardtarief rekenen.

10.1.4

Datawarehouse

Figuur 10.14 toont de FRT van het datawarehouse. Aangezien de inrichting van het datawarehouse heel sterk afhankelijk is van de wensen van een bepaald ziekenhuis, zal hier niet te diep op ingegaan worden. De DFD (figuur 10.15) is daarom maar gedeeltelijk ingevuld. Ook zijn er geen informatie-uitwisselingsdiagrammen weergegeven, omdat deze afhangen van de ziekenhuisspecifieke wensen. Opstellen managementinformatie

A: Berekenen kostprijzen

B: Opstellen medische managementinformatie

C: Opstellen financiële managementinformatie

D: Selecteren representatieve DBC's

Figuur 10.14: FRT datawarehouse Berekenen kostprijzen De kostprijs van DBC’s/productgroepen kan berekend worden met informatie uit diverse bronsystemen. Hierbij kan bijvoorbeeld gedacht worden aan een afsprakenapplicatie, een ordermanagementapplicatie en een personeelsregistratie. Aan de tijd en materiaal die besteed worden, moeten kosten verbonden worden, zodat de kosten van een DBC een som worden van de bestede tijd en materialen. Opstellen financi¨ ele managementinformatie Ziekenhuizen zullen in de toekomst meer behoefte hebben aan financi¨ele managementinformatie. Het is op dit moment moeilijk te zeggen wat voor informatie dit precies moet zijn. Dit komt omdat ziekenhuizen nog geen ervaring hebben met een marktwerking en omdat verschillende ziekenhuizen verschillende wensen zullen hebben. Informatie die bijvoorbeeld interessant kan zijn is de gemiddelde winst van een productgroep, de gemiddelde opbrengst van een bepaald specialisme, de gemiddelde kosten van een DBC etc.

72

DBC-registratie-applicatie

Afsprakenapplicatie

Ordermanagementapplicatie

…...

Medische applicaties

B: Opstellen medische managementinformatie

C: Opstellen financiële managementinformatie

A: Berekenen kostprijzen Medische gegevens

……...

D: Selecteren representatieve DBC's

……...

Figuur 10.15: DFD datawarehouse Opstellen medische managementinformatie Het is voor een ziekenhuis erg interessant te zien wat de leeftijdgroep is van pati¨enten met een bepaalde aandoening, wat hun geografische herkomst is of wat hun geslacht is. Dit alles heeft niet direct met DBC’s te maken, maar wanneer er toch een datawarehouse ge¨ımplementeerd wordt, zijn dit interessante zaken om mee te nemen. Hiervoor moeten de medische applicaties, zoals een r¨ ontgenapplicatie en een laboratoriumapplicatie, aan het datawarehouse gekoppeld worden.

10.1.5

Selecteren representatieve DBC’s

Voor de onderhandelingen met verzekeraars is het van belang dat ziekenhuizen representatieve DBC’s kunnen selecteren. Het ziekenhuis moet dus weten welke verrichtingen een DBC gemiddeld bevat. Deze gegevens kunnen uit het datawarehouse gehaald worden.

10.2

Applicaties verzekeraars

De volgende paragrafen zullen de bovengenoemde door verzekeraars gebruikte applicaties beschrijven.

10.2.1

Declaratie-applicatie

Figuur 10.16 laat een FRT van de declaratie-applicatie zien. In figuur 10.17 is de bijbehorende DFD weergegeven. De figuren 10.18 tot en met 10.22 tonen de informatieuitwisseling. De declaratie-applicatie moet de declaraties controleren en zorgen voor een afhandeling van zowel de goedgekeurde als afgekeurde declaraties.

73

Afhandelen van declaraties

A: Controleren declaraties

B: Afhandelen gecontroleerde declaraties

A1: Controleren syntax declaraties

B1: Registreren gedeclareerde productgroepen in contractmanagementapplicatie

A2: Controleren tarieven productgroepen

B2: Verzenden goedgekeurde declaraties naar financiële applicatie

A3: Controleren polis patiënten

B3: Geven overzicht afgekeurde declaraties

Figuur 10.16: FRT declaratie-applicatie

Facturatie-applicatie

Contractmanagementapplicatie

Polisregistratie-applicatie

Klantenregistratie-applicatie

Onbehandelde productgroepen A: Controleren declaraties EI-standaard syntax

Goedgekeurde productgroepen

B: Afhandelen gecontroleerde declaraties

Afgewezen productgroepen

Contractmanagementapplicatie

Financiële applicatie

Figuur 10.17: DFD declaratie-applicatie

Contractmanagementapplicatie (Verzekeraar)

Declaratie-applicatie (Verzekeraar)

productgroepcode tarief

Figuur 10.18: Informatie-uitwisseling tussen contractmanagementapplicatie en declaratie-applicatie

74

Polisregistratie-applicatie (Verzekeraar)

Declaratie-applicatie (Verzekeraar)

klantcode productgroepcodes gedekte productgroepen

Figuur 10.19: Informatie-uitwisseling tussen polisregistratie-applicatie en declaratieapplicatie

Klantenregistratie-applicatie (Verzekeraar)

Declaratie-applicatie (Verzekeraar)

klantcode naw-gegevens

Figuur 10.20: Informatie-uitwisseling tussen klantenregistratie-applicatie en declaratie-applicatie

Declaratie-applicatie (Verzekeraar)

Financiële applicatie (Verzekeraar)

ziekenhuisgegevens bedrag

Figuur 10.21: Informatie-uitwisseling tussen declaratie-applicatie en financi¨ele applicatie

Contractmanagementapplicatie (Verzekeraar)

Declaratie-applicatie (Verzekeraar)

productgroepcode status

Figuur 10.22: Informatie-uitwisseling tussen declaratie-applicatie en contractmanagementapplicatie

75

Controleren declaraties De declaratie-applicatie controleert de declaraties op de volgende punten: ˆ syntax De declaraties moeten aan de VEKTIS EI-standaard voldoen en compleet zijn. ˆ tarieven De tarieven van de productgroepen moet overeenkomen met de afgesproken tarieven. Deze tarieven kunnen opgevraagd worden uit de contractmanagementapplicatie van de verzekeraar. ˆ polissen De productgroepen van een bepaalde pati¨ent moeten gedekt worden in de polis van die pati¨ent.

Afhandelen gecontroleerde declaraties De declaratie-applicatie registreert de productgroepen in de contractmanagementapplicatie van de verzekeraar, zodat bijgehouden kan worden hoeveel productgroepen van een bepaalde soort nog gedeclareerd kunnen worden. De goedgekeurde declaraties zendt de declaratie-applicatie door aan de financi¨ele applicatie. Deze applicatie betaalt de goedgekeurde declaraties uit. Van de afgekeurde applicaties wordt een overzicht gemaakt. Deze kunnen vervolgens teruggestuurd worden naar de betreffende ziekenhuizen. De declaratie-applicatie geeft het aan de contractmanagementapplicatie door wanneer er een productgroep is goedgekeurd of afgekeurd.

10.2.2

Contractmanagementapplicatie

In figuur 10.23 staat de FRT van de contractmanagementapplicatie van de verzekeraar. In figuur 10.24 staat de DFD van deze applicatie. De informatie-uitwisseling met de declaratie-applicatie is reeds getoond in de vorige paragraaf. De contractmanagementapplicatie heeft min of meer dezelfde taken als de contractmanagementapplicatie van het ziekenhuis. In plaats van gegevens van verzekeraars registreert deze applicatie gegevens van ziekenhuizen en de status van de afspraken wordt op een iets andere manier bijgehouden dan bij een ziekenhuis. Bijhouden DBC-/ productgroepafspraken

A: Registreren ziekenhuizen

B: Registreren afspraken

C: Bijhouden status afspraken

A1: Opslaan nieuwe ziekenhuizen

B1: Opslaan contracten

A2: Wijzigen gegevens ziekenhuizen

B2: Opslaan afspraken

A3: Verwijderen ziekenhuizen

B3: Wijzigen afspraken

C1: Registreren gedeclareerde productgroepen

Figuur 10.23: FRT contractmanagementapplicatie

76

Declaratie-applicatie

Contracten

B: Registreren afspraken

A: Registreren ziekenhuizen

Actuele afspraken

C: Bijhouden status afspraken Ziekenhuizen

Figuur 10.24: DFD contractmanagementapplicatie Registreren ziekenhuizen De ziekenhuisgegevens kunnen in een database behorende bij de contractmanagementapplicatie worden opgeslagen of in een met andere applicaties gedeelde database. Het voordeel van een gedeelde database is dat de gegevens die de verschillende applicaties gebruiken consistent zijn. Registreren afspraken De contractmanagementapplicatie moet de ingescande contracten kunnen bewaren. De contracten worden dus in een grafisch formaat opgeslagen. Daarnaast moeten de afspraken apart in tekstformaat ingevoerd worden, zodat deze verder digitaal verwerkt kunnen worden. Bijhouden status afspraken De declaratie-applicatie geeft de declaraties door aan de contractmanagementapplicatie. Op deze manier kan de verzekeraar bijhouden hoeveel declaraties nog voor het afgesproken tarief gedeclareerd kunnen worden.

10.2.3

Managementinformatiesysteem

De informatie die het managementinformatiesysteem bevat en genereert, verschilt heel erg per verzekeraar. Vandaar is deze applicatie slechts oppervlakkig uitgewerkt. Figuur 10.25 geeft de FRT weer en figuur 10.26 de DFD. Vanwege het verschil in wensen per verzekeraar is de informatie-uitwisseling met andere applicaties ook niet in diagrammen gezet. De belangrijkste taken van het managementinformatiesysteem zijn het vergelijken van prijzen van verschillende ziekenhuizen, het controleren van DBC’s t.o.v. productgroepen 77

Opstellen managementinformatie

A: Vergelijken prijzen ziekenhuizen

B: Controleren DBC's t.o.v. productgroepen

C: Opstellen van financiële managementinformatie

Figuur 10.25: FRT managementinformatiesysteem Contractmanagementapplicatie

Declaratie-applicatie

Polisregistratieapplicatie

…...

B: Controleren DBC's t.o.v. productgroepen

C: Opstellen financiële managementinformatie

A: Vergelijken prijzen ziekenhuizen

……...

……..

……...

Figuur 10.26: DFD managementinformatiesysteem en het opstellen van financi¨ele managementinformatie. Vergelijken prijzen ziekenhuizen Uit de contractmanagementapplicatie kan informatie gehaald worden om de prijzen van verschillende ziekenhuizen met elkaar te vergelijken. Daarnaast dient hierbij de ‘kwaliteit’ verleken te worden. Dit kan bijvoorbeeld aan de hand van de verrichtingen die het ziekenhuis gemiddeld bij een DBC levert (dit is besproken bij de contractonderhandelingen). Hiermee kan de verzekeraar bepalen met welke ziekenhuizen hij komende periode in zee wil gaan. Controleren DBC’s t.o.v. productgroepen In het managementinformatiesysteem kunnen de binnengekomen productgroepen vergeleken worden met de binnengekomen (anonieme) DBC’s. Wanneer deze voor een bepaald ziekenhuis niet met elkaar overeenkomen, dient het ziekenhuis het verschil te verklaren. Opstellen van financi¨ ele managementinformatie Het managementinformatiesysteem kan financi¨ele informatie leveren die gebruikt kan worden om het beleid van de organisatie te bepalen. Hoe deze informatie eruit ziet, verschilt sterk per verzekeraar. Deze informatie wordt uit diverse bronsystemen gehaald, 78

zoals uit de polisregistratie-applicatie en de declaratie-applicatie.

10.3

Migratietraject

Deze paragraaf zal in een stappenplan enkele handvatten geven voor de implementatie van de in dit onderzoek ontworpen architectuur. 1. vaststellen doelen en kritieke succes factoren De doelen van ziekenhuizen en verzekeraars kunnen enigszins verschillen van de doelen die in dit onderzoek genoemd zijn. Daarom dienen deze eerst, met hun kritieke succesfactoren, op een rijtje gezet te worden. 2. ontwikkelen draagvlak Voordat de daadwerkelijke implementatie begint, is het van groot belang dat verschillende partijen achter het project staan. De belangrijkste partijen zijn in dit geval: ˆ het topmanagement Het topmanagement zorgt doorgaans voor het budget voor het IT-project. Het topmanagement van zowel ziekenhuizen en verzekeraars zullen zeer waarschijnlijk het nut van de DBC-registratie inzien, aangezien dit een wettelijke verplichting betreft. ˆ de gebruikers Cooper (1999), ook wel de vader van Visual Basicr (een programmeertaal) genoemd, stelt dat de normale gebruiker een zo simpel mogelijk te bedienen systeem wil. Alleen de echte IT-er (door Cooper ook wel Homo logicus genoemd, in tegenstelling tot de normale gebruiker: de Homo sapiens) wil zoveel mogelijk features en is bereid veel moeite te steken in het door en door leren kennen van nieuwe systemen. Aangezien IT-applicaties staan of vallen met het gebruik ervan is het van belang de applicaties zo eenvoudig mogelijk te maken. Eenvoud is ziekenhuisapplicaties vooral te bereiken door een overkoepelende schil te maken waarvanuit de gebruiker werkt. De gebruiker hoeft hierdoor niet (direct) met verschillende applicaties te werken en hierdoor met verschillende soorten gebruikersinterfaces te werken. Ziekenhuizen kunnen bijvoorbeeld werken met een aantal van deze schillen, die zich op verschillende doelgroepen richten. Deze schillen zouden vanuit de volgende drie visies kunnen werken: spoedeisende hulp (SEH), klinisch en poliklinisch. In figuur 10.27 is hiervan een voorbeeld te zien. De verschillende schillen gebruiken verschillende delen van de applicaties. In figuur 10.27 gebruikt de SEH-schil de afsprakenapplicatie bijvoorbeeld niet, aangezien voor spoedeisende hulp geen afspraak gemaakt wordt. Deze schillen kunnen nog verder op de verschillende gebruikers aangepast worden door te kijken naar de rol die de gebruiker heeft. De verpleegkundige werkt in dit geval bijvoorbeeld in de kliniek en mag daardoor alleen met medische gegevens van klinische pati¨enten werken. Zoals te zien is heeft de verpleegkundige hierbij geen toegang tot alle medische applicaties. De verpleegkundige heeft voor de uitvoering van zijn werk namelijk maar een beperkt deel van de medische gegevens van de pati¨ent

79

nodig. Het toegankelijk maken van meer gegevens zou ten koste gaan van de privacy van de pati¨ent. In dit voorbeeld heeft de specialist toegang tot applicaties van zowel de SEH, klinische zorg en poliklinische zorg, omdat hij op alledrie de afdelingen werk verricht. De specialist heeft geen toegang tot de facturatie-applicatie. In dit geval werkt de specialist namelijk in loondienst en heeft hij niets met de facturatie te maken. De medisch administrateur heeft zowel met SEH, klinisch als poliklinisch te maken, omdat hij voor alledrie de afdelingen controleert en factureert. Hij controleert de DBC’s en verrichtingen en stelt de facturen op. Verzekeraars zouden ook met een dergelijke schil kunnen werken, hoewel het hier minder voordeel oplevert. Gebruikers werken met relatief weinig applicaties en een grootste deel van de afhandeling van DBC’s gebeurt automatisch. ˆ de IT-afdeling De IT-afdeling is verantwoordelijk voor de implementatie van de applicaties, het onderhoud ervan en de ondersteuning van de gebruikers. Vanwege deze grote rol is het van groot belang dat de IT-afdeling snel bij het project betrokken wordt. De invoering van DBC’s betekent een tijdelijke zware belasting van de IT-afdeling. Het zou kunnen zijn dat hiervoor (tijdelijk) nieuw personeel aangetrokken moet worden. DBC-registratieapplicatie

Verrichtingenregistratieapplicatie

Facturatieapplicatie

Afsprakenapplicatie

Logistieke applicatie(s)

Medische applicaties

SEH

Klinische zorg

Poliklinische zorg

Specialist

Verpleegkundige

Medisch administrateur

Figuur 10.27: Mogelijke gebruikersindeling architectuur 3. inventariseren risico’s en maatregelen Door de invoering van IT-applicaties voor de verwerking van DBC’s, ontstaan er nieuwe risico’s in de informatievoorziening van ziekenhuizen en verzekeraars. Ziekenhuizen en verzekeraars dienen voor de implementatie van de nieuwe applicaties deze risico’s te inventariseren en maatregelen te formuleren. Figuur 10.28 laat enkele risico’s voor ziekenhuizen zien. Een maatregel tegen het declareren van productgroepen tegen een verkeerd tarief is bijvoorbeeld een steeksproefsgewijze controle. Figuur 10.29 toont enkele risico’s voor verzekeraars. Een maatregel voor het risico dat de verzekeraar niet op tijd nieuwe prijsafspraken maakt, is bijvoorbeeld het geven van een signaal wanneer de productgroepen voor een bepaald ziekenhuis binnen een maand dreigen ‘op te zijn’. 80

Risico DBC’s worden niet anoniem verstuurd Productgroepen worden niet volgens het afgesproken tarief gedeclareerd Verrichtingen worden niet goed geregistreerd DBC’s worden niet goed geregistreerd Tarieven/aantallen worden niet goed ingevoerd Figuur 10.28: Risico’s ziekenhuizen Risico Productgroepen worden niet volgens het afgesproken tarief gedeclareerd Verzekeraar maakt niet opnieuw prijsafspraken Tarieven/aantallen niet goed ingevoerd De gedeclareerde productgroepen komen niet overeen met de geleverde (anonieme DBC’s) Figuur 10.29: Risico’s verzekeraars 4. analyseren verandering casus en eigen situatie In dit onderzoek zijn de bedrijfsprocessen en applicaties beschreven van het hypothetisch ziekenhuis Medisch Centrum Oost en de hypothetische verzekeraar Drienerlo Verzekeringen. De bedrijfsprocessen en applicaties van ‘echte’ ziekenhuizen en verzekeraars zullen hier globaal mee overeenkomen, maar vanzelfsprekend zullen er ook verschillen bestaan. Het ziekenhuis/de verzekeraar moet daarom deze verschillen inventariseren en nagaan welke consequenties deze verschillen hebben op de nieuwe applicatie-architectuur. 5. bepalen benodigde veranderingen infrastructuur In dit onderzoek is de infrastructuur (type servers, netwerkverbinding, besturingssystemen etc.) buiten beschouwing gelaten, omdat dit te diepgaand zou zijn en omdat dit erg verschilt per ziekenhuis/verzekeraar. Voor de implementatie van de applicaties is een infrastructuuranalyse wel nodig. Er moet namelijk bepaald worden welke snelheid en opslagcapaciteit de servers moeten hebben, welke computers via een netwerk verbonden moeten worden en welke backupmogelijkheden nodig zijn. 6. bepalen prioriteiten Het kan zo zijn dat niet alle applicaties tegelijkertijd ge¨ımplementeerd kunnen worden. In dit geval kunnen ziekenhuizen het best de volgorde aanhouden, zoals aangegeven in figuur 10.30. Als eerste moet de DBC-registratie-applicatie ge¨ımplementeerd worden. Zonder registratie van DBC’s kunnen DBC’s immers niet verder verwerkt worden. Vervolgens kan een contractmanagementapplicatie ge¨ımplementeerd worden, waarin prijsafspraken met verzekeraars gezet worden. Hierna kan de facturatie-applicatie ingevoerd worden. De facturatie-applicatie maakt gebruik 81

van de prijsafspraken in de contractmanagementapplicatie. Tenslotte kan het datawarehouse ingericht worden. Dit zal een iteratief proces zijn, omdat in het begin nog niet helemaal duidelijk zal zijn welke informatie gewenst is. Applicatie DBC-registratie Contractmanagement Facturatie Datawarehouse

Prioriteit 1 2 3 4

Figuur 10.30: Prioriteiten applicaties ziekenhuizen Figuur 10.31 geeft de prioriteitenlijst voor verzekeraars weer. De verzekeraar dient eerst de gemaakte afspraken vast te kunnen leggen in de contractmanagementapplicatie. Vervolgens kan de declaratie-applicatie ge¨ımplementeerd worden. Deze maakt gebruik van de afspraken in de contractmanagementapplicatie. Tenslotte kan de verzekeraar het managementinformatiesysteem inrichten. Net als voor het datawarehouse van ziekenhuizen is dit een iteratief proces. Applicatie Contractmanagement Declaratie-applicatie Managementinformatiesysteem

Prioriteit 1 2 3

Figuur 10.31: Prioriteiten applicaties verzekeraars 7. testen van de applicaties Aangezien fouten in de software kunnen leiden tot levensbedreigende situaties, is het van groot belang dat de applicaties goed getest worden. Hiervoor moeten de applicaties afzonderlijk getest worden en daarnaast de werking als geheel. 8. opleiden gebruikers Het opleiden van gebruikers kan bijvoorbeeld door middel van cursussen. Daarnaast is het van belang dat de gebruikers een goede handleiding hebben, zodat zij zaken nog na kunnen zoeken. 9. proefdraaien In de proefdraaifase worden de nieuwe systemen in gebruik genomen, maar worden de oude systemen nog naast de nieuwe systemen gebruikt. 10. doorvoeren aanpassingen De benodigde verbeteringen die naar boven komen in de proefdraaifase moeten in deze fase verbeterd worden. 11. in gebruik nemen In de laatste fase worden de applicaties in gebruik genomen. Het kan natuurlijk nodig zijn dat na de in gebruik name nog fouten of gewenste aanpassingen naar boven komen.

82

Methodologie Doelstelling, probleemstelling en onderzoeksvragen

Literatuuronderzoek

Probleemanalyse

Requirementsanalyse

Alternatieven

Conceptueel model

Gedetailleerd model

Evaluatie

Ontwerpmethode

11. Evaluatie Dit hoofdstuk geeft een evaluatie van de ontworpen architectuur. Hiervoor wordt allereerst gekeken welke activiteiten door welke top-level-functies van de applicaties worden ondersteund. Daarnaast wordt gekeken met welke eisen uit de requirements-analyse deze functies overeenkomen. Vervolgens worden de eisen behandeld die niet naar voren zijn gekomen bij de bespreking van de activiteiten. Tenslotte wordt een overzicht gegeven van de niet gerealiseerde eisen.

11.1

Koppeling activiteiten aan applicaties

Deze paragraaf laat zien welke activiteiten door welke top-level-functies van de applicaties ondersteund worden. De activiteiten komen daarbij uit de volgende drie processen: het financieringsproces, het medisch proces en het declaratieproces (respectievelijk bijlage 4, 6 en 10). De top-level-functies komen uit de FRT’s uit het gedetailleerd model.

11.1.1

Financieringsproces

Ziekenhuis De activiteiten van het ziekenhuis die ondersteund worden door applicaties staan in tabel 11.1. Activiteit Selecteren representatieve DBC’s Opslaan contract en afspraken

Applicatie Datawarehouse Contractmanagementapplicatie

Functie Selecteren representatieve DBC’s Registreren verzekeraars Registreren afspraken

Figuur 11.1: Door applicaties ondersteunde activiteiten ziekenhuis in financieringsproces Representatieve DBC’s kunnen met behulp van het datawarehouse geselecteerd worden. Het datawarehouse is in dit ontwerp nauwelijks uitgewerkt, omdat deze applicatie nogal verschilt per ziekenhuis. Het is in ieder geval belangrijk dat het datawarehouse kan achterhalen welke verrichtingen gemiddeld bij een bepaalde DBC horen en wat de duur is van die DBC. De contractmanagementapplicatie zorgt dus voor de invulling van F11 (“Een manager (van het ziekenhuis) kan DBC-contracten opslaan”). Het ziekenhuis gebruikt hiervoor de contractmanagementapplicatie enerzijds om verzekeraars te registreren, die nog niet in het systeem staan, en anderzijds om de afspraken te registreren. Verzekeraar De activiteiten van de verzekeraar staan weergegeven in tabel 11.2. F18 (“Een manager (van de verzekeraar) kan DBC-contracten opslaan”) wordt dus mogelijk gemaakt door de contractmanagementapplicatie. De verzekeraar gebruikt de contractmanagementapplicatie hierbij op een vrijwel dezelfde manier als het ziekenhuis. 83

Activiteit Opslaan contract en afspraken

Applicatie Contractmanagementapplicatie

Functie Registreren ziekenhuizen Registreren afspraken

Figuur 11.2: Door applicaties ondersteunde activiteiten verzekeraar in financieringsproces

11.1.2

Medisch proces

Ziekenhuis De activiteiten van het medisch proces van het ziekenhuis, die ondersteund worden door applicaties, staan in tabel 11.3. Activiteit Openen DBC Typeren DBC Registreren definitieve DBC Sluiten DBC Uitvoeren controle

Factureren groep

product-

Applicatie DBC-registratieapplicatie DBC-registratieapplicatie DBC-registratieapplicatie DBC-registratieapplicatie DBC-registratieapplicatie DBC-registratieapplicatie Facturatie-applicatie

Functie Registreren DBC’s Registreren DBC’s Registreren DBC’s Registreren DBC’s Koppelen DBC’s Valideren DBC’s Gereedmaken DBC’s voor facturering Opstellen facturen Verzenden facturen

Figuur 11.3: Door applicaties ondersteunde activiteiten ziekenhuis in medisch proces De eerste vier regels van de bovenstaande tabel komen hierbij overeen met F1 tot en met F5 (de functionele eisen betreffende de registratie van DBC’s). Aan deze eisen is dus voldaan. De autorisatie van de DBC’s gaat hierbij overigens automatisch bij sluiting van de DBC. Met behulp van de facturatie-applicatie kunnen facturen worden opgesteld (F8) en verzonden. Verzekeraar Verzekeraars verzorgen geen activiteiten van dit proces.

84

11.1.3

Declaratieproces

Ziekenhuis Figuur 11.4 laat zien welke activiteiten van ziekenhuizen in het declaratieproces door applicaties worden ondersteund. Activiteit Verbeteren declaraties

incorrecte

Applicatie DBC-registratieapplicatie

Functie Registreren DBC’s

Figuur 11.4: Door applicaties ondersteunde activiteiten ziekenhuis in declaratieproces Verzekeraar Figuur 11.5 laat zien welke activiteiten van verzekeraars in het declaratieproces door applicaties worden ondersteund. Activiteit Uitvoeren batchgewijze controle mbv DBC-contracten en standaardtarieven

Controleren uitval

Controleren verbeterde declaraties

Applicatie Contractmanagementapplicatie

Functie Bijhouden status afspraken

Declaratie-applicatie

Controleren declaraties Afhandelen gecontroleerde declaraties Bijhouden status afspraken

Contractmanagementapplicatie Declaratie-applicatie

Contractmanagementapplicatie Declaratie-applicatie

Controleren declaraties Afhandelen gecontroleerde declaraties Bijhouden status afspraken Controleren declaraties Afhandelen gecontroleerde declaraties

Figuur 11.5: Door applicaties ondersteunde activiteiten verzekeraar in declaratieproces De verzekeraar kan dus met de aangepaste applicaties de declaraties afhandelen.

11.2

Overige eisen

11.2.1

Functionele eisen

De beveiligingseisen (F7, F13, F14) van het ziekenhuis zijn verwerkt in de autorisatieapplicatie. Aangezien deze applicatie niet direct met de invoering van DBC’s te maken heeft, is deze applicatie niet uitgewerkt in het gedetailleerd model. De beschrijving in het conceptueel model geeft echter hoe aan de gestelde eisen voldaan kan worden. 85

De verzekeraar heeft in deze architectuur geen centrale autorisatie-applicatie. De verzekeraar heeft namelijk relatief weinig applicaties waarvoor ingelogd moet worden. De beveiliging hoeft hierdoor alleen in de applicaties zelf geregeld te worden en niet in een centrale autorisatie-applicatie (F20, F21).

11.2.2

Niet-functionele eisen

Een evaluatie van de niet-functionele eisen is een stuk lastiger, aangezien in dit onderzoek een functioneel ontwerp is gemaakt. De verwerking van deze eisen zal dus grotendeels in het verdere ontwerp plaats moeten vinden. NF1 en NF2 stellen dat het datawarehouse en het managementinformatiesysteem correcte gegevens dienen te bevatten. Daarnaast dienen de declaratiegegevens die het ziekenhuis aan de verzekeraar zendt correct te zijn (NF3). Hiervoor geldt het zogenaamde ‘garbage in, garbage out’-principe; wanneer de bronsystemen foutieve gegevens bevatten zullen er nooit correcte gegevens uit het datawarehouse of het managementinformatiesysteem komen. Zorg dus voor correcte gegevens bij de bron. NF4 (“De declaratieberichten voldoen aan de EI-standaard van VEKTIS”) zou geen problemen op mogen leveren, aangezien deze standaard duidelijk gedefinieerd is. Aan NF5 (“Alle applicaties die gebruik maken van DBC’s kunnen indien nodig DBC-informatie met elkaar uitwisselen”) wordt voldaan door gebruik te maken van de HL7 standaard. Voor de beveiligingseisen NF6 tot en met NF9 (bescherming tegen fraude en privacyschending) zijn enkele maatregelen genoemd in het conceptueel model. Hiervoor is nog uitgebreider onderzoek nodig. NF13 en NF14 stellen dat de applicaties van het ziekenhuis en de verzekeraar met zo min mogelijk handelingen te bedienen moeten zijn. In de DBC-registratie-applicatie is dit gerealiseerd door gebruik te maken van diverse tabellen die veel gebruikte combinaties aangeven. Verder kan aan deze eisen voldaan worden door zo weinig mogelijk functionaliteiten in te bouwen. Eis NF10 stelt dat het systeem aan de functionele eisen moet voldoen. In hoeverre dat het geval is, is in dit hoofdstuk besproken. De overige niet-functionele eisen zijn applicatieafhankelijk of infrastructuur-afhankelijk. Deze eisen moeten dus meegenomen worden bij een verder uitwerking van de applicaties en bij het ontwerp van de infrastructuur.

11.3

Toekomstig werk

Wat echt nog mist in deze architectuur is een uitwerking van F22 (“Een pati¨ent wil zien welke DBC’s verzekeraars bij een bepaald ziekenhuis vergoeden.”). Dit zal in verder onderzoek uitgewerkt moeten worden. De verwerking van deze eis in de architectuur is echter niet per se noodzakelijk voor de operationele afhandeling van DBC’s. Deze eis is wel van belang voor de introductie van meer marktwerking in de gezondheidszorg. Dan moet de pati¨ent immers een keuze kunnen maken en daarvoor moet hij goed ge¨ınformeerd worden. Verder zijn er in deze archtitectuur nog geen koppelingen uitgewerkt tussen de DBCregistratie-applicatie en bijvoorbeeld de afsprakenregistratie-applicatie, de medische applicatie en dergelijke. Deze verbindingen zijn nog niet nodig voor de situatie op 1 juli 2004, maar zullen in de loop van de tijd (tot 2006) gemaakt moeten worden. Het zou daarom nuttig zijn ook een architectuur te ontwerpen voor de situatie in januari 2006.

86

12. Conclusies Dit onderzoek heeft een mogelijke architectuur voor de afhandeling van DBC’s laten zien. Deze architectuur is ontworpen door eerst de volgende elementen van de huidige situatie te analyseren: ˆ de doelen en strategie¨en van de samenwerkende organisaties in de gezondheidszorg ˆ de doelen en strategie¨en van ziekenhuizen en verzekeraars afzonderlijk ˆ de bedrijfsprocessen van ziekenhuizen en verzekeraars ˆ de in- en outputinformatie van deze bedrijfsprocessen ˆ de ondersteunende applicaties

Vervolgens zijn de eerste drie bovenstaande elementen ook voor de gewenste situatie geanalyseerd. Daaruit is afgeleid welke in- en outputinformatie nodig is in de gewenste situatie. Vervolgens zijn de stakeholders ge¨ıdentificeerd. Dit zijn: ˆ ziekenhuizen Specialisten willen zo weinig mogelijk administratieve taken en willen de privacy van de pati¨ent beschermen. Het management wil net als de specialist de privacy van de pati¨ent beschermen. Daarnaast wil het inzicht krijgen in de de kosten, de doorlooptijden van processen bepalen en de kostprijzen van productgroepen bepalen. De IT-afdeling wil goed te onderhouden systemen en gemakkelijk te gebruiken systemen. Wanneer een systeem gemakkelijk in gebruik is, wordt de IT-afdeling namelijk relatief weinig belast met vragen. ˆ verzekeraars Verzekeraar willen zoveel mogelijk informatie om de rechtmatigheid van declaraties te controleren. Daarnaast willen zij de prijs en kwaliteit van verschillende ziekenhuizen met elkaar vergelijken. Verzekeraars wensen declaraties zoveel mogelijk elektronisch af te handelen. ˆ pati¨enten/verzekerden Pati¨enten willen zo snel mogelijk behandeld worden in de zorginstelling van hun keuze. Zij willen inzicht krijgen in de producten die zorginstellingen en zorgverzekeraars aanbieden. Daarnaast willen zij dat er zorgvuldig met hun medische gegevens omgegaan wordt. ˆ de overheid De overheid wil dat ziekenhuizen inzicht krijgen in hun kosten en dat er een marktwerking ontstaat in de gezondheidszorg.

Uit de stakeholderanalyse zijn de requirements voor de architectuur opgesteld. Uit enkele verschillende communicatiemogelijkheden is voor ziekenhuizen voor HL7 MOM gekozen, aangezien dit de meest gebruikte standaard in Nederland is. Voor de communicatie tussen de applicaties van verzekeraars is gekozen voor directe berichtuitwisseling, aangezien verzekeraars relatief weinig applicaties gebruiken en de implementatie van middleware relatief veel moeite kost. Voor de declaraties die van ziekenhuizen naar verzekeraars gaan, zal de EI-standaard van VEKTIS gebruikt worden, aangezien deze standaard het meest gebruikt wordt. De nieuwe architectuur bevat de volgende nieuwe applicaties: de DBC-registratie-applicatie 87

(voor ziekenhuizen), de contractmanagementapplicatie (zowel voor ziekenhuizen als voor verzekeraars) en het datawarehouse (voor ziekenhuizen). Daarnaast moeten de volgende applicaties aangepast worden: de facturatie-applicatie (voor ziekenhuizen), de declaratieapplicatie (voor verzekeraars) en het managementinformatiesysteem (voor verzekeraars). De architectuur bevat nog geen mogelijkheid om pati¨enten de producten van zorginstellingen en verzekeraars te laten zien. Dit is wellicht interessant voor verder onderzoek. Een DBC begint bij zijn opening als lege DBC in de DBC-registratie-applicatie van het ziekenhuis. Tijdens het zorgtraject typeert de specialist de DBC. Vervolgens sluit de specialist de DBC. De DBC-registratie-applicatie koppelt de verrichtingen, behorend bij de behandeling, aan de DBC. Indien de combinatie correct is, slaat de DBC-registratieapplicatie de DBC op en cre¨eert hier de bijpassende productgroep bij. Deze DBC en productgroep worden daarna doorgegeven aan de facturatie-applicatie van het ziekenhuis. De facturatie-applicatie zoekt vervolgens het afgesproken tarief bij de productgroepen en stuurt deze productgroep naar de verzekeraar. De DBC wordt geanoniemiseerd en ook naar de verzekeraar gestuurd (bij voorkeur met een lagere frequentie dan de productgroepen om de privacy van de pati¨enten te beschermen). Bij de koppeling van verrichtingen aan DBC’s kunnen fouten ontstaan door foute registraties, maar ook door de aanwezigheid van parallelle DBC’s. Dit zijn twee DBC’s uit hetzelfde zorgtraject in dezelfde periode. Deze verrichtingen zouden standaard aan de eerste (of laatste) parallelle DBC gekoppeld kunnen worden, maar op deze manier worden DBC’s te zwaar (ze krijgen teveel verrichtingen toegewezen) of te licht (ze krijgen te weinig verrichtingen toegewezen). Dit is helaas een consequentie van de manier van registreren van DBC’s. Aangezien verrichtingen pas achteraf aan DBC’s gekoppeld worden, ontstaat nooit een 100% correct beeld van welke verrichtingen bij welke DBC’s horen. Deze manier van registreren is door de projectgroep DBC2003 gekozen, aangezien het veel werk zou zijn de applicaties in ziekenhuizen zo aan te passen dat verrichtingen meteen bij de DBC geregistreerd kunnen worden. Het is de bedoeling dat het in 2006 wel op deze manier zal verlopen.

88

13. Aanbevelingen Dit onderzoek heeft zich gericht op de DBC-situatie zoals deze zal zijn vanaf juli 2004. Zoals reeds in de conclusies gezegd, zal de situatie in 2006 pas ‘af’ zijn. De komende tijd zal dus onderzocht moeten worden hoe de applicatie-architectuur zal moeten veranderen om te komen tot een applicatie-architectuur die voldoet aan de eisen gesteld voor de DBC-situatie in 2006. Daarnaast zijn de volgende vragen interessant om te beantwoorden in verder onderzoek: ˆ Welke aanpassing zijn nodig aan de architectuur om pati¨enten producten van ziekenhuizen en verzekeraars in te laten zien? Zoals al in de conclusies gezegd is, bleek het niet haalbaar dit al in de gepresenteerde architectuur uit te werken. ˆ Hoe kunnen de verschillende gebruikersschillen eruit komen te zien? Dit onderzoek heeft de mogelijkheid aangegeven verschillende gebruikersschillen over de applicaties heen te bouwen om het gebruiksgemak te vergroten. ˆ Hoe zien de in de HL7-standaard te versturen berichten eruit? Zoals in dit onderzoek gezegd is, wordt de HL7-standaard aangepast aan de DBCsituatie. Om de communicatie tussen de verschillende ziekenhuisapplicaties mogelijk te maken, zal onderzocht moeten worden hoe de uit te wisselen berichten er precies uit komen te zien. ˆ Hoe zien de in de EI-standaard te versturen berichten eruit? Net als de HL7-standaard zal ook de EI-standaard aangepast worden. Hiervoor geldt dus hetzelfde als voor de HL7-berichten. ˆ Welke informatie heeft het datawarehouse als input nodig en welke informatie levert het datawarehouse op? Zoals reeds gezegd verschillen de wensen voor een datawarehouse per ziekenhuis. Daarom zou elk ziekenhuis verder moeten onderzoeken wat het met een datawarehouse wil. Daaruit kan afgeleid worden welke informatie het datawarehouse als input moet hebben en welke output het moet leveren. ˆ Welke informatie heeft het managementinformatiesysteem als input nodig en welke informatie levert het datawarehouse op? Voor het managementinformatiesysteem van verzekeraars geldt hetzelfde als net genoemd is bij het datawarehouse van ziekenhuizen. ˆ Welke beveiligingsmaatregelen zijn geschikt voor ziekenhuizen? Tijdens dit onderzoek is naar voren gekomen dat informatiesystemen van ziekenhuizen vaak slecht beveiligd zijn. In dit onderzoek zijn enige beveiligingsmaatregelen aangegeven, maar deze zouden in een vervolgonderzoek verder uitgewerkt moeten worden. ˆ Welke maatregelen kunnen genomen worden om fraude met DBC’s te voorkomen? Fraude in de zorg is een vrij actueel onderwerp. In de DBC-situatie zal de manier van frauderen waarschijnlijk veranderen. Het is daarom van belang te onderzoeken of de fraudemogelijkheden groter of kleiner worden, wat er verandert in de fraude en hoe fraude voorkomen kan worden. ˆ Welke rechtsgeldigheid heeft een elektronisch contract en hoe kan een dergelijk

89

contract gerealiseerd worden? In de architectuur ontwikkeld in dit onderzoek slaan de contractmanagementapplicaties van ziekenhuizen en verzekeraars ingescande contracten op. De hieruit afgeleide afspraken worden apart ingevoerd in deze applicaties. Het zou effici¨enter zijn om de contracten reeds vanaf het begin elektronisch op te stellen en op te slaan. Op deze manier hoeven de contracten niet ingescand te worden en hoeven de afspraken niet apart ingevoerd te worden. Er dient hiervoor onderzocht te worden of een dergelijk elektronisch contract dezelfde rechtsgeldigheid heeft als een papieren contract. Daarnaast is het interessant te onderzoeken hoe de afspraakgegevens van ziekenhuizen en verzekeraars automatisch gesynchroniseerd kunnen worden bij de declaratie van productgroepen. In de huidige architectuur bestaat namelijk het gevaar van inconsistentie, aangezien ziekenhuizen en verzekeraars allebei apart gedeclareerde productgroepen van het aantal afgesproken productgroepen aftrekken. ˆ Welke rol hebben de LAZR en de LMR in de toekomst? Ziekenhuizen moesten in de FB-situatie de LAZR- en LMR-gegevens bijhouden om aan hun bugdet te komen. Dit is in de toekomst niet meer nodig. Het is daarom interessant om te onderzoeken of deze registraties in de toekomst nog een rol hebben en zo ja, wat voor rol dit is.

Tenslotte wil ik toekomstige onderzoekers aanraden de volgende documenten goed te bestuderen: ˆ Het DBC registratie- en declaratiemodel 2004. ˆ Validatiemodule, specificaties en toelichting bij de validatiemodule.

Beide documenten zijn te vinden op de website van het project DBC2003 (www.dbc2003.nl).

90

Bibliografie Belastingdienst (2000). Handleiding systeemconcept en applicatie-architectuur startarchitectuur. Belastingdienst: intern document. Blank, J. & Krijger, M.J. (1982). Evaluation of methods and techniques for the analysis, design and implementation of information systems. Den Haag: Academic Service. Blobel, B. & Holena, M. (1997). Comparing middleware concepts for advanced healthcare system architectures. International Journal of Medical Informatics. Jaargang 46, pp. 69-85. By, R.A. de (1999). Diktaat: ontwerpen van informatiesystemen. Universiteit Twente: intern document. Chaffey, D. (2002). E-business and e-commerce management. Harlow: Pearson Education Limited. Cooper, A. (1999). The inmates are running the alysum. Why high-tech products drive use crazy and how to restore the sanity. Indianapolis: SAMS. DBC2003 (2003). DBC declaraties. http://www.dbc2003.nl/upload/DBC%20declaraties%20fase%201.pdf, 1-8-2003. DBC2003 (z.j.). DBC: een nieuw geluid in de zorg. http://www.dbc2003.nl/images/MWPD01020014101605.pdf, 10-3-2003. DBC2003 (2002). Gedetailleerde diagnosevastlegging binnen de DBC. http://www.dbc2003.nl/upload/DBC%20declaraties%20fase%201.pdf, 1-8-2003. DBC2003 (2003). Gezamenlijk plan van aanpak invoering DBC-systematiek. http://www.dbc2003.nl/upload/Bijlage%201 GPvA.doc, 10-3-2003. DBC2003 (2003). Het DBC registratie- en declaratiemodel 2004. http://www.dbc2003.nl/upload/Het%20DBC%20registratiemodel%202004% 20030704.pdf, 1-9-2003. DBC2003 (2003). Kaderregeling administratieve organisatie en interne controle inzake DBC registratie en facturering. http://www.dbc2003.nl/upload/Opzet%20AOIC%20versie%200.14.pdf, 1-7-2003. DBC2003 (2003). Projectvoorstel voor DBC-registratie HL7.3 berichten. http://www.dbc2003.nl/upload/Projectvoorstel voor DBC-registratie HL7.3 berichten.doc, 8-10-2003. DBC2003 (2003). Validatiemodule, specificaties en toelichting bij de validatiemodule. http://www.dbc2003.nl/upload/ZIP.zip, 8-10-2003. Deloitte & Touche (z.j.) Zorgverzekeraars aan bod. Onderzoek naar de rol en positie van zorgverzekeraars in het nieuwe zorgstelsel. Deloitte & Touche: intern document. Deloitte & Touche (2002). Productfinanciering in de zorg. Deloitte & Touche: intern document. 91

Franke, C. & Zeef, P. (2003). Implementing Electronic Services, Transnational guidelines, perspectives and case studies. http://primavera.fee.uva.nl/PDFdocs/2003-06.pdf, 1-6-2003. Gregor, S. & Johnston, R.B (2000). Developing an understandaing of interorganizational systems: Arguments for multilevel analysis and structuration theory. http://www.dis.unimelb.edu.au/staff/robertj/beef.pdf, 20-4-2003. Hansa (z.j.). Hansa. http://www.gesi.it/hansa/suite.htm, 30-7-2003. Hong, I. B. (2002). A new framework for interorganizational systems based on the linkage of participants’ role. Information & Management. Jaargang 39, pp. 261-270. Hooghiemstra, T.F.M. (2002). Privacy bij ICT in de zorg. http://www.cbpweb.nl/downloads av/AV26.pdf, 25-7-2003. ISO/IEC (1991). Software product evaluation, quality characteristics and guidelines for their use. ISO/IEC 9126. Jochemsen, H. (2002). Kiezen met zorg. http://www.kiezenmetzorg.nl/kiezen met zorg eindrapport.pdf, 1-6-2003. Linden, H. van der, Boers, G. & Tange, H. (z.j.) Virtueel EPD, een virtueel dossier op basis van CorbaMed. http://www.openkaart.org/docs/downloads/vitual epd/virtueel epd.pdf, 1-9-2003. Ministerie van Justitie (2003). Hoofdlijnen Wet Bescherming Persoonsgegevens. http://www.justitie.nl, 3-4-2003. Ministerie van Volksgezondheid, Welzijn en Sport (2001). Tellen en meten. http://www.tellenenmeten.nl, 10-3-2003. Ministerie van Volksgezondheid, Welzijn en Sport (2001). Vraag aan bod, hoofdlijnen van vernieuwing van het zorgstelsel. http://www.minvws.nl/documents/meva/Nota/Vraag-aan-bod.pdf, 10-3-2003. Ministerie van Volksgezondheids, Welzijn en Sport (2002). Zorgnota 2003. http://www.minvws.nl/documents/fez/Nota/Zorgnota%202003.pdf, 1-5-2003. Nationaal ICT Instituut in de Zorg (2002). Architectuurontwerp basis infrastructuur in de zorg. https://doc.telin.nl/dscgi/ds.py/Get/File-28395/Architectuurontwerp basis infrastructuur in de zorg.pdf, 1-5-2003. Oberendorff, L. (1999). Privacy en Toegankelijkheid in Gemeenschappelijk te gebruiken Elektronische Pati¨enten Dossiers. http://home.hccnet.nl/l.oberendorff/privacyentoegankelijkheid.pdf, 4-4-2003. Orde van Medisch Specialisten et al. (z.j.). DBC-Registratie, opzet, aanpak en organisatie. http://www.dbc2003.nl/images/MWPD01020423092427.pdf, 10-3-2003.

92

Raad voor de Volksgezondheid en Zorg (2003). Marktwerking in de medisch specialistische zorg. http://www.ggzbeleid.nl/pdfnma/rvz Advies Marktwerking.pdf, 1-5-2003. Rauch, W. B. (1996). Distributed open systems engineering. New York: John Wiley & Sons Inc. Robertson, J. & Robertson, S. (1999). Mastering the requirements process. London: Addison-Wesley. Schaepkens, F.F.J.M. (2002). Ziekenhuisbekostiging in Nederland; van FB naar DBC. MCA Tijdschrift voor Organisaties in Control. Jaargang 6, nr 5. pp. 13-24. Stichting CBV (2003). Het CBV bestand. http://www.cbv.nl/bestand/bestand2.html, 1-4-2003. Stichting HL7 Nederland (z.j.) HL7. http://www.hl7.nl, 1-8-2003. Tagg, R. & Freyberg, C. (1997). Designing distributed and cooperative information systems. Cambridge: Cambridge University Press. Telematica Institute (2000). Rapid Service Development Method. https://doc.telin.nl/dscgi/ds.py/Get/File9156/Rapid Service Development Methodology.pdf, 10-3-2003. Verschuren, P. & Doorewaard, H. (2003). Het ontwerpen van een onderzoek. Utrecht: Uitgeverij Lemma BV, 3e druk. Vlist, P. van der et. al. (1992). EDI in de Gezondheidszorg. Alphen aan de Rijn: Samson Bedrijfsinformatie. Wieringa, R.J. (1996). Requirements Engineering. Chichester: John Wiley & Sons.

93

Interviews Ziekenhuizen Vlietland Ziekenhuis ˆ Steef Nieuwenhuijsen

Rivas Zorggroep ˆ Frank van Oosterhout ˆ Jack van Oord

AZG ˆ Maria Hintzbergen ˆ Erik van der Velde

Verzekeraars Achmea ˆ Benno Teijgeler ˆ Eddy van der Stouwe ˆ Ceesjan van Westen

DSW ˆ Rita de Jong

ZIS-levanciers Chipsoft ˆ Diederik de Reus ˆ Ritchey Blommers

HISCOM ˆ Jacob Hofdijk

McKesson ˆ Mark Boon

Overig DBC2003/Cap Gemini Ernst & Young ˆ Henk Bakker

VEKTIS ˆ Piet Moerkens ˆ Marcella Walraven ˆ Robert de Bie

94

Bijlage 1: afkortingenlijst AGB-Z CBP CBV COM CORBA CTG CvV CvZ DBC DFD DHE FB FRT HL7 ICD-9 IOS LAZR LMR NAW ORB RPC WBP WGBO XML ZIS

Algemeen GegevensBeheer Zorgverleners College Bescherming Persoonsgegevens Centraal Bureau Verrichtingen Component Object Model Common Object Request Broker Architecture College Tarieven Gezondheidszorg Classificatie van Verrichtingen Classificatie van Ziekten Diagnose Behandel Combinatie Data Flow Diagram Distributed Health Environment Functiegericht Budget Function Refinement Tree Health Level 7 International Classification of Diseases 9 Interorganisationeel Informatiesysteem Landelijke Ambulante Zorg Registratie Landelijke Medische Registratie Naam Adres Woonplaats Object Request Broker Remote Procedure Call Wet Bescherming Persoonsgegevens Wet op de Geneeskundige BehandelingsOvereekomst eXtensible Markup Language ZiekenhuisInformatieSysteem

95

Bijlage 2: woordenlijst Adherentiegetallen

informatie over de productie en capaciteit van ziekenhuizen

AGB-Z

codering voor medische specialismen

Applicatie

informatiesysteem dat ´e´en primaire functie binnen de organisatie vervult

Architectuur

hoog-niveau functionele beschrijving van applicatiecomponenten (zoals software, databases en netwerken) en de manier waarop deze samenwerken

CBP

Nederlandse organisatie die toeziet op de uitvoering van de WBP

CBV

Nederlandse organisatie die enkele medische verrichtingtabellen beheert

COM

algemene middleware-omgeving ontwikkeld door Microsoft op basis van een ORB

CORBA

algemene middleware-omgeving ontwikkeld door OMG (Object Management Group) op basis van een ORB

CTG

organisatie die de tarieven van medische verrichtingen vaststelt

CvV

codering voor verrichtingen

CvZ

Nederlandse typeringslijst van ziekten afgeleid van ICD-9

DBC

geheel van activiteiten van ziekenhuis en medisch specialist voortvloeiend uit de zorgvraag waarvoor de pati¨ent het ziekenhuis consulteert

DFD

diagram dat aangeeft hoe data stroomt tussen processen en dataopslag

DHE

gezondheidsspecifieke middleware-omgeving

FB

budget dat ziekenhuizen ontvangen op basis van adherentiegetallen

FRT

boomstructuur die aangeeft welke functies een applicatie uit dient te voeren

HL7

internationale standaard voor de uitwisseling van medische en administratieve berichten in ziekenhuizen 96

ICD-9

internationale typeringslijst van ziekten

Infrastructuur

hele verzameling van technische componenten die het aanbod aan ICT-gebaseerde services verzorgen (zowel aan werknemers als aan klanten)

Interorganisationeel informatiesysteem

informatiesysteem dat over organisatiegrenzen heengaat

LAZR

registratie van poliklinische gegevens

LMR

registratie van medische en administratieve gegevens over klinische behandelingen en dagverplegingen

Lupsum

bedrag dat een specialist jaarlijks toegewezen krijgt

NAW

naam-, adres- en woonplaatsgegevens van een pati¨ent

ORB

component dat ervoor zorgt dat verschillende objecten elkaar kunnen loceren en met elkaar kunnen communiceren

Productstructuur

een adequate typering van de medische specialistische zorg, waarbij de producten medisch herkenbaar en vergelijkbaar zijn en wat betreft kosten en inzet van de medisch specialisten homogeen zijn.

RPC

procedure-aanroep bij een externe applicatie

Spiegelinformatie

vergelijkende informatie over de prestaties van verschillende ziekenhuizen

Typeringslijst

een lijst opgesteld door de wetenschappelijke vereniging van een bepaald specialisme aan de hand waarvan de specialist DBC’s kan typeren.

WBP

wet voor de bescherming van persoonsgegevens van burgers

WGBO

wet voor de bescherming van persoonsgegevens van pati¨enten

XML

standaard voor de syntaxopbouw van berichten

ZIS

organisatiebreed informatiesysteem voor ziekenhuizen

97

Bijlage 3: financieringsproces huidige situatie Ziekenhuis (Afdeling Medische Registratie)

Prismant

Ministerie van VWS

Registreren LAZR-en LMR-gegevens

LAZR-en LMR-gegevens [nieuw]

Leveren LAZR-en LMRgegevens aan Prismant

Ontvangen LAZR-en LMRgegevens

Bepalen adherentiegetallen en spiegelinformatie

Leveren adherentiegetallen en spiegelinformatie aan Ministerie van VWS

Ontvangen adherentiegetallen en spiegelinformatie

Bepalen budget

98

Bijlage 4: financieringsproces gewenste situatie Verzekeraar (Management)

Ziekenhuis (Management) Selecteren representatieve DBC's

Zenden DBC-gegevens naar verzekeraar

Ontvangen DBC-gegevens

Onderhandelen over volume, prijs en inhoud DBC's

Opstellen contract

Opslaan contract

99

bijlage 5: medisch proces huidige situatie Patiënt Maken afspraak

Administrateur Voorbereiden afspraak

Specialist Opvragen medisch dossier

Onderzoeken patiënt

Stellen diagnose

Registreren diagnose in medisch dossier

Inplannen capaciteit

Plaatsen orders

Uitvoeren behandeling

Voorschrijven medicatie

Registreren behandeling/medicatie in medisch dossier

Vastleggen verrichtingen

Uitvoeren controle

Factureren verrichtingen

100

Bijlage 6: medisch proces gewenste situatie Patiënt Maken afspraak

Specialist

Administrateur Voorbereiden afspraak

Opvragen medisch dossier

Onderzoeken patiënt

Stellen diagnose

Registreren diagnose in medisch dossier

Inplannen capaciteit Openen DBC

Plaatsen orders

Typeren DBC

Uitvoeren behandeling

Voorschrijven medicatie

Registreren behandeling/medicatie in medisch dossier

Registreren definitieve DBC

Sluiten DBC

Uitvoeren controle

Uitvoeren controle

Factureren productgroep

101

Vastleggen verrichtingen

102

CvV

CBV

reden afspraak, verwijzing huisarts, benodigd specialisme, beschikbare tijdstippen

mogelijke verrichtingen

mogelijke verrichtingen

voorbereide afspraak

Voorbereide afspraken

Voorlopige verrichtingen

verrichtingen

diagnose

diagnose

Afgekeurde verrichtingen

afgekeurde goedgekeurde verrichtingen verrichtingen

Uitvoeren controle

uitgevoerde behandeling

NAW-gegevens, verzekeringsgegevens

gekozen behandeling

Factureren verrichtingen

gefactureerde verrichtingen

tarieven voor verrichtingen

Uitvoeren behandeling

goedgekeurde verrichtingen

Goedgekeurde verrichtingen

uitgevoerde behandeling

capaciteitsplanning

Inplannen capaciteit

Capaciteitsplanning

gekozen medicatie

gekozen behandeling

gekozen behandeling

diagnose

mogelijke diagnoses

Registreren behandeling/medicatie in medisch dossier

Stellen diagnose

Voorschrijven medicatie

gekozen behandeling

Registreren diagnose in medisch dossier

resultaten onderzoek

Medische dossiers

beschikbaar personeel

verrichtingen

Personeelsplanning

NAW-gegevens, verzekeringsgegevens

Patiënten

medische gegevens patiënt

Opvragen medisch dossier

medische gegevens

Onderzoeken patiënt

NAW-gegevens

klachten

Vastleggen verrichtingen

beschikbare tijdstippen

Voorbereiden afspraak

onvoorbereide afspraak

Onvoorbereide afspraken

tijdstip afspraak, patiënt, specialist, locatie

Maken afspraak

beschikbare specialisten

Specialisten

Patiënt

Gefactureerde verrichtingen

CTG-tarieven

Orders

orders

Plaatsen orders

gekozen behandeling

Bepalen behandeling

CvZ

Bijlage 7: DFD medisch proces huidige situatie

103

CvV

CBV

goedgekeurde verrichtingen

gekozen behandeling

gevalideerde DBC's

gesloten DBC's

Goedgekeurde verrichtingen

goedgekeurde verrichtingen

gekozen medicatie

Uitgevallen DBC's

diagnose

tarieven productgroepen

Ongefactureerde productgroepen

gefactureerde productgroepen

Typeringslijsten

typeringsgegevens

Typeren DBC

open DBC

NAWgegevens

gesloten zorgtraject

Open zorgtrajecten

open zorgtraject

Gefactureerde productgroepen

Gesloten zorgtrajecten

gesloten zorgtraject

Sluiten zorgtraject

open zorgtraject

Openen zorgtraject

Openen DBC

Orders

orders

open DBC

NAWgegevens

Open DBC's

open DBC

gekozen behandeling

Bepalen behandeling

CvZ

Plaatsen orders

Registreren definitieve DBC

NAWgegevens

Patiënten

gekozen behandeling

gekozen behandeling

gekozen behandeling

NAW-gegevens, verzekeringsgegevens

open DBC

NAWgegevens

Capaciteitsplanning

capaciteitsplanning

Inplannen capaciteit

Factureren productgroepen

DBC-contracten

Gevalideerde DBC's

Gesloten DBC's

gesloten DBC's

Sluiten DBC

NAW-gegevens, verzekeringsgegevens

Uitvoeren behandeling

beschikbaar personeel

mogelijke diagnoses

Registreren behandeling/medicatie in medisch dossier

Voorschrijven medicatie

Stellen diagnose

NAW-gegevens

uitgevallen verrichtingen

Uitvoeren controle

uitgevoerde behandeling

NAW-gegevens, verzekeringsgegevens

uitgevoerde behandeling

uitgevallen verrichtingen

Uitgevallen verrichtingen

Afgekeurde verrichtingen

afgekeurde verrichtingen

verrichtingen

Vastleggen verrichtingen

Controleren verrichtingen

verrichtingen

Medische dossiers

medische gegevens patiënt

Opvragen medisch dossier

diagnose

resultaten onderzoek

Registreren diagnose in medisch dossier

diagnose

Onderzoeken patiënt

medische gegevens

klachten

Personeelsplanning

beschikbare tijdstippen

mogelijke verrichtingen

mogelijke verrichtingen

Voorlopige verrichtingen

Voorbereide afspraken

voorbereide afspraak

Voorbereiden afspraak

onvoorbereide afspraak

Onvoorbereide afspraken

tijdstip afspraak, patiënt, specialist, locatie

Maken afspraak

reden afspraak, verwijzing huisarts, benodigd specialisme, beschikbare tijdstippen beschikbare specialisten

Specialisten

Patiënt

Bijlage 8: DFD medisch proces gewenste situatie

Bijlage 9: declaratieproces huidige situatie Ziekenhuis

Verzekeraar Verzenden papieren declaraties

Verzenden elektronische declaraties

Ontvangen papieren declaraties

Overtypen declaraties

Ontvangen elektronische declaraties

Uitvoeren batchgewijze controle mbv CTG-lijsten

uitval hoger dan x% uitval lager dan x% Controleren uitval

Uitbetalen goedgekeurde declaraties

Ontvangen betalingen

Ontvangen afwijzingen

Contact opnemen met verzekeraar

Geven uitleg over afwijzingen

Verbeteren incorrecte declaraties

Verzenden verbeterde declaraties

104

Controleren verbeterde declaraties

Afwijzen incorrecte declaraties

Bijlage 10: declaratieproces gewenste situatie Verzekeraar

Ziekenhuis

Ontvangen elektronische declaraties

Verzenden elektronische declaraties

Verzenden anonieme DBC's

Uitvoeren batchgewijze controle mbv DBC-contracten en standaardtarieven

uitval hoger dan x% uitval lager dan x% Controleren uitval

Uitbetalen goedgekeurde declaraties

Ontvangen betalingen

Ontvangen afwijzingen

Contact opnemen met verzekeraar

Geven uitleg over afwijzingen

Verbeteren incorrecte declaraties

Verzenden verbeterde declaraties

105

Controleren verbeterde declaraties

Afwijzen incorrecte declaraties

Bijlage 11: DFD declaratieproces huidige situatie (vanuit ziekenhuis) Verzekeraar

verrichtingen, vragen over reden afwijzing

verrichtingen Gefactureerde verrichtingen

gefactureerde verrichtingen

Verzenden elektronische declaraties

betalingen

afgewezen verrichtingen

NAWgegevens

verbeterde verrichtingen

Ontvangen betalingen

Verzenden papieren declaraties

verrichtingen

Contact opnemen met verzekeraar

Verzenden verbeterde declaraties betalingen

NAWgegevens Betalingen verrichtingen Patiënten

verbeterde verrichtingen

Ontvangen afwijzingen

afgewezen verrichtingen

Verbeterde verrichtingen

Goedgekeurde verrichtingen Afgewezen verrichtingen verbeterde verrichtingen afgewezen verrichtingen Verbeteren incorrecte declaraties

verbeterde verrichtingen

Verbeterde verrichtingen

106

Bijlage 12: DFD declaratieproces gewenste situatie (vanuit ziekenhuis) Verzekeraar

productgroepen, vragen over reden afwijzing

productgroepen Verzenden elektronische declaraties

betalingen (anonieme) DBC's

gefactureerde productgroepen

afgewezen productgroepen

Gefactureerde productgroepen

ongefactureerde productgroepen NAWgegevens

verbeterde productgroepen

Ontvangen betalingen Verzenden verbeterde declaraties

Verzenden (anonieme) DBC's

betalingen

Betalingen Ongefactureerde productgroepen

Patiënten

Contact opnemen met verzekeraar

verbeterde productgroepen

Ontvangen afwijzingen

(anonieme) DBC's

afgewezen productgroepen

Verbeterde productgroepen

Afgewezen productgroepen

verbeterde productgroepen afgewezen productgroepen

Gevalideerde DBC's DBC's

Verbeteren incorrecte declaraties

verbeterde DBC's

Verbeterde DBC's

107

Bijlage 13: DFD declaratieproces huidige situatie (vanuit verzekeraar) Ziekenhuis

papieren verrichtingen Uitbetaalde verrichtingen

elektronische verrichtingen

afgewezen verrichtingen, redenen afwijzing

bevestiging betaling

Ontvangen papieren declaraties

uitbetaalde verrichtingen

Ontvangen elektronische declaraties papieren declaraties

Afwijzen incorrecte declaraties

Uitbetalen goedgekeurde declaraties

uitleg over redenen afwijzingen Overtypen declaraties

elektronische verrichtingen

Geven uitleg over afwijzingen

goedgekeurde verrichtingen

elektronische verrichtingen afgewezen verrichtingen, reden afwijzing

Onbehandelde verrichtingen

onbehandelde verrichtingen

Goedgekeurde verrichtingen

goedgekeurde verrichtingen

Uitvoeren batchgewijze controle mbv CTG-lijsten

Afgewezen verrichtingen goedgekeurde verrichtingen

uitgevallen verrichtingen

Uitgevallen verrichtingen

polisgegevens patiënten CTG-tarieven, CTG-instellingsgegevens

afgewezen verrichtingen, reden afwijzing

goedgekeurde verrichtingen

uitgevallen verrichtingen

Controleren uitval afgewezen verrichtingen, reden afwijzing

polisgegevens patiënt CTG-tarieven, CTG-instellingsgegevens

Polissen

polisgegevens patiënten

CTG-gegevens

CTG-tarieven, CTG-instellingsgegevens

108

Controleren verbeterde declaraties

Bijlage 14: DFD declaratieproces gewenste situatie (vanuit verzekeraar) Ziekenhuis

elektronische productgroepen

Uitbetaalde productgroepen afgewezen productgroepen, redenen afwijzing

bevestiging betaling uitbetaalde productgroepen

Ontvangen elektronische declaraties Afwijzen incorrecte declaraties

Uitbetalen goedgekeurde declaraties

uitleg over redenen afwijzingen

elektronische productgroepen

Geven uitleg over afwijzingen

goedgekeurde productgroepen

afgewezen productgroepen, reden afwijzing

Onbehandelde productgroepen

Goedgekeurde productgroepen

onbehandelde productgroepen

goedgekeurde productgroepen Afgewezen verrichtingen

Uitvoeren batchgewijze controle mbv DBC-afspraken

goedgekeurde productgroepen

uitgevallen productgroepen

Uitgevallen productgroepen

polisgegevens patiënten

afgewezen productgroepen, reden afwijzing

goedgekeurde productgroepen

uitgevallen productgroepen

onderhandelde productgroepprijzen, hoeveelheid op te nemen productgroepen, algemene productgroepprijzen

Controleren uitval afgewezen productgroepen, reden afwijzing

onderhandelde productgroepprijzen, hoeveelheid op te nemen productgroepen, algemene productgroepprijzen

polisgegevens patiënt

Polissen polisgegevens patiënten DBC-afspraken

onderhandelde productgroepprijzen, hoeveelheid op te nemen productgroepen, algemene productgroepprijzen

109

Controleren verbeterde declaraties