Faculteit Toegepaste Wetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE
Web service integratie voor eHealth toepassingen door Kristof STEURBAUT en Sabrina STEURBAUT
Promotoren: Prof. Dr. Ir. F. DE TURCK, Prof. Dr. J. DECRUYENAERE Scriptiebegeleider: Ir. S. VAN HOECKE
Scriptie ingediend tot het behalen van de academische graad van licenciaat in de informatica
Academiejaar 2004–2005
Dankwoord Bij de realisatie van deze scriptie houden we eraan een aantal personen speciaal te bedanken voor hun steun en hulp die we erg konden waarderen. In de eerste plaats gaat vanzelfsprekend onze oprechte dank uit naar onze promotoren Prof. Dr. Ir. Filip De Turck (UGent) en Prof. Dr. Johan Decruyenaere (UZ Gent), die de leiding van dit eindwerk op zich namen. Met hun hulp kregen we inzicht in de probleemstelling en genoten we de nodige ondersteuning bij het uitwerken van een oplossingsstrategie waarbij ons belangrijke suggesties werden gedaan. In tweede instantie willen we ook Ir. Sofie Van Hoecke bijzonder bedanken. Ze was onze gids op weg naar de uiteindelijke voltooiing van deze scriptie, bij wie we meer dan eens op haar deskundige hulp en begeleiding konden beroep doen. We hebben dan ook dankbaar rekening gehouden met de inhoudelijke suggesties en de kritische lectuur van de hoofdstukken. We vermelden graag en met dankbaarheid: Dhr. Chris Danneels, die ons wegwijs wist te maken in het IZIS-systeem en op de dienst Intensieve Zorgen; Mevr. Diane Keerstock, die ons de dagelijkse werking van de administratiedienst toonde, en de vele andere mensen van het Universitair Ziekenhuis die bij dit eindwerk betrokken waren. Tenslotte willen we onze ouders bedanken voor de mogelijkheden die ze ons gaven om universitaire studies aan te vatten en tevens voor hun aanmoedigingen. We danken ook onze vrienden voor hun belangstelling en kritisch luisterend oor.
Gent, mei 2005, Kristof Steurbaut en Sabrina Steurbaut
Toelating tot bruikleen “De auteurs geven de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopi¨eren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”
Kristof Steurbaut, Sabrina Steurbaut, mei 2005
Web service integratie voor eHealth toepassingen door Kristof STEURBAUT en Sabrina STEURBAUT Scriptie ingediend tot het behalen van de academische graad van licenciaat in de informatica Academiejaar 2004–2005 Promotoren: Prof. Dr. Ir. F. DE TURCK, Prof. Dr. J. DECRUYENAERE Scriptiebegeleider: Ir. S. VAN HOECKE Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE
Samenvatting In de huidige applicaties zijn gegevens vaak verbrokkeld aanwezig. Routinetaken, papieren nota’s, delen van data doen de behoefte ontstaan om informatiestromen te integreren tussen verschillende platformen en applicaties. ’eHealth’ zoals de informatisering in de medische wereld wordt genoemd biedt de mogelijkheid om door het inzetten van nieuwe informaticatechnologie een vereenvoudiging en verbetering te introduceren. Na een studie van web services hebben we ons geconcentreerd op de noden en vereisten van de facturatie van medisch technische prestaties op de dienst Intensieve Zorgen van het Universitair Ziekenhuis Gent. We onderzochten hoe het huidige facturatieproces kan omgevormd worden tot een volledig geautomatiseerd proces waarbij verschillende services autonoom werken. De trend naar een servicegebaseerde architectuur be¨ınvloedde de manier waarop het ontwerp van de applicatie werd opgevat. In de datastromen tussen de services zelf kan XML als platformonafhankelijk formaat ingezet worden om de informatie van een tarificatieformulier, dat de te factureren verstrekkingen bevat, bij te houden. Voor de implementatie werden web services gebruikt om een losse koppeling tussen de verschillende taken in het facturatieproces mogelijk te maken. De hoofdtaken werden als services gemodelleerd met een eigen verantwoordelijkheid en de uitwerking in C# werd voorzien van een transparante gebruikersinterface.
Trefwoorden web services, serviceori¨entatie, integratie, automatisatie, eHealth
INHOUDSOPGAVE
i
Inhoudsopgave Lijst met afkortingen
v
1 Inleiding
1
1.1
Indeling van het boek . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2 Onderzoek en Technologie
2 3
2.1
Interoperabiliteit en standaarden als drijvende krachten . . . . . . . . . . . . . .
3
2.2
Web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Wat? Waarom? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
Web service architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.1
eXtensible Markup Language . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3.2
Simple Object Access Protocol . . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.3
Web Services Description Language . . . . . . . . . . . . . . . . . . . . .
7
2.3.4
Universal Description, Discovery, and Integration . . . . . . . . . . . . . .
8
Uitgebreide web services architectuur . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4.1
Web Services Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4.2
BPEL4WS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.5
Integratie via web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
2.6
.NET
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.6.1
Ontwikkelen van een web service . . . . . . . . . . . . . . . . . . . . . . .
11
2.6.2
Serialisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
2.6.3
Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
2.6.4
Levensloop van een web service . . . . . . . . . . . . . . . . . . . . . . . .
12
2.6.5
Asynchrone web services . . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
2.6.6
Gebruik van WSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
2.3
2.4
INHOUDSOPGAVE
2.7
ii
Windows Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Case Study
14 15
3.1
Wat is eHealth? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Case Study IZ, UZ Gent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.1
IZ InformatieSysteem . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.2
Technische omgeving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.2.3
Definities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.4
Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4 Specificatie
21
4.1
Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.1
Monitorsysteem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.2
Administratiebeheerder . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
Sequentieschema’s . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.3
5 Architectuur 5.1
5.2
5.3
5.4
28
Een servicegebaseerde architectuur . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.1.1
Definitie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5.1.2
Principes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
Serviceori¨entatie en objectori¨entatie . . . . . . . . . . . . . . . . . . . . . . . . .
30
5.2.1
Vergelijking en parallellen . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
Globale architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.3.1
Ontwerppatronen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.3.2
Een centraal beheer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.3.3
XML als medisch dataformaat . . . . . . . . . . . . . . . . . . . . . . . .
34
5.3.4
Architectuur van de eHealth toepassing . . . . . . . . . . . . . . . . . . .
35
Bespreking van de eHealth-services . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.1
Grafische User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.2
TimerService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.3
TriggerService
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.4.4
TarificatieService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
INHOUDSOPGAVE
iii
5.4.5
RIZIVRegelService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.4.6
ArtsenService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.4.7
MPFLOPService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6 Implementatie 6.1
39
De TimerService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.1.1
De klasse ProjectInstaller . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.1.2
De Windows Service EHealthTimerService . . . . . . . . . . . . . . . . . .
40
De TriggerService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.2.1
De DataSet LaatsteFacturatie . . . . . . . . . . . . . . . . . . . . . . . . .
41
6.2.2
De SybaseTriggerService . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
De TarificatieService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
6.3.1
De DataSet Prestaties . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.3.2
De DataSet Feestdagen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
46
6.3.3
De DataSet Tarificatieformulieren
. . . . . . . . . . . . . . . . . . . . . .
46
6.3.4
De TarificatieFormatService . . . . . . . . . . . . . . . . . . . . . . . . . .
47
De RegelService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.4.1
De DataSet Regels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
6.4.2
De RIZIVRegelService . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
48
De ArtsenService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
6.5.1
De DataSet SpecialisatieCodes . . . . . . . . . . . . . . . . . . . . . . . .
49
6.5.2
De DataSet ArtsenInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.5.3
De ArtsenInfoService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
De MPFLOPService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
6.6.1
Web service MPFLOPFormatService . . . . . . . . . . . . . . . . . . . . .
50
6.6.2
De klasse MPFLOPBuilder . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.6.3
De klasse MPFLOPRecord . . . . . . . . . . . . . . . . . . . . . . . . . .
51
6.6.4
String formatting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
De Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.7.1
De DataSet Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.7.2
De MonitorService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
6.8
De Grafische User Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.9
Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
56
6.2
6.3
6.4
6.5
6.6
6.7
INHOUDSOPGAVE
iv
7 Prestatiemetingen
57
7.1
De testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
7.2
De code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
57
7.3
De resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
59
8 Besluiten en uitbreidingen
63
8.1
Besluit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
63
8.2
Uitbreidingen en verder onderzoek . . . . . . . . . . . . . . . . . . . . . . . . . .
64
8.2.1
64
Datastandaarden in de gezondheidszorg . . . . . . . . . . . . . . . . . . .
A Gebruikershandleiding eHealth Tarificatie applicatie
66
A.1 Overzicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
A.2 Tarificatieformulieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
A.3 MPFLOP-bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
A.3.1 Controleren van een MPFLOP . . . . . . . . . . . . . . . . . . . . . . . .
70
A.3.2 Zoeken van een MPFLOP . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.3.3 MPFLOP openen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.4 Instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
74
A.4.1 Algemene instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.4.2 Artsen Informatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
76
A.4.3 Feestdagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.4.4 Medisch Technische Prestaties
. . . . . . . . . . . . . . . . . . . . . . . .
82
A.4.5 RIZIV-regels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
B XML-specificatie van het tarificatieformulier en MPFLOP B.1 Voorbeeld van een formulier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C Installatie
86 86 89
C.1 Installatie web services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
89
C.2 Installatie gebruikersinterface en timer . . . . . . . . . . . . . . . . . . . . . . . .
93
Lijst met afkortingen
Lijst met afkortingen
BPEL4WS
Business Process Execution Language for Web Services
COM
Component Object Model
CORBA
Common Object Request Broker Architecture
GUI
Graphical User Interface
HL7
Health Level Seven
HTML
Hypertext Markup Language
HTTP
Hypertext Transport Protocol
IIS
Internet Information Services
IZIS
Intensieve Zorgen Informatie Systeem
ODBC
Open DataBase Connectivity
OO
Object Oriented
RIZIV
Rijksinstituut voor ziekte- en invaliditeitsverzekering
RPC
Remote Procedure Call
SO
Service Oriented
SOA
Service Oriented Architecture
SOAP
Simple Object Access Protocol
TCP/IP
Transmission Control Protocol/Internet Protocol
WSDL
Web Services Description Language
UDDI
Universal Description Discovery and Integration
URI
Uniform Resource Identifier
WSE
Web Services Enhancements
XML
eXtensible Markup Language
v
INLEIDING
1
Hoofdstuk 1
Inleiding De industri¨ele revolutie leidde in de negentiende eeuw een nieuw tijdperk in met de introductie van machines. Het was de start van een grote evolutie waarin menselijke taken werden geautomatiseerd. In de twintigste eeuw kenden we een informatierevolutie. De ontwikkeling van de computer vormde hier een nieuwe impuls voor diverse informatiestromen en de automatisatie van bedrijfsprocessen. Op sommige punten in deze innovatie moeten echter nog mensen bepaalde routinetaken uitvoeren. Alsook in de gezondheidszorg werd de IT-infrastructuur ingezet om effici¨ent de informatie over pati¨enten te beheren. Het ontwikkelen van een standalone applicatie voor elk probleem leidt er echter toe dat veel informatie verbrokkeld aanwezig is. Het integreren van applicaties en informatie-eenheden vormt hier een bijzondere uitdaging want jammer genoeg is bepaalde informatie nog strikt papiergebaseerd wat leidt tot routinetaken bij het elektronisch verwerken van deze documenten.
Waar vroeger diverse aparte applicaties werden ontwikkeld is er vandaag een trend naar serviceori¨entatie. De ontwikkeling van web services hebben bijgedragen tot de servicegebaseerde architectuur die als oplossingsmodel inzake automatisatie van onafhankelijke bedrijfsprocessen aan belang wint. Het is een benadering waarin de begrippen ’beschikbaarheid’, ’flexibiliteit’, ’samenwerking’, ’autonomie’ worden vooropgesteld en waarin standaarden een cruciale rol spelen wat ’interoperabiliteit’ betreft.
1.1 Indeling van het boek
1.1
2
Indeling van het boek
In deze scriptie hebben we bijzondere aandacht voor de integratie van eHealth toepassingen door middel van web services. We bekijken hoe een applicatie kan ontwikkeld worden die de administratieve taken bij de facturatie van medisch technische prestaties van pati¨enten automatiseert en integreert via web services. In hoofdstuk 2 bespreken we eerst de web service technologie en diens voordelen. In hoofdstuk 3 lichten we de case study verder toe. De gebruikerscontext en interacties die de eHealth-facturatietoepassing beoogt komen aan bod in hoofdstuk 4. In hoofdstuk 5 gaan we dieper in op de architectuur. We gaan na wat een service gebaseerde architectuur te bieden heeft en hoe we de eHealth toepassing kunnen ontwerpen rekening houdende met de diverse gebruikersnoden. Hoofdstuk 6 gaat in op enkele implementatiedetails. Prestatiemetingen worden beschreven in hoofdstuk 7. Tot slot raken we enkele uitbreidingen aan voor de toepassing. We voegen aan deze scriptie ook enkele bijlages toe waarbij bijlage A een gebruikershandleiding biedt van de ontwikkelde eHealth toepassing. Bijlage C geeft een overzicht van de installatie van de toepassing.
ONDERZOEK EN TECHNOLOGIE
3
Hoofdstuk 2
Onderzoek en Technologie In dit hoofdstuk behandelen we het web service framework. We bekijken het gebruik van web services als een manier om systemen en applicaties te connecteren waardoor een informatieuitwisseling en -deling mogelijk wordt. We bekijken de standaarden XML, SOAP, WSDL, UDDI, ... Web services vormen een nieuw platform waarop gedistribueerde applicaties kunnen gebouwd worden op een gestandaardiseerde manier en met interoperabiliteit en integratie tussen applicaties als drijvende krachten. Verder bekijken we web services binnen de .NET omgeving.
2.1
Interoperabiliteit en standaarden als drijvende krachten
Informatieuitwisseling tussen computers onderling is een noodzaak geworden. Een applicatie staat zelden nog volledig op zichzelf maar omvat een combinatie van softwarecomponenten die met elkaar samenwerken. Verschillende computers en softwareapplicaties wensen informatie en functionaliteit te kunnen delen over een netwerk. Interoperabiliteit kunnen we omschrijven als de mogelijkheid om verschillende applicaties, meerdere computersystemen, effectief te laten communiceren over verschillende platformen en onafhankelijk van de gebruikte taal. De komst van XML en web services vormen een grote bijdrage om de interoperabiliteit te verhogen tussen applicaties. De communicatie bij web services is gebaseerd op het gebruik van platformonafhankelijke standaarden.
2.2 Web services
2.2
4
Web services
2.2.1
Wat? Waarom?
Het World Wide Web Consortium (W3C) [1] omschrijft een web service als: Een web service is een softwareapplicatie ge¨ıdentificeerd door een URI, wiens interfaces en bindingen in staat zijn om te worden gedefinieerd, beschreven en gevonden op basis van XML. Een web service ondersteunt directe interacties met andere softwareapplicaties gebruik makend van XML gebaseerde berichten die uitgewisseld worden via internetgebaseerde protocols. Er zijn veel varianten op deze definitie gekend. Een zeer algemene definitie spreekt over een web service als een component van een softwareapplicatie die toegankelijk is d.m.v. open protocols. Toch kunnen we wanneer we over een web service spreken enkele gemeenschappelijke kenmerken herkennen die net het begrip web service karakteriseren. De volgende lijst somt bovendien ook al enkele voordelen van het gebruik van web services op. • Een web service is opgebouwd uit standaard internet communicatieprotocols. De bestaande protocols XML, HTTP, TCP/IP worden hier ingezet in de basislagen van de protocolstack. Het gebruik hiervan garandeert een platformonafhankelijkheid. De gemeenschappelijke standaarden SOAP, WSDL, UDDI, .. geven de web service vorm. Door verder te bouwen op deze standaarden is er een lagere barri`ere voor de integratie van applicaties. Deze belofte werd vroeger ook reeds gemaakt door COM en CORBA maar de complexiteit om dit mogelijk te maken vormde toen de grote struikelblok. De eenvoud van de SOAPspecificatie biedt een nieuwe mogelijkheid tot data interactie. Het succes van web services vloeit bovendien voort uit het bouwen op de bestaande standaarden. • Een web service is onafhankelijk van het besturingssyteem en de programmeertaal. • Een web service beschrijft zichzelf in een zogenaamd Web Services Description Language (WSDL) document. Het is een manier om de interfaces en hun functionaliteit te beschrijven om zodoende gebruikers toe te laten de web services te gebruiken. • Een web service is lokaliseerbaar. Ze is geregistreerd zodat gebruikers deze op een eenvoudige manier kunnen terugvinden. Dit gebeurt door Universal Discovery Description and Integration (UDDI).
2.3 Web service architectuur
2.3
5
Web service architectuur
Hoewel deze architectuur[2, 3, 4] verschillend is van de web architectuur worden zowel enkele voordelen als tekortkomingen overge¨erfd. De modulaire opbouw zorgt dat de complexiteit van de verschillende specificaties beheersbaar is en gereduceerd wordt waardoor een hoge uitbreidbaarheid voor geavanceerde web services wordt verkregen.
Figuur 2.1: Modulaire opbouw van een web service
2.3.1
eXtensible Markup Language
De eXtensible Markup Language (XML) is een eenvoudige en flexibele tekstgebaseerde syntax. Deze hi¨erarchische gestructureerde syntax biedt een gestandaardiseerde manier voor dataopslag. Initieel werd het formaat ontwikkeld om een antwoord te bieden op de uitdaging om een elektronisch dataformaat te ontwikkelen dat op grote schaal toepasbaar is. Het formaat wint sterk aan belang binnen webapplicaties en toepassingen voor datauitwisseling omdat de opbouw en structuur van XML het formaat immers bijzonder toegankelijk en leesbaar maakt voor zowel toepassingen als personen. XML wordt bij web services gebruikt als berichtenformaat maar ook om de service zelf te beschrijven (zie SOAP en WSDL). Voordelen van XML • Eenvoudig: Talrijke tools en parsers laten het toe om XML op een eenvoudige manier te lezen en te bewerken.
2.3 Web service architectuur
6
• Leesbaar : Daar XML een tekstformaat is, is het formaat eenvoudig leesbaar door middel van een eenvoudige webbrowser. • Standaard : Misschien wel het belangrijkste voordeel is het gebruik van de standaard ’XML’. Het gestandaardiseerde formaat zorgt dat de data onafhankelijk van platform, besturingssysteem of programmeertaal is. Het maakt XML het uitgelezen formaat voor datacommunicatie. Een XML Schema kan de structuur van een bericht abstract beschrijven en kan ook ingezet worden voor validatie van het XML-document. Het XML Schema beschrijft o.a. welke elementen en attributen aanwezig kunnen of moeten zijn, de volgorde van de elementen, de hoeveelheid, de datatypes en de namespace.
2.3.2
Simple Object Access Protocol
Simple Object Access Protocol (SOAP) is een eenvoudig XML-gebaseerd protocol voor de informatieuitwisseling in een gedistribueerde omgeving. SOAP is de specificatie die het XML-formaat voor de berichten definieert [3, 4]. Een SOAP-bericht bestaat uit drie delen: SOAP-envelope, data encoding rules en RPC conventies. De SOAP-specificatie is standaard een request/response patroon voor berichtenuitwisseling. • De <Envelope> definieert een framework voor de beschrijving van de inhoud, de structuur van een bericht en hoe het bericht kan verwerkt worden. De <Envelope> bestaat uit een optionele
en een verplicht -element. • De van een SOAP-bericht kan bijkomende metadata bevatten over hoe het bericht kan verwerkt worden dat door de eindpunten kan bekeken worden. De header kan implementatiedetails bevatten voor SOAP-uitbreidingen (zie verder WSE). • De bevat het eigenlijke databericht. Dit element kan ook gebruikt worden om informatie over fouten door te geven via geneste elementen. <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Header> Optioneel, bevat informatie wat het SOAP-bericht bevat en hoe het te verwerken.
2.3 Web service architectuur
7
<soap:Body> De Soap-body bevat XML-data SOAP is platformonafhankelijk en onafhankelijk van de programmeertaal. Een courante SOAPimplementatie bevat een binding met HTTP omdat dit door alle huidige besturingssystemen ondersteund wordt. SOAP onderstelt dat beveiligd transport een zaak is van het transportprotocol. Door de modulariteit kan security evenwel worden voorzien als een blok bovenop de architectuur en zo kan de specificatie zijn eenvoud behouden.
2.3.3
Web Services Description Language
De Web Services Description Language (WSDL) is een XML formaat om netwerkservices te beschrijven als een set eindpunten die opereren op berichten die documentof proceduregeori¨enteerde informatie bevatten. De operaties en berichten zijn abstract beschreven en worden dan gebonden aan een concreet netwerkprotocol en een berichtenformaat om de eindpunten te defini¨eren [1]. Een WSDL-file legt de XML-beschrijving van een set van SOAP-berichten vast en bevat hoe de berichtenuitwisseling verloopt. Deze WSDL-file vormt de interface van de service en beschrijft welke interacties mogelijk zijn en hoe de in- en uitvoer van de functies er uit ziet. Een WSDL-document beschrijft Data type definities, Message formats, Port types, Bindings, Ports en Service. Om dit wat te verduidelijken bekijken we enkele constructies die de web service defini¨eren. De abstracte interfacedefinitie wordt beschreven door de elementen interface, message, types die een platform onafhankelijke beschrijving bieden.
De concrete implementatie-informatie
wordt beschreven door de elementen service, binding, endpoint [2]. • interface (eerder portType) Een web service wordt voorgesteld door een interface element. Dit bevat een reeks logische operaties op deze web service. • operation Dit element bestaat uit een set van input- en ouputberichten. Het stelt een functie van de service voor.
2.4 Uitgebreide web services architectuur
8
• message Dit zijn de operatie-berichten. Ze kunnen meerdere parameters (part) bevatten die de inkomende en uitgaande parameters voorstellen. • service Dit element stelt een of meer eindpunten voor waarop de service toegankelijk is. Ze bevat de elementen endpoint (vroeger port). • binding Protocol en berichtenformaat worden aan de operaties gebonden.
2.3.4
Universal Description, Discovery, and Integration
Universal Description, Discovery, and Integration of UDDI[3] is een soort telefoonboek voor web services. Een UDDI directory entry is een XML-file die een web service beschrijft (wat + hoe te gebruiken). UDDI verzamelt de metadata. Er zijn 3 delen voor zo’n entry. • De ’witte pagina’s’ beschrijven het bedrijf dat de service levert door zijn naam, adres, contactinfo, .. • De ’gele pagina’s’ bevatten de industri¨ele categorie. • De ’groene pagina’s’ geven een gedetailleerde beschrijving voor de interface van de service. Door middel van UDDI kan men de service terugvinden.
2.4
Uitgebreide web services architectuur
De eenvoud van SOAP kan uitgebreid worden door enkele specificaties. We bekijken Web Services Enhancements en BPEL4WS als mogelijke uitbreidingen van de web services architectuur.
2.4.1
Web Services Enhancements
De functionaliteit van web services kan uitgebreid worden door toevoeging van een aantal specificaties. De modulariteit van de web service architectuur laat ons toe nieuwe specificaties toe te voegen en biedt bovendien een transparante ontwikkeling van de service. Enkel de specifieke
2.4 Uitgebreide web services architectuur
9
uitbreidingen dienen te worden toegevoegd waardoor men niet met de complexiteit van een grote specificatie moet handelen. Het .NET Framework ondersteunt Web Services Enhancements (WSE), een verzameling klassen en filters die nieuwe protocols implementeren en inkomende en uitgaande SOAP-berichten onderscheppen, interpreteren en de SOAP-header aanpassen om de functionele uitbreidingen te bieden. Deze uitbreidingen omvatten vooral security, betrouwbaar transport, transacties, routing, ... Deze werden zoals we eerder aangaven niet in de initi¨ele eenvoudige SOAP-specificatie opgenomen. We geven een beknopt overzicht van enkele specificaties die door WSE 2.0 ondersteund worden.
WS-Security De WS-Security specificatie biedt encryptie-mogelijkheden in het SOAP-bericht. Het laat encrypteren en digitaal ondertekenen van een bericht toe. WS-SecurityConversation breidt deze specificatie uit door beveiligde communicatie en interactie. WS-Trust is een andere uitbreiding van WS-Security die security-elementen in een bericht valideert.
WS-Policy WS-Policy zorgt ervoor dat de WSDL-specificatie wordt uitgebreid met de nodige voorzieningen voor WSE-specificaties. De specificatie maakt een aanduiding wat er van de oproeper verwacht wordt.
WS-Adressing WS-Adressing biedt een manier om zenders en ontvangers van berichten te identificeren. De specificatie zorgt ervoor dat de afzender en bestemmeling van een bericht en andere adresinformatie in het bericht wordt opgenomen. Wanneer deze niet in het bericht worden opgenomen dan kan deze informatie immers verloren gaan door een connectie time-out bijvoorbeeld. De adresinformatie wordt losgekoppeld van het transport.
WS-Referral WS-Referral specifieert een methode om requests door te zenden naar andere web services met behoud van de oorspronkelijke informatie in de SOAP-header.
2.5 Integratie via web services
10
WS-Attachment WS-Attachment specifieert hoe Direct Internet Message Encapsulation (DIME) berichten via SOAP kunnen worden gezonden.
WS-Coordination WS-Coordination specifieert hoe acties kunnen geco¨ordineerd worden tussen verschillende gedistribueerde applicaties. Het is zo ook mogelijk om transactionele processen te gebruiken.
2.4.2
BPEL4WS
De Business Process Execution Language for Web Services (BPEL4WS) biedt een syntax om de workflow van business processen te beschrijven. Een BPEL4WS-document beschrijft de volgorde waarin de services worden gebruikt. Het WSDL-bestand dat interfaces bevat van de service stelt het BPEL4WS-proces voor. De servicedefinitie voor BPEL4WS is implementatieonafhankelijk en in het WSDL-bestand is geen binding opgenomen [5].
2.5
Integratie via web services
Het modelleren van een web service waarin een bedrijfsproces gevat wordt is geen alleenstaand blok functionaliteit. Vaak is een interactie met diverse web services noodzakelijk om de volledige logica en workflow van een bedrijfsproces te ontwikkelen. Hierbij is een geco¨ordineerde uitwisseling van berichten een noodzaak. De interacties worden hier beheerd door een orchestration engine. Orchestration beschrijft hoe web services met elkaar kunnen interageren door middel van berichten inclusief de bedrijfslogica en uitvoeringsvolgorde van de interacties [6]. Er zijn interacties tussen een service, die de beheerder is, en enkele uitvoerende services. BPEL4WS is zo’n beheerder.
Deze beschrijving kan een aantal regels, condities bevatten voor de diverse services waartussen interacties mogelijk zijn.
2.6 .NET
2.6
11
.NET
2.6.1
Ontwikkelen van een web service
De System.Web.Services namespace bevat de functionaliteit om een web service te ontwikkelen. Dit omvat de WebService klasse, het attribuut WebService en het attribuut WebMethod. In Visual Studio .NET kan een web service gecre¨eerd worden door het attribuut WebService toe te voegen aan de klasse die de web service implementeert. Het attribuut WebMethod wordt toegevoegd aan de publieke methodes die als web service methodes zullen worden gebruikt. Als voorbeeld bekijken we de klassieke ’Hello World’-web service. In de clientapplicatie die deze web service gebruikt, kunnen we in Visual Studio de service als een webreferentie toevoegen.
using System; using System.Web; using System.Web.Services;
namespace Voorbeeld { [WebService] public class Service { [WebMethod] public string HelloWorld() { return "Hello World"; } } }
2.6.2
Serialisatie
SOAP laat toe om complexe berichten uit te wisselen als input, outputparameters of als returnwaarde. Om dit te bewerkstelligen worden de datastructuren op zich geserialiseerd in een ander formaat. Het SOAP-serialisatieproces zal een omzetting doen naar XML en het geserialiseerde formaat wordt over het netwerk gezonden d.m.v. SOAP. De ontvanger doet een deserialisatie en reconstrueert de verzonden datastructuur. Serialisatie kan enkel bij de publieke
2.6 .NET
12
velden en eigenschappen van een klasse en de klasse moet een defaultconstructor hebben. Om de serialisatie in te schakelen wordt System.Xml.Serialization namespace, of een eigen serialisatiemechanisme, gedefinieerd door de implementatie van de ISerializable interface van de System.Runtime.Serialization namespace.
2.6.3
Proxy
.NET voorziet een proxy klasse die de complexiteit van het gebruik van SOAP verbergt en een eenvoudige interface biedt, gebaseerd op de methoden van de web service. Op die manier hoeft men de SOAP-berichten niet te manipuleren maar kan men via de proxy de functionaliteit van de service gebruiken. Het aanmaken van de proxy gebeurt op basis van de WSDL-file. De clientapplicatie kan de webmethoden aanroepen door de equivalente methoden van de proxy te gebruiken. De proxy zet dan de lokale aanroepen om in een SOAP-request en zendt deze naar de web service. De proxy wacht op een antwoord, deserialiseert de data en geeft het terug aan de client.
2.6.4
Levensloop van een web service
Deze figuur[7] geeft een overzicht van de levensloop van een web service.
Figuur 2.2: Een cyclus van een web service
2.6 .NET
13
1. Creatie van een web service als een .NET klasse met de nodige methoden en functionaliteit. 2. Automatisch wordt in .NET een WSDL-document aangemaakt. 3. De client die de service wil gebruiken, voegt in Visual Studio .NET een webreferentie toe. 4. Automatisch genereert .NET een proxy klasse op basis van het WSDL-document. Deze klasse laat de communicatie toe met de web service. 5. De client roept ´e´en van de webmethoden op. Hoewel de client lijkt te communiceren met een gewone .NET klasse, wordt eigenlijk de proxy gebruikt. 6. De proxy zet de aanroep om in een SOAP-bericht en verstuurt dat bericht naar de web service. 7. De proxy ontvangt het antwoord van de web service en zet het terug om zodat het kan geretourneerd worden aan de client. 8. De client gebruikt de geretourneerde informatie.
2.6.5
Asynchrone web services
Voor grote berichten die veel tijd in beslag nemen is het nuttig asynchrone web services te gebruiken. We dienen een onderscheid te maken tussen synchrone en asynchrone web services. Asynchroon werken verhoogt de performantie van de applicatie. Men spreekt van asychroon wanneer threads worden gebruikt die de normale uitvoering niet blokkeren wanneer bijvoorbeeld moet gewacht worden op toegang tot een bestand, netwerk, ... Bij web services hebben we een asynchroon berichtenpatroon: berichten worden verzonden maar er is geen onmiddellijke reactie op dit bericht. Om asynchroon te werken roept men in plaats van de methode aan met bvb. MethodName, de methode aan met BeginMethodName. Dit geeft ons een IAsyncResult object terug. Op het einde van de methode roept men EndMethodName aan met het AsyncResult object. Deze methode geeft dan de vereiste data terug van de methode zoals bij een synchroon behandelen van deze webmethode [2].
2.7 Windows Service
2.6.6
14
Gebruik van WSE
Om Web Services Enhancements (WSE) te gebruiken moet men een referentie maken naar Microsoft.Web.Services.dll. Hierbij spoort men Visual Studio .NET aan om Microsoft.Web.Services.ClientProtocol te gebruiken in plaats van System.Web.Services.Protocols.SoapHttpClientProtocol als basisklasse bij de generatie van de proxy klasse. Om bijkomende informatie i.v.m. de verschillende WS-specificaties toe te voegen maakt men gebruik van de property SoapContext. Door middel van deze klasse kan men de verstuurde en ontvangen berichten lezen en aanpassen met extra informatie.
2.7
Windows Service
Windows services laten ons toe een periodische taak uit te voeren. Ze vormen een proces dat op de achtergrond loopt, naast andere processen. Nadat de windows service-applicatie ontwikkeld is, kan de service gestart worden via de command-line tool InstallUtil.exe en het path van de service. In het administratiebeheer (Services control manager) kan de service gestart, gestopt, gepauzeerd, herstart of geconfigureerd worden. Om de methode te starten roept men de OnStart methode aan van de service. Analoog is er een methode OnStop voorzien om de service te stoppen.
CASE STUDY
15
Hoofdstuk 3
Case Study Gedurende de laatste decennia vindt een snelle informatisering plaats in de medische sector. Medische informatiesystemen en elektronisch pati¨entenbeheer worden ge¨ıntroduceerd om een effici¨entere informatiedoorstroming te verzekeren en om de kwaliteit van de geneeskundige zorgen nog te verbeteren. Het aanwenden van nieuwe informaticamiddelen zorgt voor diverse probleemstellingen m.b.t. de integratie en ontwikkeling van de verschillende eHealth diensten in de bestaande omgeving. In dit hoofdstuk bekijken we eHealth services bij het optimaliseren van de administratieve of financi¨ele zaken. Verder bouwen we de noodzakelijke terminologie op voor de verdere hoofdstukken.
3.1
Wat is eHealth?
eHealth is een moeilijk te defini¨eren term. Een universele consensus over de definitie van de term ’eHealth’ blijkt immers niet te bestaan waardoor de precieze betekenis varieert naargelang de gebruikerscontext met invalshoeken uit de gezondheidszorg, uit technologische vernieuwingen, en uit commerci¨ele activiteiten [8]. Gunther Eysenbach[9] geeft de volgende definitie: eHealth is een groeiend gebied in het snijpunt van de medische informatica, publieke gezondheidszorg en zakenwereld, verwijzend naar health services en overdracht en uitwisseling van informatie over het Internet en aanverwante technologie¨en. In bredere zin, karakteriseert de term niet alleen de technische omgeving maar ook een manier van denken, een attitude, en een bijdrage voor een gerelateerd, wereldwijd denken om
3.2 Case Study IZ, UZ Gent
16
de gezondheidszorg lokaal, regionaal en wereldwijd te verbeteren door informatie- en communicatietechnologie te gebruiken. De ’e’ in eHealth benadrukt volgens Eysenbach niet alleen ’electronic Health’ maar bovenal een effici¨ente, kwaliteitsvolle, ethische, en democratische gezondheidszorg. Een gelijklopende definitie vinden we bij de Information Society van de Europese Commissie[10]: eHealth verwijst naar het gebruik van moderne informatie- en communicatietechnologie om de noden van zowel burgers, pati¨enten, mensen uit de gezondheidszorg als beleidsmakers te ondersteunen. eHealth beslaat dus een hele reeks applicaties gaande van medische systemen tot administratieve applicaties in de gezondheidssector, welke een vereenvoudiging en verbetering van de interacties in de sector bewerkstelligen.
3.2 3.2.1
Case Study IZ, UZ Gent IZ InformatieSysteem
De dienst Intensieve Zorgen (IZ) van het Universitair Ziekenhuis in Gent gebruikt een systeem ’IZIS’ dat alle pati¨entengegevens registreert. IZIS staat voor Intensieve Zorgen Informatie Systeem en bestaat uit de software ’Deio Clinisoft for Critical Care’. Het verplegend personeel kan observaties en toegediende prestaties registreren via een computer aan het bed van de pati¨ent. Artsen kunnen hun orders ook in het systeem inbrengen. Het informatiesysteem laat toe om ingebrachte gegevens op te vragen om een beter zicht te krijgen op de evolutie van de pati¨ent.
3.2.2
Technische omgeving
Het IZIS systeem is gebaseerd op de principes van een Client-Server Architectuur [11]. Aan het bed van de pati¨ent bevindt zich een client-PC die via het ziekenhuisnetwerk verbonden is met een server. Een ethernetbox verbindt de computer-monitor, ventilator en spuitpompen aan het bed met het ziekenhuisnetwerk. Een switch verdeelt alle gegevens van de dienst over de juiste servers. Zo blijft het informatiesysteem afgescheiden van andere data en van andere afdelingen. De data afkomstig via een draadloze verbinding wordt door een firewall gestuurd. De computers kunnen zowel in LAN als in WLAN-modus gebruikt worden. Er zijn drie servers
3.2 Case Study IZ, UZ Gent
17
Figuur 3.1: Technische omgeving IZIS
in het systeem aanwezig nl. de warehouseserver, de productieserver en de communicatieserver. De productieserver bevat alle gegevens van alle opgenomen en recent ontslagen pati¨enten (max. 3 dagen na ontslag). De warehouseserver bevat alle gegevens van reeds ontslagen pati¨enten. Beide servers zijn in een cluster geschakeld en maken gebruik van dezelfde productiedatabank. De communicatieserver zorgt voor communicatie met externe servers. Enkele technische gegevens[11]: • Client (bedside-PC en office-PC) De client is een IBM NETVISTA Pentium 4, Processor 2.0 - 2.6 Ghz met 512 MB RAM geheugen, een ethernetkaart, WLAN-kaart. De computer beschikt over een 17Inch scherm, CD-ROM, 3.5 Inch diskette. Het besturingssysteem op de client is Microsoft Windows 2000 Professional. Verder werden ook antivirus- en IZIS-software ge¨ınstalleerd. • Servers Elke server is een IBM xSeries 235, 2x Xeon 2,4 Ghz met 4 GB RAM geheugen en 4x 36,4GB RAID1, een Hot Spare. De server draait op Microsoft Windows 2000 Server en bevat de databank en de software Sybase SW en antivirussoftware.
3.3 Probleemstelling
3.2.3
18
Definities
Voor een goed begrip belichten we kort enkele veelgebruikte termen uit de medische administratie. • IZIS - Het Intensieve Zorgen Informatie Systeem is het centrale informatiesysteem dat de pati¨entendossiers en de geleverde prestaties bevat. • Medisch Technische Prestatie - Dit verwijst naar de prestatiedienst die aan een pati¨ent wordt verleend. • Tarificatieformulier - Dit formulier bestaat uit een tabel met alle medische prestaties en het bijbehorende aantal geleverde prestaties aan de pati¨ent. Het formulier wordt per dag en per pati¨ent bijgehouden en vormt zo een beschrijving van de te factureren verstrekkingen. • RIZIV-regel - Het RIZIV of ’Rijksinstituut voor ziekte- en invaliditeitsverzekering’ legt ziekenhuizen bepaalde regels op inzake terugbetaling en tarificatie van bepaalde diensten. • MPFLOP - Het gegevensformaat dat aan de financi¨ele administratiedienst wordt doorgestuurd wordt ’MPFLOP’ genoemd.
3.3
Probleemstelling
Figuur 3.2: Probleemstelling
Momenteel worden de medische data over pati¨enten verzameld en verwerkt d.m.v. het eigen medisch platform, het Intensieve Zorgen Informatie Systeem. De financi¨ele dienst van het UZ
3.4 Doelstelling
19
gebruikt echter een ander platform. Wanneer een medische prestatie verstrekt wordt, wordt dit momenteel enerzijds geregistreerd in de IZIS-databank maar anderzijds is ook een manuele aanduiding nodig op een papieren tarificatieformulier. Dit tarificatieformulier dat per pati¨ent en per dag ingevuld wordt, wordt nu doorgegeven aan de administratie-eenheid binnen de dienst Intensieve Zorgen. Daar worden de quotaties op het formulier ingebracht en geconverteerd in een programma waarbij manueel diverse RIZIV-regels en facturatieregels toegepast worden. De administratie-eenheid levert dan een bestand ’MPFLOP’ aan de financi¨ele dienst. Dit huidige facturatieproces is zeer arbeidsintensief en tijdrovend.
3.4
Doelstelling
Figuur 3.3: Doelstelling
Het huidige facturatieproces maakt momenteel geen gebruik van de IZIS-databank waarin de prestaties ook reeds geregistreerd zijn. Onze doelstelling is om deze databank in te zetten in het facturatieproces zodat de tarificatieformulieren in elektronische vorm automatisch kunnen opgebouwd worden per dag en per pati¨ent. Dit vereist een consultatie van de databank en manipulaties op een consistent gegevensformaat voor de tarificatieformulieren. Het formulier dient op eenzelfde manier bewerkt te worden als de handelingen die manueel door de secretaresse gebeuren op de ingevoerde formulieren. Deze acties bestaan o.a. uit het toepassen van RIZIV-regels en het koppelen van artsen aan geleverde prestaties. Deze know-how van het administratief personeel zal in de diensten van de applicatie gevat worden. De elektronische diensten en de fysische administratie-eenheden zullen gekoppeld worden door middel van web services. We bestuderen dus manieren om het huidige facturatieproces te informatiseren teneinde een automatische ge-
3.4 Doelstelling
20
neratie van de formulieren en MPFLOP-formaat (voor de financi¨ele dienst) mogelijk te maken. We kunnen onze doelstelling beknopt omschrijven:
Door het ontwerpen van een applicatie die via web services een koppeling cre¨eert tussen het platform van de dienst Intensieve Zorgen (IZ) en de administratiedienst van het UZ zal de facturatie van geleverde medisch technische prestaties geautomatiseerd worden.
SPECIFICATIE
21
Hoofdstuk 4
Specificatie 4.1
Overzicht
In dit hoofdstuk wordt het tarificatiesysteem bekeken vanuit het standpunt van de administratiebeheerder. We analyseren hier de use cases die de extern zichtbare werking en het gedrag van het systeem of hun componenten beschrijven. De automatisatie van de tarificatie be¨ınvloedt sterk de use cases. Afzonderlijke softwaremodules en bijbehorende services worden intern opgeroepen vanuit een monitorapplicatie. Deze monitor gedraagt zich als een systeemactor bij het opbouwen van een elektronische versie van het tarificatieformulier, dat dient tot het factureren van de medisch technische prestaties. De systeemactor verzorgt de interactie met de services, die instaan voor de pati¨entendata, de RIZIV-regels, artseninformatie, ... Daarnaast is er ook een humane actor, de administatiebeheerder, die een controle wenst op het tarificatieformulier. De beheerder wenst ook het systeem dynamisch te updaten met RIZIV-regels, beschikbare artsen, prestaties en andere systeemconfiguratieparameters.
4.2 4.2.1
Use Cases Monitorsysteem
Het systeem start ´e´enmaal per dag automatisch de triggering op gewijzigde pati¨entendata aanwezig in de database van het IZIS-systeem.
4.2 Use Cases
22
Het IZIS-systeem bevat de medisch technische prestaties die aan elke pati¨ent verleend zijn. De monitor zal een tarificatieformulier genereren. Dit formulier wordt na controle en filtering op basis van RIZIV-regels, die men opvraagt en toepast, in een MPFLOP omgezet. De kerntaken van het monitorsysteem zelf zijn : • Opvragen van pati¨entendata uit de database door triggering. • Laten toepassen en opbouwen van het tarificatieformulier a.d.h.v. de verworven data en de configuratieparameters. • Omzetten van de tarificatieformulieren in een MPFLOP-bestand.
Figuur 4.1: Use case - Monitor als systeemactor
Opvragen van pati¨ entendata d.m.v. triggering In de eerste fase zoekt men naar: • Nieuwe pati¨enten, • Ontslagen pati¨enten, • Langdurig verblijvende pati¨enten.
4.2 Use Cases
23
Nieuwe pati¨ enten: Als het proces een nieuwe pati¨ent vindt, dan wordt deze samen met de opnamedatum en het opnameuur in het monitorsysteem opgenomen. Ontslagen pati¨ enten: Als het proces een recent ontslagen pati¨ent terugvindt, dan start het proces voor de generatie van tarificatieformulieren. Na dit proces wordt de pati¨ent verwijderd uit het monitorsysteem. Langdurig verblijvende pati¨ enten: Bij langdurig verblijvende pati¨enten wordt een tussentijdse facturatie aangemaakt. De laatste facturatiedatum van de pati¨ent wordt dan aangepast in het monitorsysteem.
Facturatie en opbouw van het tarificatieformulier Bij de facturatie van de medisch technische prestaties wordt er per pati¨ent per dag een tarificatieformulier opgemaakt. Alle gegenereerde tarificatieformulieren worden opgeslagen om latere opvragingen mogelijk te houden.
Omzetten van de tarificatieformulieren in een MPFLOP-bestand Bij de omzetting van de tarificatieformulieren worden de medisch technische prestaties gekoppeld aan een IZ arts. Deze koppeling gebeurt op basis van de werklast en de beschikbaarheid van iedere arts. Er wordt rekening gehouden met de functie van de arts en er wordt gezorgd voor een ongeveer gelijke verdeling van de geleverde arbeidsprestaties. Daarna worden er een aantal RIZIV-regels toegepast om uiteindelijk het MPFLOP-bestand te genereren.
4.2.2
Administratiebeheerder
Het gehele tarificatieproces moet natuurlijk kunnen beheerd worden voor o.a. het opsporen van mogelijke fouten. De beheerder zal volgende taken willen uitvoeren: • Opvragen en eventueel aanpassen van het tarificatieformulier. • Instellen van de verlofperioden van de artsen. • Veranderen van configuratieparameters. • Toevoegen en verwijderen van RIZIV-regels. • Toevoegen van medisch technische prestaties.
4.2 Use Cases
24
Figuur 4.2: Use case - Administratief beheerder IZ
Opvragen en eventueel aanpassen van het tarificatieformulier De administratief beheerder wil kunnen controleren of de automatische generatie van het tarificatieformulier op een correcte manier is verlopen. Men onderstelt dat het mogelijk is om de formulieren op te vragen en eventueel te wijzigen vooraleer ze via regels worden omgezet in het MPFLOP-formaat. Wanneer het proces stabiel loopt, kan van deze bevestigings- of controlemodus overgeschakeld worden naar een gehele automatische generatie van de MPFLOP zonder deze tussenstap. De tarificatieformulieren worden hierbij in het systeem opgeslagen om een latere opvraging toe te laten. Precondities: - De data moeten opgehaald zijn uit het IZIS-systeem en een tarificatieformulier is gegenereerd. (De systeemactor heeft zijn taak vervuld.)
4.2 Use Cases
25
Postcondities: - Wanneer het formulier bevestigd wordt, wordt dit omgezet in een MPFLOP-bestand.
Instellen van de verlofperiode van een arts Voor de koppeling aan medisch technische prestaties moet de beschikbaarheid van de arts gekend zijn. Met deze functie kan men de verlofperiode van elke arts manueel instellen. Deze functie kan eventueel in een latere fase geautomatiseerd worden. Preconditie: - De arts is in het systeem opgenomen. Postconditie: - De beschikbaarheid van de arts is bepaald.
Configuratie van diverse parameters De beheerder kan enkele systeemeigen parameters wijzigen die het tarificatieproces onmiddellijk be¨ınvloeden o.a. - het triggeringstijdstip - de facturatieperiode voor langdurig verblijvende pati¨enten - timeshift
Toevoegen en verwijderen van RIZIV-regels De evoluties in de wetgeving op de medische prestaties verplichten de beheerder tot het instellen en wijzigen van de beschikbare RIZIV-regels.
Toevoegen van medisch technische prestaties Door de continue verandering in de medische sector, worden er steeds nieuwe medische technieken ontwikkeld. In dat kader moet er dus een mogelijkheid zijn om nieuwe prestaties toe te voegen. Het verwijderen van prestaties is niet aangeraden voor het behoud van de achterwaartse compatibiliteit.
4.3 Sequentieschema’s
4.3
26
Sequentieschema’s
Deze schema’s verduidelijken het gedrag van het monitorsysteem bij het genereren van tarificatieformulieren en bij het genereren van een MPFLOP-bestand.
Figuur 4.3: Sequentieschema van het ophalen van de data
4.3 Sequentieschema’s
27
Figuur 4.4: Sequentieschema van de opbouw van een tarificatieformulier
Figuur 4.5: Sequentieschema van de MPFLOP
ARCHITECTUUR
28
Hoofdstuk 5
Architectuur Een architectuur omvat niet alleen richtlijnen en principes voor de ontwikkeling van een toepassing maar is tevens een abstractie van de werkelijkheid. Het omhelst een hele visie van hoe de toepassing op langere termijn kan ingezet worden om de nodige functionele als niet-functionele vereisten te ondersteunen. In dit hoofdstuk onderzoeken we de visie die schuilt in de servicegebaseerde architectuur. We bekijken de principes en vergelijken ze met de traditionele aanpak van objectori¨entatie. Verder bouwen we een architectuur voor de eHealth facturatietoepassing.
5.1
Een servicegebaseerde architectuur
De servicegebaseerde architectuur (of Service Oriented Architecture, kortweg SOA) vindt zijn oorsprong in de begrippen autonomie en integratie. Het zijn eigenlijk tegengestelde begrippen die aan de basis liggen van serviceori¨entatie.
5.1.1
Definitie
Het World Wide Web Consortium (W3C) [1] omschrijft een servicegebaseerde architectuur als Een set componenten die kunnen worden aangeroepen en wiens interfacebeschrijvingen kunnen gepubliceerd worden en kunnen opgezocht worden. We dienen echter waakzaam te zijn voor enige verwarring met betrekking tot serviceori¨entatie. Een applicatie die web services gebruikt kan immers niet zomaar bestempeld worden als zijnde
5.1 Een servicegebaseerde architectuur
29
een servicegebaseerde architectuur [5]. Vanuit technisch opzicht, de implementatie van de architectuur, kunnen we spreken over een gestandaardiseerde architectuur waarbij XML en web services worden gebruikt. Dit kan niet tijdens het defini¨eren op zich van de servicegebaseerde architectuur! Het is evenwel zo dat wanneer de SOA wordt ingezet de ontwerpprincipes van web services deel zullen uitmaken van de uiteindelijke technische omgeving.
5.1.2
Principes
Een servicegebaseerde architectuur heeft volgende basisprincipes: • De grenzen van de services zijn expliciet Enkel de functionaliteit is bereikbaar via de services. Er is slechts een enkele manier om functionaliteit en informatie aan te roepen door de grenzen van de services (welke in de interfaces zichtbaar gemaakt worden). Dit principe verwoordt ook dat een service een welbepaald gebied dient te omvatten en een duidelijke interface moet hebben. Deze grenzen moeten expliciet zijn omdat het overschrijden van zo’n grens een impact heeft op zowel prestaties als schaalbaarheid van de toepassing. • De services zijn autonoom Elke service heeft zijn eigen verantwoordelijkheid. Een service staat op zichzelf en heeft geen afhankelijkheden met andere services. Dit betekent dat wanneer een andere service plots onbereikbaar wordt, deze service onafhankelijk kan verderwerken zonder daarbij verstoord te worden door het falen van een andere service. Dit principe bekrachtigt de losse koppeling van bvb. web services. De autonomie van de services moet ook een makkelijker opvangen van wijzigingen in een service mogelijk maken. • Deel schema’s en contracten, niet klassen De interfaces van de services moeten via begrijpbare schema’s en structuren aanwezig zijn. De schema’s beschrijven de structuur en het berichtenformaat. Het contract beschrijft een berichtenuitwisseling tussen services door hun interacties. Integratie is hier gebaseerd op het delen van schema’s en contracten in plaats van het delen van objecten. Het gebruik van standaarden moet de interoperabiliteit bewerkstelligen. • Compatibiliteit gebaseerd op een policy Compatibiliteit dient gebaseerd te zijn op basis van een vastgelegde policy of beleidsverkla-
5.2 Serviceori¨entatie en objectori¨entatie
30
ring. Elke service maakt zijn mogelijkheden en eisen bekend onder de vorm van een policy. Ze bevatten de garanties en condities waaraan moet voldaan zijn om de service normaal te kunnen uitvoeren. Dit kan mogelijkheden bieden om bvb. encryptie van berichten af te spreken of de levensduur van een bericht onderling vast te leggen.
5.2
Serviceori¨ entatie en objectori¨ entatie
Het abstractieniveau van een architectuur bevat modules, objecten of componenten. Vandaag kunnen we aan deze reeks het begrip ’service’ toevoegen. Er zijn dan ook verschillende links te trekken met het objectgeori¨enteerde paradigma en de componentgebaseerde ontwikkelingen. Net als een object of een component vormt een service een basisblok dat gedrag als toestand modelleert. Wanneer we serviceori¨entatie vergelijken met objectori¨entatie kunnen we nog een aantal equivalente principes ontdekken [12]. In dit opzicht wensen we wel te vermelden dat serviceori¨entatie de objectori¨entatie niet vervangt! Integendeel, serviceori¨entatie en objectori¨entatie zijn complementair.
Decompositie Bij het opstellen van de architectuur splitsen we een groot probleem op in een aantal kleinere problemen, waarvoor we een oplossing vinden die ge¨ıntegreerd wordt tot een groter geheel. Deze ’decompositie’ wordt ook bij serviceori¨entatie uitgevoerd, rekening houdend met de SOA-eisen en principes.
Herbruikbaarheid en interfaces Bij objectori¨entatie is er een decompositie in modules die we verder kunnen vormen door een aantal objecten. Er wordt gebruik gemaakt van herbruikbaarheid op klasseniveau waarbij de interface een abstractie vormt van de functionaliteit. Net als in de objectori¨entatie herbergt de service ook het concept ’information hiding’ waarbij interne informatie wordt afgeschermd en de service een interface heeft. Bij services is de interface een WSDL-document dat een beschrijving van de service bevat.
Losse koppeling Een vereiste van serviceori¨entatie is een losse koppeling. Het gebruik van overerving en uitbrei-
5.2 Serviceori¨entatie en objectori¨entatie
31
ding vormt bij objectori¨entatie een meer vaste koppeling.
Compositie Objectori¨entatie bevat aggregatie en compositie van objecten. Bij serviceori¨entatie kennen we ook compositie van services.
Autonomie Autonomie is zeer belangrijk bij serviceori¨entatie. Door een losse koppeling tussen services kan dit bewerkstelligd worden. Objectori¨entatie bevat veel meer overervingsrelaties en referenties waardoor een lagere autonomie verkregen wordt in vergelijking met serviceori¨entatie.
Toestand Objectori¨entatie is toestandsbehoudend. Hoewel serviceori¨entatie zowel toestandsbehoudend als toestandsloos kan zijn, is ze meer algemeen toestandsloos. Er wordt geen toestand bijgehouden.
Vindbaarheid Objectori¨entatie is zelf beschrijvend. Bij serviceori¨entatie kunnen de services beschreven zijn zodat men op basis van een soort register de services kan gaan opzoeken.
5.2.1
Vergelijking en parallellen
Uit deze vergelijking en uit de principes blijkt dat serviceori¨entatie de beste karakteristieken van zowel objectori¨entatie als web services (uit hoofdstuk 2) samenneemt. Serviceori¨entatie betekent zeker niet dat alles van objectori¨entatie overboord wordt gegooid!
5.3 Globale architectuur
32
Vergelijking objectori¨entatie en serviceori¨entatie Begrip
OO
SO
objecten/klassen
services
Interfaces
interface
interface (WSDL)
Koppeling
vaste koppeling
losse koppeling
Compositie
aggregatie,compositie
compositie
Autonomie
laag
hoog
toestandsbehoudend
vooral toestandsloos
zelf beschrijvend
SO - beschrijving
Herbruikbaarheid
Toestand Vindbaarheid
5.3
Globale architectuur
In dit hoofdstuk bekijken we ook de architectuur van de applicatie. We baseren ons op de specificaties, use cases en sequentiediagrammen om hieruit de nodige interacties en componenten op te bouwen. Vertrekkende van een globaal schema bespreken we de verschillende services in detail.
5.3.1
Ontwerppatronen
Voor het ontwikkelen van een robuste architectuur gaan we na welke ontwerppatronen een impact kunnen hebben op het ontwerp van onze administratieve toepassing. Vooraleer we een afweging van de ontwerppatronen maken inzake karakteristieken bekijken we enkele patronen die een rol zouden kunnen spelen in ons ontwerp.
Mediator Dit patroon richt zich op het gedrag van objecten. Het patroon bevordert een lossere koppeling door objecten ervan te weerhouden expliciet naar elkaar te verwijzen. Ze maken het mogelijk de interacties tussen objecten onafhankelijk van elkaar te vari¨eren [13]. De interacties tussen de objecten wordt geregeld via de mediator. Indien er vele onderlinge verbindingen zouden zijn, zijn de objecten immers zeer afhankelijk van elkaar en resulteert een kleine wijziging in een object in wijzigingen in de andere objecten die een verbinding hebben met dat object. Een mediator is verantwoordelijk voor het beheer en de co¨ordinatie van de diverse interacties tussen de objecten. De mediator is als een tussenpersoon die de communicatie regelt tussen objecten, zonder dat die
5.3 Globale architectuur
33
expliciet verbonden zijn met elkaar. De objecten hoeven elkaar strikt genomen niet te kennen. Hierbij kent deze tussenpersoon dus de objecten en de objecten kennen de tussenpersoon. Door het gebruik van dit patroon vermindert dus het aantal onderlinge verbindingen wat de uitbreidbaarheid en structuur ten goede kan komen.
Figuur 5.1: Mediator ontwerppatroon
Facade Een structureel patroon dat een uniforme interface levert voor een reeks interfaces in een subsysteem is de facade [13]. De facade helpt om het aantal afhankelijkheden tussen de subsystemen te verminderen. Het biedt een eenvoudige interface bovenop de subsystemen. We kunnen het ontwerppatroon introduceren om de subsystemen te ontkoppelen van diens clients. Hierbij biedt de facade een algemeen toegangspunt voor de subsystemen. De facade fungeert als een doorgeefluik. Door het gebruik van dit patroon verminderen we de onderlinge afhankelijkheden en vereenvoudigen we de koppeling met een algemene eenvoudige interface voor de client.
Figuur 5.2: Facade ontwerppatroon
5.3 Globale architectuur
34
Proxy De proxy is een surrogaat of plaatshouder voor een ander object om daartoe de toegang te controleren [13].
Figuur 5.3: Proxy ontwerppatroon
Afwegingen De ontwerppatronen Mediator en Facade lijken in zekere mate aan elkaar gerelateerd. Bij het ontwerp van de applicatie hebben we nood aan een beheerder die de verschillende onderlinge delen zal koppelen. Voortgaande op de visie uit de servicegebaseerde architectuur merken we echter dat in de Mediator er de eis is dat alle deelnemende partijen elkaar kennen. Dit hoeft echter niet zo te zijn bij de applicatie. Om een losse koppeling toe te laten beslissen we dat enkel een beheerdermodule de andere delen kent. Wanneer we de verschillende submodules opbouwen voorzien we ook dat deze als services kunnen werken, en weten we al deels dat ze op implementatieniveau aanleiding zullen geven tot web services. Deze services zullen zich gedragen als doorgeefluik of facade naar achterliggende functionaliteit. Merk op dat bij web services een proxy zal worden gegenereerd.
5.3.2
Een centraal beheer
We plaatsen een centrale beheermodule die instaat voor de integratie en controle over de communicatie tussen de verschillende deelblokken. Een autonomie wordt gerealiseerd doordat de verschillende deelcomponenten hun verwerking afschermen en enkel toegankelijk zijn via hun interfaces. De centrale beheermodule welke we verder ’monitor’ noemen biedt bovendien de mogelijkheid om de verwerkingstaken te controleren.
5.3.3
XML als medisch dataformaat
In de architectuur dienen we ook rekening te houden hoe de interacties tussen de verschillende delen zullen verlopen. De werkgroep Data van de Telematics Commission formuleerde in
5.3 Globale architectuur
35
2001 reeds een aantal adviezen m.b.t. ’Electronic Health Care Messages’ [14]. E´en van de aanbevelingen is het gebruik van XML als syntax voor de elekronische health care berichtenuitwisseling. XML is namelijk een geaccepteerde industriestandaard en het grote aantal tools voor de bewerking en het bekijken van XML-formaten maken de taal tot een geschikt formaat voor dataopslag.
Opbouw van het tarificatieformulier Het XML-document in onze toepassing bestaat uit een set tags die het medisch tarificatieformulier beschrijven. Voor een voorbeeld van dit formulier verwijzen we naar bijlage B. De tags kunnen zelf gekozen worden. HTML bezit een gelijkaardige tag-structuur met dat verschil dat bij HTML de tags vastliggen. Bij het tarificatieformulier kunnen we zo elementen specifi¨eren voor de prestaties en voor de algemene pati¨enteninformatie. Het formulier zal m.a.w. de aan te rekenen prestaties bevatten. De namespace in het XML document is een unieke identificatie. De namespace wordt aangeduid met het attribuut xmlns. Omwille van de eenvoud, leesbaarheid en standaard leende XML zich goed voor de opslag van de medische tarificatieformulieren. We kozen ervoor om tags te voorzien voor de algemene pati¨enteninformatie en enkele per prestatie die een aanduiding vormen van de code en het aantal per tijdstip (vb. dag- of nachtdienst).
5.3.4
Architectuur van de eHealth toepassing
Figuur 5.4 geeft een overzicht van de globale architectuur. De TimerService (1) geeft een impuls naar de Monitor om de TriggerService aan te roepen. De TimerService staat in voor het bijhouden wanneer deze bevraging moet gebeuren. Periodiek wordt de TriggerService (2) gevraagd de gewijzigde data van bvb. de laatste 24u op te halen uit de database (2,3). Aan de hand van deze data wordt er voor elke pati¨ent een tarificatieformulier opgebouwd op basis van de aanwezige data (4,5). Daarna kan de monitor een RegelService aanroepen welke de verschillende RIZIVregels toepast op het formulier (6,7). Ook worden artsen toegekend aan het formulier (8,9). De MPFLOPService tenslotte zorgt voor de omzetting van tarificatieformulieren naar een formaat voor de financi¨ele dienst.
5.4 Bespreking van de eHealth-services
36
Figuur 5.4: Globale architectuur eHealth toepassing
5.4
Bespreking van de eHealth-services
5.4.1
Grafische User Interface
Deze GUI vormt de toegang voor de gebruiker tot de automatisatie-instellingen en biedt de mogelijkheden om de formulieren te openen en te bekijken. Deze GUI dient, in overeenstemming met de use cases, een eenvoudige en onderhoudbare toegangspoort te zijn voor de hele applicatie. De grafische user interface staat enkel in verbinding met de monitor.
5.4.2
TimerService
Deze service is verantwoordelijk voor de tijd. Het vormt eigenlijk een tijdsklok die elke dag (of na de ingestelde periode) afloopt en hiermee een indicatie geeft dat de database moet geconsulteerd worden.
5.4 Bespreking van de eHealth-services
5.4.3
37
TriggerService
Deze service staat in contact met de pati¨entendatabank. De communicatie met de databank kunnen we bewerkstelligen d.m.v. ODBC of een .NET dataprovider. Alle communicatie die met de databank moet verlopen, moet via deze service verlopen. Zo wordt de IZIS-databank ook afgeschermd door deze service.
5.4.4
TarificatieService
De TarificatieService is verantwoordelijk voor het opbouwen van een tarificatieformulier. De service dient een formulier op te bouwen met de verschillende aan te rekenen medisch technische prestaties voor een pati¨ent. Het formulier wordt opgebouwd volgens de structuurspecificaties die we vastlegden voor het XML-formaat. Het tarificatieformulier vormt het middel om verder in de andere services, de artsen te gaan koppelen aan de prestaties en een verificatie van de RIZIV-regels door te voeren.
5.4.5
RIZIVRegelService
Deze service staat in voor de controle van de RIZIV-regels. De service beschikt over de informatie over de toe te passen regels en zal een tarificatieformulier teruggeven waarbij de RIZIV-regels zijn toegepast. De RIZIVRegelService heeft als input een tarificatieformulier en zet dit om in een tarificatieformulier waarbij de prestatieaantallen in overeenstemming zijn met de RIZIV-regels.
5.4.6
ArtsenService
Deze service zal de prestaties op het tarificatieformulier voorzien van een arts. Deze service is noodzakelijk omdat de artseninformatie nog niet in de IZIS-databank aanwezig is. Eigenlijk zou op termijn het moeten mogelijk zijn om meteen de prestatie en de arts uit de databank te halen. Deze service moet momenteel dus nog zelf de verschillende artsen bijhouden met hun bijbehorende verlofperiodes en bevoegdheden. Dit moet gebeuren omdat we enkel beschikbare artsen kunnen koppelen aan een prestatie. De ArtsenService heeft als input een tarificatieformulier en zet dit om in een tarificatieformulier waarbij de artsen zijn toegevoegd.
5.4 Bespreking van de eHealth-services
5.4.7
38
MPFLOPService
De MPFLOPService staat in voor de omzetting van het tarificatieformulier van de pati¨ent in een tekstueel formaat dat de financi¨ele dienst van het UZ gebruikt. Dit tekstformaat bevat een aaneenschakeling van pati¨entengegevens en eist een exacte breedte en inhoud van de diverse tekstvelden welke aaneengeschakeld worden. Een klein gedeelte van het MPFLOPformaat ziet er bijvoorbeeld als volgt uit: 20UZG 700313 028A06 MONITO 1100 20031127 0 IZE2 144922 D 20031127 144922 N0 Bovenstaande lijn vormt dan de omzetting van de gegevens van een tarificatieformulier, waarbij de pati¨entidentificatie 700313 is en een geleverde prestatie met code MONITO verstrekt werd op 27/11/2003 door de arts met identificatienummer 144922. Zo’n lijn noemen we een MPFLOPRecord. Een MPFLOPRecord is steeds op eenzelfde manier opgebouwd. We voorzien in deze service dus ook een klasse die verantwoordelijk is voor de formattering. Alle gegevens van de tarificatieformulieren gaan op deze manier onder tekstuele vorm naar de financi¨ele dienst. De MPFLOPService heeft als input de gegevens van het tarificatieformulier en zet deze om in het tekstuele MPFLOP-formaat.
IMPLEMENTATIE
39
Hoofdstuk 6
Implementatie Dit hoofdstuk gaat dieper in op de specifieke C#-implementatie van de applicatie. De oplossing van de applicatie bestaat uit acht verschillende .NET-projecten die we hier verder in detail zullen bespreken. Tot slot vermelden we ook nog het loggen van fouten dat voorzien is in de verschillende web services.
6.1
De TimerService
Het project TimerService bevat de klasse ProjectInstaller en de Windows Service EHealthTimerService.
6.1.1
De klasse ProjectInstaller
De klasse ProjectInstaller is verantwoordelijk voor het installeren van de Windows Service. Naast de automatisch gegenereerde code, bevat deze klasse nog twee EventHandlers die verantwoordelijk zijn voor het starten en stoppen van de service. De EventHandler ProjectInstaller_AfterInstall wordt opgeroepen net na de installatie van de service.
private void ProjectInstaller_AfterInstall(object sender, InstallEventArgs e) { ServiceController c = new ServiceController("eHealthTimer"); c.Start();
6.1 De TimerService
40
c.WaitForStatus(ServiceControllerStatus.Running); } De eerste lijn in deze code maakt een nieuwe ServiceController voor de ’eHealthTimer’ aan. Daarna wordt het commando start gegeven aan de ServiceController, die er voor zal zorgen dat de Windows Service eHealthTimer gestart wordt. De derde lijn zorgt ervoor dat de methode pas be¨eindigd wordt als de service zeker gestart is.
De EventHandler ProjectInstaller_BeforeUninstall wordt opgeroepen net voor het verwijderen van de service. private void ProjectInstaller_BeforeUninstall(object sender, InstallEventArgs e) { ServiceController c = new ServiceController("eHealthTimer"); c.Stop(); c.WaitForStatus(ServiceControllerStatus.Stopped); } Deze EventHandler is bijna identiek aan de vorige, met dat verschil dat hier de service wordt gestopt.
6.1.2
De Windows Service EHealthTimerService
De ’EHealthTimerService’ is de Windows Service die verantwoordelijk is voor het starten van alle periodieke taken. Deze service heeft een webreferentie naar de Monitor (zie verder) voor het opvragen van de nodige instellingen en het oproepen van de webmethoden. private MonitorService monitor; De service bevat ook een Timer die elke tien minuten een Elapsed event genereert. private System.Timers.Timer timer; Dit event wordt dan opgevangen door EventHandler timer_Elapsed. Deze methode zal dan de DataSet-Settings van de MonitorService opvragen en aan de hand van die instellingen kan er gecontroleerd worden of er een actie moet starten.
6.2 De TriggerService
41
Als de triggering moet gestart worden, dan wordt volgende code uitgevoerd in de TimerService:
DateTime eind = DateTime.Now.Subtract(new TimeSpan(1,0,0,0,0)); DateTime begin = (DateTime)settings.Triggering.Select()[0]["LaatsteTriggering"]; TimeSpan periode = new TimeSpan ((int) settings.Triggering.Select()[0]["Periode"],0,0,0,0); if (eind - begin >= periode) monitor.BeginStartTriggering(begin,null,null); De eerste lijn code vermindert de datum van de dag met ´e´en. Zo kan men tot en met de vorige dag triggeren. De tweede lijn code bepaalt vanaf welke datum de triggering dient te starten. Deze datum duidt op de datum van de laatste triggering en is opgeslagen in de settings-DataSet in de kolom ’LaatsteTriggering’. De volgende lijn maakt een TimeSpan die het aantal dagen van de periode waarover men triggert bevat. Dit is nodig om de conditie van overlapping na te gaan. Als men dus in de instellingen opgeeft dat de periode drie dagen is, dan zal er maar om de drie dagen getriggerd worden. Als de conditie waar is dan wordt er een asynchrone oproep gedaan naar de MonitorService voor het starten van de triggering.
6.2
De TriggerService
Het project TriggerService bestaat uit een DataSet ’LaatsteFacturatie’ en de web service SybaseTriggerService.
6.2.1
De DataSet LaatsteFacturatie
Deze DataSet bevat slechts ´e´en tabel Facturatie. De tabel heeft twee kolommen: Id en Datum. Het bevat alle pati¨enten waarvoor nog een facturatie moet gebeuren samen met de datum vanaf wanneer die facturatie moet beginnen.
6.2.2
De SybaseTriggerService
De SybaseTriggerService verzorgt alle communicatie met de Sybase-databank van het IZISsysteem.
6.2 De TriggerService
42
Connectie De connectie met de databank wordt gemaakt met behulp van de AseDataProvider. Om deze dataprovider te kunnen gebruiken moet men de volgende import doen:
using Sybase.Data.AseClient; Voor het maken van een verbinding met de databank heeft de service een private methode:
private AseConnection MaakConnectie(String databank) { AseConnection conn = new AseConnection(); //1 conn.ConnectionString = "Data Source=’ url databank ’;" + "Port=’ poort ’;" + "Database=’"+databank+"’;" + "UID=’ gebruikersnaam ’;" + "PWD=’ wachtwoord ’"; //2 return conn; //3 } Deze methode neemt als argument een string met de naam van de databank die men wil connecteren. In deze thesis is dit de databank ’pati¨ent’ of de databank ’system’. De methode maakt dan een nieuwe AseConnection (1) aan en de ConnectionString (2) wordt ingesteld. Deze string bevat alle gegevens over de connectie die moet worden opgezet. De connectie wordt dan teruggegeven aan de oproeper van deze functie. Om de connectie te kunnen gebruiken moet deze wel nog geopend worden:
conn.Open(); Nu is de connectie gemaakt en kan men ze aanwenden om gegevens op te halen met behulp van een AseCommand die dan wordt uitgevoerd door een AseDataReader.
Update Opnames private void UpdateAdmissions(DateTime start, DateTime end)
6.2 De TriggerService
43
Deze methode is verantwoordelijk voor het updaten van de DataSet ’LaatsteFacturatie’.
AseConnection patientConn = MaakConnectie("patient"); //1 patientConn.Open(); //2
AseCommand cmd = new AseCommand("SELECT PatientId, AdmissionTime FROM p_generaldata " + "WHERE AdmissionTime >= ’" + start.ToString("yyyy-MM-dd hh:mm:ss") + "’ AND AdmissionTime < ’" + end.ToString("yyyy-MM-dd hh:mm:ss") + "’",patientConn); //3
AseDataReader reader = cmd.ExecuteReader(); //4 while(reader.Read()) //5 Eerst wordt er een connectie gemaakt met de databank (1 en 2). Dan zoekt men naar alle pati¨enten die opgenomen werden op de dienst in de periode [start, end[ (3 en 4). In de while-lus (5) wordt het id en de opnamedatum van deze pati¨enten toegevoegd aan de DataSet.
Ophalen van pati¨ enten public DataSet GetPatients(DateTime start,int periode, int langdurigePatienten) De methode is verantwoordelijk voor het ophalen van de pati¨enten waarvoor een facturatie moet gebeuren. De pati¨enten werden ofwel ontslagen in de periode [start, start+periode[ of het is langer geleden dan de waarde van de parameter ’LangdurigePatienten’ dat er een facturatie is gebeurd. Deze methode roept eerst de methode UpdateAdmissions op. Daarna zal het een connectie maken met de databank en alle ontslagen pati¨enten opvragen via
AseConnection patientConn = MaakConnectie("patient"); patientConn.Open(); AseCommand cmd = new AseCommand("SELECT PatientID,
6.2 De TriggerService
44
DischargeTime FROM p_dischargedata WHERE " + "DischargeTime >= ’"+ start.ToString("yyyy-MM-dd hh:mm:ss") + "’ AND DischargeTime < ’" + end.ToString("yyyy-MM-dd hh:mm:ss") + "’",conn); AseDataReader reader = cmd.ExecuteReader(); Na het uitvoeren van deze code bevat reader het id en de ontslagdatum van alle pati¨enten ontslagen tijdens de periode [start, end[, waarbij DateTime end = start.AddDays(periode); Al deze pati¨enten worden in een DataSet geplaatst samen met hun laatste facturatiedatum en hun ontslagdatum. Deze pati¨enten worden ook verwijderd uit de tabel ’Facturatie’ van de DataSet ’LaatsteFacturatie’. Daarna gaat de methode op zoek naar pati¨enten die een tussentijdse facturatie moeten krijgen. Hiervoor controleert men voor elke pati¨ent uit de tabel ’Facturatie’ of de laatste facturatiedatum meer dagen verschilt dan aangegeven door de parameter ’langdurigePatienten’ met de waarde van ’end’. Ook deze pati¨enten worden toegevoegd aan die DataSet en hun laatste facturatiedatum wordt aangepast. De DataSet wordt dan teruggegeven als resultaat van deze methode.
Ophalen prestaties public DataSet GetPrestaties(int patientId, DateTime start, DateTime end) Met bovenstaande methode kan men per pati¨ent alle toegediende medische technische prestaties binnen een bepaalde periode opvragen. Deze methode maakt een DataSet aan met daarin de prestatiecode en het tijdstip van uitvoering van de prestatie. Het roept dan de volgende vier bijna identieke methodes aan die elk een soort prestatie opvragen en in de DataSet plaatsen. De DataSet wordt dan teruggegeven. private DataSet GetGeobserveerdePrestaties(int patientId, DateTime start, DateTime end, DataSet data); private DataSet GetMonitoringPrestaties(int patientId, DateTime start, DateTime end, DataSet data);
6.3 De TarificatieService
45
private DataSet GetOnderzoeksPrestaties(int patientId, DateTime start, DateTime end, DataSet data);
private DataSet GetToegediendeMedicatie(int patientId, DateTime start, DateTime end, DataSet data);
private DataSet GetBerekendeWaarden(int patientId, DateTime start, DateTime end, DataSet data);
Extra pati¨ enteninformatie public object[] GetPatientenInfo(int patientId) Deze methode haalt extra informatie over een bepaalde pati¨ent op uit de databank. De object array bevat respectievelijk: • het pati¨entennummer • het episodenummer • de familienaam • de voornaam • het geslacht • de geboortedatum • de opnamedatum • de ontslagdatum indien al gekend, anders null
6.3
De TarificatieService
Het project TarificatieService bestaat uit een DataSet ’Prestaties’, een DataSet ’Feestdagen’, een DataSet ’Tarificatieformulier’ en een web service TarificatieFormatService.
6.3 De TarificatieService
6.3.1
46
De DataSet Prestaties
Dit type DataSet heeft een DataTable ’Prestatie’ die alle medisch technische prestaties bevat die het systeem herkent. Een medisch technische prestatie bestaat uit: • een code (mnemonic) • een omschrijving • een nomenclatuur nummer • een IZIS-code • een type • een bevoegdheid (voor de uitvoerende arts)
6.3.2
De DataSet Feestdagen
Dit type DataSet heeft een DataTable ’Feestdag’ die alle feestdagen bevat. Een Feestdag bestaat uit: • een dag • een maand • een naam Er is voor gekozen om niet het jaar op te slaan, zodat feestdagen die elk jaar op dezelfde datum vallen, slechts ´e´enmaal moeten worden ingevoerd. De andere feestdagen (b.v. Pasen en Pinksteren) moeten echter wel elk jaar aangepast worden.
6.3.3
De DataSet Tarificatieformulieren
Dit is het belangrijkste type DataSet. Het is de voorstelling van het tarificatieformulier dat het verplegend personeel elke dag voor elke pati¨ent moet invullen. De elektronische vorm van het tarificatieformulier bestaat uit twee grote delen nl. informatie over de pati¨ent en de geleverde prestaties. Het informatiegedeelte bestaat uit een DataTable ’Pati¨ent’ die de volgende gegevens bevat:
6.3 De TarificatieService
47
• de familienaam • de voornaam • het id • het episodenummer • de geboortedatum • het geslacht • de opnamedatum • de ontslagdatum • de datum van het tarificatieformulier De geleverde prestaties worden voorgesteld in drie tabellen: Prestatie, Tijdstip en Arts. De tabel ’Prestatie’ bevat de code (mnemonic) en de uitleg van de prestatie. Per rij in de tabel ’Prestatie’ is er een rij in de tabel ’Tijdstip’ die het aantal prestaties per periode (Morgen, Dag, Nacht, Weekend, Feestdag) aangeeft. Ook is er voor elke prestatierij een rij in de tabel ’Arts’ die informatie bevat over de arts die de prestatie heeft uitgevoerd.
6.3.4
De TarificatieFormatService
Deze web service is verantwoordelijk voor het genereren van het elektronisch tarificatieformulier. Deze service heeft naast de getters en de setters voor bovenstaande DataSets ook nog een methode voor het cre¨eren van de tarificatieformulieren. public Tarificatieformulier[] MaakTarificatie (object[] patientInfo, DataSet prestaties, DateTime start, DateTime end) De bovenstaande methode wordt opgeroepen met een objectarray met de nodige informatie over de pati¨ent, een DataSet die alle prestaties bevat en de begin- en einddatum van de te factureren periode. De methode maakt per dag van de te factureren periode een nieuw tarificatieformulier en vraagt dan aan de DataSet de uitgevoerde prestaties van die dag. Deze prestaties hebben nog IZIS-codes die moeten vertaald worden naar de juiste mnemonic.
6.4 De RegelService
48
Voor elke prestatie wordt er gecontroleerd of die prestatie al in het tarificatieformulier staat. Zoniet dan wordt er een nieuwe prestatie toegevoegd. De tijdstiprij behorende bij die prestatie wordt dan ook opgevraagd en aangepast volgens het tijdstip dat bij de prestatie staat in de DataSet. Als alle prestaties van die dag zijn verwerkt, wordt het tarificatieformulier toegevoegd aan de array. Als alle dagen van de periode zijn verwerkt, wordt de array met de tarificatieformulieren terug gegeven als resultaat van de functie.
6.4
De RegelService
Het project RegelService is opgebouwd uit een DataSet ’Regels’ en een web service RIZIVRegelService.
6.4.1
De DataSet Regels
Het type ’Regels’ is een DataSet die zowel de hoeveelheidsregels als de splitsingsregels bevat. De hoeveelheidsregels worden voorgesteld door een DataTable die de prestatiecode en een bepaalde maximum hoeveelheid bevat. De splitingsregels bestaan uit twee tabellen. De oudertabel ’SplitsingsRegel’ bevat de prestatiecode van de prestatie die gesplitst dient te worden. Elke rij in deze tabel heeft minstens twee kinderrijen in de tabel ’DeelCode’. Deze tabel bevat alle codes waarin de presatie moet worden gesplitst.
6.4.2
De RIZIVRegelService
De hoofdfunctionaliteit van deze web service is het toepassen van de twee soorten regels op de prestaties van een tarificatieformulier. Daartoe heeft deze service drie methoden:
public DataSet StartRegelService(DataSet data, DataSet prestaties) private DataSet ToepassenSplitsingsRegels(DataSet data, DataSet prestaties) private DataSet ToepassenHoeveelheidsRegels(DataSet data)
6.5 De ArtsenService
49
De eerste methode is vervat in de interface naar buiten toe. Deze methode start het toepassen van de regels op het tarificatieformulier data. De DataSet ’prestaties’ bevat alle medisch technische prestaties van het systeem. Deze is nodig voor het opvragen van extra informatie van de prestaties bij het toepassen van de splitingsregels. De DataSet die wordt teruggegeven is dan het aangepaste tarificatieformulier. De laatste twee methodes worden dan opgeroepen vanuit ’StartRegelService’.
Bij het toepassen van de HoeveelheidsRegels wordt er rekening gehouden met een proportionele verdeling van de prestaties over de periodes van de dag (Morgen (00u-7u59), Dag(8u-20u59) en Nacht(21u-23u59)). Zo zal een prestatie die een maximum heeft van zes op een dag bvb. twee maal in de morgen, drie maal overdag en ´e´en maal in de nacht voorkomen. Ook zal men op de dag van de opname en de ontslagdag rekening houden met het aantal uren dat men effectief heeft doorgebracht op de dienst. Als een pati¨ent om 12u is opgenomen, dan zal die prestatie maar 2 keer voorkomen overdag en 1 maal in de nacht. Bij het toepassen van de splitsingsregels wordt elke prestatie die gesplitst moet worden verwijderd uit het tarificatieformulier en worden de deelprestaties eraan toegevoegd. Naast deze drie methodes heeft de service ook nog een methode voor het opvragen van de Regels (GetRIZIVRegels) en een voor het instellen van de Regels (SetRIZIVRegels).
6.5
De ArtsenService
Het project ArtsenService heeft drie componenten: een DataSet ’SpecialisatieCodes’, een DataSet ’ArtsenInfo’ en een web service ArtsenInfoService.
6.5.1
De DataSet SpecialisatieCodes
Deze DataSet bevat alle specialisatiecodes van het systeem. Een specialisatiecode wordt door de laatste drie cijfers van het nomenclatuurnummer van een arts aangeduid. Aan de hand van deze code kan men de specialisatie van die arts weten.
6.6 De MPFLOPService
6.5.2
50
De DataSet ArtsenInfo
De drie tabellen (’ArtsInfo’, ’Arts’, ’Verlof’) van ’ArtsenInfo’ bevatten alle nodige informatie over de artsen van de dienst Intensieve Zorgen. De tabel ’ArtsInfo’ is de hoofdtabel. Een ArtsInfoRow bevat een veld voor het aantal prestaties dat de arts al heeft uitgevoerd en een verwijzing naar een ArtsRow en een naar ´e´en of meerdere verwijzingen naar een VerlofRow. Een ArtsRow bevat alle informatie over de arts zelf: naam, nomenclatuurnummer en specialisatie. Een VerlofRow bevat, zoals de naam het zegt, een verlofperiode van een bepaalde arts.
6.5.3
De ArtsenInfoService
Deze web service bevat naast de getters en setters voor de bovenstaande DataSets ook een methode voor het toevoegen van een arts aan elke prestatie van een tarificatieformulier. public DataSet ArtsenToevoegen(DataSet form, DataSet prestaties) Deze methode overloopt alle medisch technische prestaties van het tarificatieformulier form. Voor elke prestatie wordt de nodige bevoegdheid opgevraagd aan de DataSet ’prestaties’. Als de bevoegdheid ’Geen’ is, dan wordt de arts met het kleinste aantal uitgevoerde prestaties aan die prestatie toegekend. Als er wel een bevoegdheid voor die prestatie nodig is, dan gaat men eerst op zoek naar alle artsen die de juiste specialisatie hebben. Van die artsen zal men diegene met het kleinst aantal uitgevoerde prestaties koppelen aan die prestatie. Het aangepaste tarificatieformulier wordt dan teruggegeven als resultaat van de service.
6.6
De MPFLOPService
Het project MPFLOPService bestaat uit een klasse MPFLOPBuilder, een klasse MPFLOPRecord en de web service MPFLOPFormatService.
6.6.1
Web service MPFLOPFormatService
public string FormatForm(DataSet s) Deze web service vormt op zich niet meer dan een doorgeefluik naar de achterliggende klasse MPFLOPBuilder. Het tarificatieformulier waarbij artsen zijn gekoppeld aan elke prestatie en
6.6 De MPFLOPService
51
waarbij RIZIV-regels reeds zijn toegepast, wordt onder de vorm van een DataSet doorgegeven aan deze web service.
6.6.2
De klasse MPFLOPBuilder
Deze klasse staat in voor het ophalen van de vereiste data uit de tabellen van de DataSet. De DataSet wordt bevraagd en zo kan men MPFLOPRecords gaan opbouwen. De klasse staat in voor de gegevensselectie maar laat de uiteindelijke formattering van een MPFLOPRecord over aan de gelijknamige klasse MPFLOPRecord.
6.6.3
De klasse MPFLOPRecord
Deze klasse is de representatie van een MPFLOPRecord op zich. De klasse bezit een aantal setters die de MPFLOPFields instellen. Zo een veld is bvb. de geleverde prestatiecode. We voorzien ook analoge getters en leggen hier de eis vast dat de teruggekregen waarde de correcte breedte en uitlijning dient te hebben die voor een MPFLOPRecord vastgelegd is in zijn specificatie. De andere klasse MPFLOPBuilder interpreteert de data van een tarificatieformulier en cre¨ert instanties van MPFLOPRecord. Dit houdt in dat de klasse een inkomende DataSet die de gegevens van het tarificatieformulier bevat bevraagt, een MPFLOPRecord aanmaakt voor elke dag/nacht-prestatie per pati¨ent en nadien de verschillende aangemaakte records aaneen kan schakelen om zo tot een correct MPFLOP-formaat te komen.
6.6.4
String formatting
Het .NET framework bezit een statische functie String.Format in C#. Deze functie neemt een te formatteren string als input en genereert de output op basis van de meegegeven eis in de argumenten. In de klasse MPFLOPRecord wordt veelvuldig gebruik gemaakt van volgende code: string format(int breedte, string s) { return String.Format("{0,breedte}", s); } Dit codefragment zorgt ervoor dat steeds aan de gewenste breedte voor een gegevensveld in het MPFLOP-formaat wordt voldaan. Binnenin de accolades een gewenste formattering of
6.7 De Monitor
52
masker worden toegepast. Wanneer we de gewenste breedte laten voorafgaan door een minteken dan wordt de gewenste breedte gevormd met spaties vooraan, anders worden spaties achteraan toegevoegd indien dat nodig is om de breedte te bereiken.
6.7
De Monitor
Het project Monitor is opgebouwd uit een DataSet ’Settings’ en een web service MonitorService.
6.7.1
De DataSet Settings
Deze verzameling van tabellen bevat alle algemene instellingen van de applicatie. • Instellingen i.v.m. de automatisatie • Instellingen i.v.m. het doorsturen van de MPFLOP • Instellingen i.v.m. de triggering van de data • Instellingen i.v.m. het backuppen van de tarificatieformulieren
6.7.2
De MonitorService
Deze web service is de kern van de applicatie. Hij heeft een referentie naar alle andere web services voor de co¨ordinatie van de verschillende functionaliteiten. De service heeft drie grote groepen van methoden: • getters en setters • methoden voor de generatie van de MPFLOP • het versturen van de MPFLOP en het backuppen en verwijderen van de tarificatieformulieren.
Getters en setters Naast de methode voor het opvragen en instellen van de verschillende DataSets van de verschillende web services bevat deze groep ook methoden voor het ophalen van tarificatieformulieren en MPFLOPs.
6.7 De Monitor
53
public Tarificatieformulier[] GetTarificatieformulieren () Deze methode geeft alle nog niet gecontroleerde tarificatieformulieren terug.
public Tarificatieformulier[] GetMPFLOPs () Deze methode geeft alle nog niet gecontroleerde MPFLOPs terug.
public Tarificatieformulier[] GetOudeMPFLOPs(string naam, string voornaam, string id, string episode, DateTime date) Dit is een methode voor het opvragen van een MPFLOP aan de hand van de naam, voornaam, id, episodenummer van de pati¨ent en/of datum van de MPFLOP. De methode kan MPFLOPs tot twee jaar terug zoeken op basis van de ingevulde parameters. De parameters die niet nodig zijn bij het zoeken moeten null zijn (de date moet gelijk zijn aan DataTime.Now), anders worden ze wel in rekening gebracht. Het geeft een array terug van alle MPFLOPs die aan die parameters voldoen. De methode kijkt eerst of de datum geldig is (verschillend van DataTime.Now). Als die geldig is, dan weten we al in welke map de te zoeken MPFLOP zich bevindt en hoe de MPFLOPs noemen. Er wordt dan een ArrayList gemaakt met alle kandidaat MPFLOPs. Dan worden de parameters ´e´en voor ´e´en overlopen en worden de MPFLOPs die niet meer voldoen verwijderd uit de ArrayList. Diegene die nog overblijven op het einde van de methode worden teruggegeven als resultaat.
Generatie MPFLOP De groep bevat alle methodes voor de volledige generatie van een MPFLOP. Het begint allemaal bij de methode:
public void StartTriggering(DateTime date) Deze methode wordt op het juiste moment opgeroepen vanuit de EHealthTimerService en start zo het hele proces. De methode haalt eerst alle pati¨enten bij de TriggerService op waarvoor een facturatie moet gebeuren. Dan zal hij per pati¨ent alle prestaties asynchroon opvragen (1).
6.7 De Monitor
54
IAsyncResult result = trigger.BeginGetPrestaties (patientID,startDatum,eindDatum,null,r); //1 result.AsyncWaitHandle.WaitOne(); //2 DataSet prestaties = trigger.EndGetPrestaties(result); //3 Er moet dan gewacht worden tot het terugkeren van de asynchrone oproep (2). Als de TriggerService een resultaat heeft kan men het dan opvragen (3) en wordt het doorgestuurd naar de methode GenerateTarificatieFormulier. Hier is geopteerd om te wachten op het terugkeren van de call. Men kan ook werken met callbacks voor het opvagen van de terugkerende call. Echter door de beperking van het aantal threads in de Internet Information Services (IIS) 5.1 wordt de controle van de threads bemoeilijkt. public void GenerateTarificatieFormulier(int id, DataSet prestaties, DateTime start, DateTime end) Methode voor het starten van de generatie van het tarificatieformulier. Deze methode vraagt eerst extra informatie over de pati¨ent aan de TriggerService en roept dan de TarrificatieFormatService op voor het genereren van de tarificatieformulieren. Daarna worden de tarificatieformulieren opgeslagen op schijf en indien automatische generatie van het tarificatieformulier, worden ze een voor een doorgestuurd naar de methode StartRegelService. public void StartRegelService(Tarificatieformulier form) Deze methode roept de RegelService op en stuurt het verkregen resultaat door naar de methode StartArtsenService. public void StartArtsenService(DataSet form) Deze methode roept eerst de ArtsenService op en slaat dan het verkregen resultaat op en stuurt het eventueel (indien automatisatie MPFLOP aangezet is) door naar de methode GenerateMPFLOP. public void GenerateMPFLOP(DataSet form) Deze methode roept de MPFLOPFormatService op. Het verkregen resultaat (een string) wordt dan bijgeschreven aan het einde van een temporele MPFLOP.
6.7 De Monitor
55
Versturen en backup Deze groep bevat een zestal methoden: • public bool IsMPFLOPDoorgestuurd() Methode om te controleren of de MPFLOP is doorgestuurd. Deze methode heeft slechts eenmaal true terug na elk doorsturen. • public void MPFLOPDoorsturen() Voor het doorsturen van de MPFLOP naar de juiste locatie. De MPFLOP kan worden verstuurd naar een locatie op een (netwerk)schijf of naar een e-mailadres. De instellingen voor deze methode staan in de DataSet ’Settings’. • public int WanneerVerwijderenTarificatieformulieren() Methode voor de Grafische User Interface om te controleren of het tijd is voor het nemen van een backup. Deze methode geeft een aantal dagen tot de verwijdering van de tarificatieformulieren weer tenzij het nog langer dan zeven dagen is of dat er een automatische backup moet genomen worden. In die gevallen is de returnwaarde -1. • public void TijdVoorBackUpTarificatieformulieren(int dagen) Methode voor het instellen van het aantal dagen tot het verwijderen van de tarificatieformulieren. Deze methode wordt opgeroepen door de EHealthTimerService vanaf zeven dagen voor het verwijderen. • public void BackUpTarificatieformulieren(string path) Methode voor het nemen van een backup van de oude tarificatieformulieren. De string path is het pad waar de tarificatieformulieren dienen te worden opgeslagen. • public void VerwijderTarificatieformulieren() Methode voor het verwijderen van de oude tarificatieformulieren. Deze methode wordt ´e´enmaal per jaar op de 7de januari opgeroepen door de EHealthTimerService. De methode zal dan alle tarificatieformulieren van drie jaar terug verwijderen. Begin 2005 zullen dan bijvoorbeeld alle tarificatieformulieren van het jaar 2002 verwijderd worden.
6.8 De Grafische User Interface
6.8
56
De Grafische User Interface
De grafische user interface (GUI) is verantwoordelijk voor het contact met de gebruiker. Doordat de GUI bovenop de MonitorService is ge¨ımplementeerd wordt het opvragen en instellen van configuratieparameters zeer eenvoudig en kan het opvragen van de tarificatieformulieren of MPFLOPs snel gebeuren (zie bijlage A).
6.9
Logging
Elke web service is voorzien van een logfile. Telkens als er ergens een fout optreedt dan wordt deze gelogd in de logfile van de web service. Elke gelogde fout bevat een timestamp, de methode en de opgetreden fout. Daarnaast wordt ook nog de stacktrace van de exception in de logfile weggeschreven. Daar de web services naast het loggen van de fout, de fout ook nog eens doorgeven naar de oproeper van de service, kan het zijn dat bepaalde fouten in meerdere logfiles te voorschijn komen.
PRESTATIEMETINGEN
57
Hoofdstuk 7
Prestatiemetingen Onze applicatie moet niet enkel correct werken maar moet tevens ook performant zijn! Om die reden hebben we enkele prestatiemetingen uitgevoerd. De bevindingen hebben we neergeschreven in dit hoofdstuk.
7.1
De testopstelling
• De databankserver heeft als besturingssysteem Windows 2000 Server editie (Service Pack 2). Het systeem is een AMD Athlon XP 2200+ AT/AT Compatible met 523.760 KB RAM. • De PC waarop de webservices draaien is een Dell Inspiron 510m met een Intel Pentium M processor die draait op 1.70 GHz. Deze computer bezit ook 512 MB RAM geheugen en heeft Windows XP Professional (Service Pack 2) als besturingssysteem. De webservices worden ondersteund door de Internet Information Services (IIS) 5.1. • De connectie verloopt via een 100Mbit lokaal netwerk.
7.2
De code
Voor het meten van de tijdsduur van de verschillenden delen hebben we gebruik gemaakt van de volgende imports.
using System.Runtime.InteropServices;
7.2 De code
58
[DllImport("Kernel32.dll")] internal static extern int QueryPerformanceCounter(out Int64 qpc);
[DllImport("Kernel32.dll")] internal static extern int QueryPerformanceFrequency(out Int64 qpf); De eerste DllImport is een externe functie waarmee men het aantal kloktikken van de processor kan opvragen. De tweede is een externe functie voor het opvragen van het aantal kloktikken die de processor per seconde doet. De volgende functie berekent dan voor een gegeven start- en stopwaarde het aantal seconden dat er tussen die twee waarden ligt. static decimal GetSecondsElapsed(long start, long stop) { long queryFrequency; //1 QueryPerformanceFrequency(out queryFrequency); //2 decimal result = Convert.ToDecimal(stop - start) / Convert.ToDecimal(queryFrequency); //3 return Math.Round(result,6); //4 } Men definieert eerst een variabele (1), die dan via de extern functie QueryPerformanceFrequency (2), de waarde van het aantal kloktikken per seconde zal bevatten. Dan berekent men het aantal seconden (3) en voor de teruggave aan de oproeper van de methode wordt het afgerond tot zes cijfers na de komma (4). Volgende code illustreert het gebruik van de voorgaande functies: long start, stop; QueryPerformanceCounter(out start); // doe werk QueryPerformanceCounter(out stop); long tijd = GetSecondsElapsed(start,stop) Zo konden we metingen uitvoeren die tot op de microseconde (10−6 seconde) nauwkeurig zijn.
7.3 De resultaten
7.3
59
De resultaten
Daar we gebonden zijn aan de structuur van de databank en dus ook aan het aantal prestaties die we per pati¨ent kunnen opvragen, konden we het aantal opgevraagde prestaties niet zelf bepalen. We hebben daarvoor de gehele demodatabank bevraagd en komen tot de resultaten die we op de volgende pagina hebben toegevoegd. • De kolom id bevat niet het echte pati¨entennummer maar een id die Sybase heeft gegeven aan elke pati¨ent. • De kolom #prestaties bevat het aantal medisch technische prestaties die we van elke pati¨ent hebben kunnen ophalen uit de databank. • De kolom #formulieren bevat het aantal gegenereerde tarificatieformulieren. • De kolom GetPrestaties bevat de tijd in seconden voor het ophalen van de prestaties uit de databank via de SybaseTriggerService. • De kolom Tarificatie bevat de tijd in seconden voor het omzetten van de prestaties in de nodige tarificatieformulieren via de TarificatieFormatService.
7.3 De resultaten
60
Figuur 7.1: Resultaten van de prestatiemetingen
7.3 De resultaten
61
Alle metingen werden gedaan vanuit de MonitorService. Indien we deze metingen in een grafiek omzetten bekomen we de volgende resultaten:
Figuur 7.2: Grafiek van prestatiemetingen op GetPrestaties
Bovenstaande blauwe curve toont het verloop van de tijdsduur van het opvragen van de prestaties ten opzichte van het aantal prestaties. Hier zien we al een duidelijk stijgende lijn die min of meer lineair verloopt. De onregelmatigheden in de curve hebben te maken met een optimalisatie die is doorgevoerd in de TriggerService. Deze optimalisatie probeert de toegang tot de databank te beperken.
Wanneer men alle prestaties van een pati¨ent heeft opgevraagd, moet men in de systeemdatabank gaan zoeken naar de juiste RZ-code van die prestaties. De prestaties die al eens opgezocht zijn worden bijgehouden in een verzameling. Door eerst na te gaan of die prestatie al in deze verzameling vervat zit vooraleer men naar de databank gaat, wordt er zeer veel tijd gewonnen. Deze tijdswinst is vooral duidelijk bij pati¨enten die veel dezelfde prestaties hebben. Daardoor kunnen twee pati¨enten met eenzelfde aantal prestaties toch zeer verschillende tijden hebben voor het ophalen van de medisch technische prestaties.
7.3 De resultaten
62
Figuur 7.3: Grafiek van prestatiemetingen op de generatie van tarificatieformulieren
Deze grafiek vertoont het verloop van de generatie van de tarificatieformulieren ten opzichte van het aantal prestaties. Hier is het verloop zeer duidelijk lineair. Dit is geen verrassend resultaat, aangezien de TarificatieFormatService de prestaties ´e´en voor ´e´en moet verwerken en in het juiste tarificatieformulier op de juiste plaats moet zetten.
We hebben nu de prestaties van de TarificatieFormatService en de SybaseTriggerService gemeten. Deze services waren volgens ons de grootste bottlenecks en onze metingen bevestigen dit ook.
Voor de andere web services (RIZIVRegelService, ArtsenInfoService en
MPFLOPService) was de reactietijd bijna direct. Ook speelt hier het feit dat deze web services telkens op slechts ´e´en tarificatieformulier inwerken en we zo geen goede vergelijkende studie kunnen doen met de TarificatieFormatService en de SybaseTriggerService.
BESLUITEN EN UITBREIDINGEN
63
Hoofdstuk 8
Besluiten en uitbreidingen 8.1
Besluit
In deze scriptie zijn we vertrokken van de probleemstelling op de administratie van de dienst Intensieve Zorgen. We ondervonden dat hoewel pati¨enteninformatie en gegevens met betrekking tot ziektebeelden, diagnoses en bijbehorende medische prestaties worden opgeslagen in de databank van het Intensieve Zorgen Informatie Systeem (IZIS) er op het vlak van de administratie en facturatie van deze toegediende zorgen deze databank nog niet werd ingezet. Het facturatieproces verloopt er nog sterk papiergebaseerd met veel tijdrovend routinewerk. Het vormde een uitdaging om tot een automatisatie te komen waarin de taken van de administratie volledig gedragen worden door een toepassing. Wetende dat het facturatieproces tussen twee diensten verloopt met enerzijds de prestatiedata van IZ en anderzijds het uiteindelijke factureren door de financi¨ele dienst, zal deze automatisatie een integratie vormen tussen twee platformen.
De ontwikkeling van de toepassing bleek mogelijk te zijn door web services in te zetten die elk een verantwoordelijkheid en taak afschermen en die bovendien autonoom kunnen uitvoeren. We kozen er voor om waar mogelijk de services als herbruikbare gedeeltes op te vatten met een centrale beheerder die de informatiestromen tussen de services controleert. Een studie van web services en de servicegebaseerde architectuur leerde ons overigens dat standaardisatie en interoperabiliteit twee belangrijke kernwoorden zijn die platformonafhankelijk werken kunnen typeren. De case study toonde aan dat web services een goede technologie zijn om deze interoperabiliteit tussen de twee heterogene systemen te realiseren. Bovendien konden we XML als
8.2 Uitbreidingen en verder onderzoek
64
dataformaat inzetten om het tarificatatieformulier gedigitaliseerd voor te stellen en het formaat leende zich uitstekend om de gegevensstromen tussen de services goed te laten verlopen.
Bij het ontwikkelen van de services dient steeds voldoende rekening te worden gehouden met de gebruikersvereisten en -afspraken. Deze worden dan geanalyseerd in use cases en sequentieschema’s die een visualisatie bieden van de noden voor de applicatie. De ontwikkelingscyclus wordt verder doorlopen met het opstellen van de architectuur en nadien het komen tot een eerste implementatie. Hier bleek opnieuw dat de softwarecyclus vaak meermaals doorlopen wordt rekening houdende met opmerkingen en bijkomende vereisten uitgaande van de gebruiker. Het is interessant op te merken dat een evaluatie van de toepassing en tussentijds samenzitten met deze eindgebruiker de applicatie enkel kan verrijken en het uiteindelijk gebruik op de dienst ten goede kan komen. We hopen dan ook dat deze toepassing het facturatieproces in de toekomst kan ondersteunen!
8.2
Uitbreidingen en verder onderzoek
De ontwikkelingen op het vlak van web services en servicegebaseerde architectuur openen nieuwe mogelijkheden voor communicatie en datauitwisseling. Op vlak van beveiliging wensen we WSE (of Web Services Enhancements) te vermelden waarbij WS-Security als uitbreiding zou kunnen gebruikt worden om een beveiligd transport van berichten toe te laten. We bespraken deze WSspecificaties in hoofdstuk 2. Een andere uitbreiding ligt in het dataformaat om medische gegevens voor te stellen. Specifiek voor de gezondheidszorg ontwikkelde men HL7 voor datauitwisseling. Ook zijn uitbreidingen mogelijk aan de diverse services. De onderhoudbaarheid van de applicatie wordt mogelijk door talrijke instellingen die we in Bijlage A bundelden.
8.2.1
Datastandaarden in de gezondheidszorg
Een mogelijke uitbreiding vormt het gebruik van de standaard HL7 om data uit te wisselen tussen systemen. Hoewel we in onze eHealth applicatie gebruik maakten van XML als formaat voor datauitwisseling zijn er in de gezondheidssector ook enkele formaten tot standaarden ge¨evolueerd die vastleggen hoe data kan gedeeld worden. Voor interne applicaties wordt HL7 of Health Level Seven gebruikt.
8.2 Uitbreidingen en verder onderzoek
65
HL7 HL7 is zowel de naam van de datastandaard als van de organisatie die deze standaard ontwikkelde. HL7 staat voor Health Level Seven en benadrukt dat dit formaat zich situeert op de zevende laag of de applicatielaag van de OSI-stack. Het werkingsdomein van HL7 beslaat de klinische en administratieve data. Ze omschrijven hun missie[15] als volgt:
Standaarden aanbieden voor uitwisseling, beheer en integratie van data die klinische pati¨entenzorg, beheer, aanbod, evaluatie van de gezondheidszorg ondersteunt, specifiek om flexibele, kost-effici¨ente benaderingen, standaarden, richtlijnen, methodologie¨en en aanverwante diensten voor interoperabiliteit tussen gezondheidszorg- en ziekenhuis informatiesystemen te bieden.
Interoperabiliteit staat ook bij de ontwikkeling van deze standaard voorop met name voor de uitwisseling van pati¨enteninformatie.
GEBRUIKERSHANDLEIDING EHEALTH TARIFICATIE APPLICATIE
66
Bijlage A
Gebruikershandleiding eHealth Tarificatie applicatie A.1
Overzicht
Wanneer men de applicatie start verschijnt het hoofdmenu van de applicatie.
Figuur A.1: Hoofdmenu eHealth Tarificatie applicatie
We bespreken elke onderverdeling in detail. Men heeft de keuze tussen het openen van tarificatieformulieren, het openen van MPFLOP-bestanden of het openen van het venster met instellingen.
A.2 Tarificatieformulieren
A.2
67
Tarificatieformulieren
Figuur A.2: Menu Tarificatieformulieren
Wanneer men in het hoofdmenu op de knop van de tarificatieformulieren klikt verschijnt bovenstaand menu. Via dit menu kan de gebruiker de gegenereerde tarificatieformulieren controleren. Dit zijn de formulieren waarbij nog geen regels zijn toegepast en er nog geen artsen gekoppeld zijn aan de prestaties. E´enmaal men op de knop ’Controle’ heeft geklikt ziet men het volgende scherm verschijnen:
Figuur A.3: Venster met te controleren tarificatieformulieren
A.2 Tarificatieformulieren
68
Dit venster toont alle tarificatieformulieren die nog niet gecontroleerd zijn. Het toont de naam van de pati¨ent samen met de datum waarvoor het tarificatieformulier gemaakt is. Men kan dan het gewenste formulier selecteren en op de knop ’Toon’ klikken. Hetzelfde effect verkrijgt men ook door te dubbelklikken op het gewenste formulier of het formulier te selecteren en op de Enter-toets te drukken. Men krijgt dan het tarificatieformulier te zien.
Figuur A.4: Weergave van een tarificatieformulier
Aan de hand van dit venster kan men nagaan of het tarificatieformulier goed is gegenereerd. Men kan eventueel prestaties wijzigen, toevoegen of verwijderen. Om een prestatie te verwijderen, moet men ze selecteren en op de knop ’Verwijderen’ klikken. Bij het wijzigen of het toevoegen van een prestatie verschijnt een nieuw scherm.
Daar kan men in de keuzelijst de juiste prestatie kiezen. De omschrijving van de prestatie verandert automatisch mee met de gekozen prestatie. Daarna kan men dan per periode (Morgen, Dag, Nacht, Weekend, Feestdag) ingeven hoeveel prestaties er uitgevoerd zijn. Klikt men dan
A.3 MPFLOP-bestanden
69
Figuur A.5: Toevoegen van een prestatie
op de knop ’Toevoegen’ dan verschijnt deze prestatie onderaan de dataset.
A.3
MPFLOP-bestanden
Figuur A.6: Menu MPFLOP-bestanden
A.3 MPFLOP-bestanden
70
Via dit menu kan men de gegenereerde MPFLOP bestanden (in XML formaat) controleren, de al verwerkte MPFLOPs opzoeken en MPFLOPs openen.
A.3.1
Controleren van een MPFLOP
Het controleren van een MPFLOP is analoog aan het controleren van een tarificatieformulier. Men krijgt ook een scherm met alle nog niet gecontroleerde MPFLOPs te zien.
Figuur A.7: Venster met te controleren MPFLOP-bestanden
De gekozen MPFLOP wordt dan weergegeven op volgend scherm. Merk op dat hier de regels wel al zijn toegepast en dat er artsen aan de prestaties zijn gelinkt. Men kan dan ook prestaties toevoegen, wijzigen of verwijderen.
A.3 MPFLOP-bestanden
71
Figuur A.8: Weergave van een MPFLOP-bestand
Bemerk dat in de weergave van een MPFLOP-bestand telkens een arts is gekoppeld aan elke prestatie. Wanneer we vergelijken met de weergave van het tarificatieformulier dan zien we dat het prestatieaantal bij bijvoorbeeld prestatie ARTMET in bovenstaande schermafdruk gewijzigd werd door een RIZIV-regel!
Bij het toevoegen van een prestatie krijgt men een scherm waarbij de aantallen kunnen worden ingegeven.
A.3 MPFLOP-bestanden
72
Figuur A.9: Toevoegen van een prestatie
Dit is opnieuw analoog aan het toevoegen van een tarificatieformulier, maar hier is er nog een extra gedeelte voorzien voor het toevoegen van een arts aan de prestatie.
A.3.2
Zoeken van een MPFLOP
Indien men een MPFLOP wil zoeken, dan kan men dat doen door op de knop ’Zoek ’te klikken in het MPFLOP-Menu. Deze opzoeking gaat minstens twee jaar terug. Daarna worden de MPFLOPs verwijderd uit het systeem. (Dit gebeurt evenwel na een eventuele backup.)
Figuur A.10: Zoeken van een MPFLOP
A.3 MPFLOP-bestanden
73
Men kan zoeken op naam, voornaam, pati¨entennummer, episodenummer en datum. Als men een bepaalde zoekparameter wenst in rekening te brengen, dan moet men deze aanvinken en de juiste waarde invullen. Als men op de knop ’Zoek’ klikt dan verschijnt er een lijst met alle MPFLOPs die voldoen aan de criteria.
Figuur A.11: De gevonden MPFLOP-bestanden
Wanneer men geen zoekparameters heeft aangevinkt, dan verkrijgt men een lijst met alle MPFLOPs van de laatste twee jaar. Men kan dan de juiste MPFLOP selecteren en dan verkrijgt men een scherm met de volledige weergave van het formulier.
A.4 Instellingen
74
Figuur A.12: Weergave van tarificatieformulier voor afdruk
Deze weergave laat bovendien toe om de MPFLOP af te drukken of te exporteren naar een ander bestandsformaat.
A.3.3
MPFLOP openen
Indien men op de knop ’Openen’ klikt, dan krijgt men een venster te zien waarin men de juiste MPFLOP kan kiezen. Men krijgt dan ook bovenstaand scherm als resultaat.
A.4
Instellingen
Het menu instellingen:
A.4 Instellingen
75
Figuur A.13: Menu Instellingen
A.4.1
Algemene instellingen
Dit scherm bevat alle mogelijke configuratieparameters van het systeem.
Figuur A.14: Algemene instellingen
De groep ’Automatisatie’ bevat instellingen i.v.m. het automatiseren van de generatie. Wanneer men ’Generatie Tarificatieformulieren’ aanvinkt, dan zal men de nieuw gegenereerde tarificatie-
A.4 Instellingen
76
formulieren niet meer moeten controleren. Deze worden dan automatisch doorgestuurd voor het toepassen van de regels en het toevoegen van de artsen. Het aanvinken van ’Generatie MPFLOP’ heeft dan weer als resultaat dat men geen controle meer hoeft te doen op de MPFLOPs. Deze worden dan automatisch omgezet in het tekstformaat (volgens de MPFLOP-specificatie).
De groep ’Triggering’ bevat alle instellingen i.v.m. met het ophalen van de data bij het IZISsysteem. De periode is het aantal dagen waarover men de data opvraagt. Het is tevens de periodiciteit van het starten van de triggering. Als de periode bijvoorbeeld drie is, dan zal men om de drie dagen de data gaan opvragen en de tarificatieformulieren genereren. De waarde van ’Langdurige Pati¨enten’ slaat dan weer op het maken van een tussentijdse facturatie voor pati¨enten die lang op de dienst verblijven. Het tijdstip is het tijdstip waarop de triggering moet starten. Let wel dat door de specifieke implementatie van de timer dit kan vari¨eren met maximum tien minuten.
Onder ’Backup Tarificatieformulieren’ heeft men de mogelijkheid om het nemen van de backup te automatiseren. Hier kan men dan de map kiezen waar de bestanden moeten worden opgeslagen.
De groep ’Versturen MPFLOP ’ bevat alle instellingen i.v.m. de gegenereerde MPFLOP die moeten verstuurd worden naar de financi¨ele dienst. Men kan ervoor kiezen om de MPFLOP op te slaan op schijf (lokaal of netwerk) of om hem door te sturen naar een bepaald emailadres. Men kan daar ook de periodiciteit van dit doorsturen instellen.
A.4.2
Artsen Informatie
Instellen artsen Indien men in het menu ’Instellingen’ voor ’Artsen Informatie’ kiest dan krijgt men volgend scherm waar men de instellingen m.b.t. een arts kan maken.
A.4 Instellingen
77
Figuur A.15: Menu instellingen m.b.t. artsen
Figuur A.16: Instellen van artsen
Op dit scherm krijgt men alle artsen te zien, samen met hun nomenclatuurnummer en hun specialisatie. Hier kan men de informatie van artsen wijzigen, toevoegen of verwijderen. Om een arts te verwijderen, dient men hem te selecteren en op de knop ’Verwijderen’ te klikken. Het toevoegen en aanpassen van een arts gebeurt via volgend scherm:
A.4 Instellingen
78
Figuur A.17: Toevoegen van een arts
Bij het toevoegen van een arts is dit scherm leeg. Indien men de gegevens van een arts wil aanpassen verschijnt er in dit scherm de huidige waarde van de velden. Als men een verkeerd nummer ingeeft en men drukt op ’OK’ dan verschijnt er een rood rondje met een uitroepteken naast de velden van nummer.
Figuur A.18: Foutdetectie bij het toevoegen van een arts
Gaat men op dit uitroepteken met de muisaanwijzer staan dan krijgt men wat extra uitleg over de fout.
Het veld ’Specialisatie’ wordt automatisch ingevuld van zodra men een correcte specialisatiecode (laatste deel van het nummer) heeft ingevoerd.
A.4 Instellingen
79
Figuur A.19: Foutdetectie en info bij het toevoegen van een arts
Verlofdata
Figuur A.20: Verlofdata instellen
In de keuzelijst ’Naam’ kan men de naam van de arts selecteren en de verlofperiodes van die arts zullen tevoorschijn komen. Indien men op ’Toevoegen’ klikt verschijnt het volgende scherm:
A.4 Instellingen
80
Figuur A.21: Toevoegen van een verlofperiode
Hier kan men een verlofperiode van de arts invoegen. Voordat de verlofperiode wordt toegevoegd, wordt gecontroleerd of de einddatum na de begindatum komt. Zo worden enkel geldige periodes toegevoegd.
Specialisatiecodes Elke arts heeft een specialisatiecode (de laatste drie cijfers van zijn nomenclatuurnummer). Voor het bepalen van de juiste specialisatie van de arts en de nodige specialisatie voor het uitvoeren van een bepaalde prestatie, moeten ook deze codes opgenomen worden in het systeem.
Figuur A.22: Overzicht van de specialisatiecodes
Het toevoegen van een specialisatiecode gebeurt via volgend scherm:
A.4 Instellingen
81
Figuur A.23: Toevoegen van een specialisatiecode
A.4.3
Feestdagen
Indien men in het menu ’Instellingen’ voor ’Feestdagen’ kiest dan verschijnt het volgende scherm. Enkel de feestdagen die nog moeten komen worden op het scherm getoond. Feestdagen die elk jaar op dezelfde datum vallen moeten slechts ´e´enmaal worden ingegeven. De datums van die dagen wordt namelijk automatisch aangepast. Feestdagen die elke jaar veranderen van datum (Pasen, Pinksteren) moeten elk jaar worden aangepast aan de juiste datum.
Figuur A.24: Feestdagen instellen
A.4 Instellingen
82
Als men op de knop ’Toevoegen’ klikt dan ziet men het volgende scherm:
Figuur A.25: Toevoegen van een feestdag
In het bovenstaande scherm kan men een feestdag toevoegen.
A.4.4
Medisch Technische Prestaties
Indien men alle medisch technische prestaties die in het systeem zijn opgenomen wil kennen dan raadpleegt men best volgend scherm. Een prestatie heeft een mnemonic (code), een gedeelte met tekstuele uitleg (Tekst), een nomenclatuurnummer (NOM NR), een IZIS nummer (RZ IZIS), een type en een bevoegdheid. De bevoegdheid duidt aan welke arts die prestatie mag uitvoeren.
Figuur A.26: Overzicht van de Medisch Technische Prestaties
A.4 Instellingen
83
Figuur A.27: Toevoegen van een prestatie
Op dit scherm kan men alle velden van een prestatie invullen. Voor de waarde van ’Type’ kan men kiezen uit monitoring, onderzoek, observatie en medicatie. Bij ’Bevoegdheid’ kan men kiezen tussen ’Geen’ (alle artsen mogen deze prestatie uitvoeren) of voor ´e´en uit alle andere specialisaties die de applicatie zijn opgenomen (via het scherm ’Specialisatiecodes’).
A.4.5
RIZIV-regels
Er zijn twee soorten regels aanwezig in het systeem: ’Hoeveelheidsregels’ en ’Splitsingsregels’. De ’Hoeveelheidsregels’ vormen beperkingen. Ze bepalen hoeveel keer een zekere prestatie mag aangerekend worden per dag. De ’Splitsingsregels’ splitsen een bepaalde prestatie op in een aantal deelprestaties. Elk soort regel heeft zijn eigen tabblad, waarmee men kan kiezen welke regels men bekijkt.
A.4 Instellingen
84
Figuur A.28: Instellen van RIZIV-regels: Hoeveelheidsregels
Figuur A.29: Toevoegen van een hoeveelheidsregel
Als men op de knop ’Toevoegen’ klikt en het tabblad ’Hoeveelheidsregels’ is zichtbaar dan verschijnt volgend scherm. In dit scherm kan men dus een hoeveelheidsregel toevoegen. Men hoeft hiervoor enkel de juiste prestatie te selecteren in de keuzelijst en het aantal te bepalen. Het toevoegen van een splitsingsregel is iets ingewikkelder. Eerst bepaalt men de te splitsen prestatie in de bovenste keuzelijst (naast de code, zie volgende pagina).
A.4 Instellingen
85
Figuur A.30: Instellen van RIZIV-regels: Splitsingsregels
Figuur A.31: Toevoegen van een splitsingsregel
Dan kan men de prestaties selecteren waarin de bovenstaande prestatie moet gesplitst worden door ze te zoeken in de onderste keuzelijst en op de bovenste toevoegknop te klikken. De deelprestaties verschijnen dan in het onderste tekstvak gescheiden door een puntkomma. Als men op de knop ’Verwijder’ klikt dan wordt die laatste prestatie van de deelprestaties verwijderd.
XML-SPECIFICATIE VAN HET TARIFICATIEFORMULIER EN MPFLOP
Bijlage B
XML-specificatie van het tarificatieformulier en MPFLOP B.1
Voorbeeld van een formulier
<Patient> <PatientId>789123 <Episode>025A13 2004-10-23T00:00:00.0000000+02:00 Van De Velde Adam J. M 1953-09-09T12:00:00.0000000+02:00 2004-10-21T07:00:00.0000000+02:00 2004-11-10T12:00:00.0000000+01:00 ARTMET Drukmeting toezicht <Tijdstip> <Morgen>0 0 0 <Weekend>1
86
B.1 Voorbeeld van een formulier
0 C. Roosens 1-45176-33-100 D BULBUS Bulbus plaatsen <Tijdstip> <Morgen>249 0 92 <Weekend>398 0 P. Depuydt 1-34972-52-620 D VENTIL Beademing <Tijdstip> <Morgen>0 0 0 <Weekend>1 0 S. Oeyen 1-35677-26-100 D
87
B.1 Voorbeeld van een formulier
ECHAR Echografie Cardio <Tijdstip> <Morgen>2 0 1 <Weekend>3 0 J. Dewaele 1-46461-09-140 D ICDMET Drukmeting Intracranieel <Tijdstip> <Morgen>249 0 91 <Weekend>400 0 J. Decruyenaere 1-44922-93-580 D
88
INSTALLATIE
89
Bijlage C
Installatie In deze bijlage leggen we uit hoe de applicatie ge¨ınstalleerd moet worden. Voor de installatie van de gebruikersinterface is er een set-up voorzien, de web services daarentegen moeten handmatig worden geconfigureerd. Bijgevoegd vindt u een cd-rom met de nodige bestanden.
C.1
Installatie web services
Vooraleer men de web services kan installeren moet men zich ervan verzekeren dat er een versie van de Internet Information Services (IIS) is ge¨ınstalleerd. Is dit niet het geval dan kan men deze installeren met de Windows cd-rom. Ook moet een recente versie van het .NET framework ge¨ınstalleerd zijn op de computer. Deze set-up staat ook op de cd-rom.
Kopieer de volledige inhoud van de map ’webservices’ op de cd-rom naar C:\Inetput\wwwroot. Ga dan naar start menu - settings - control panel- administrative tools - Internet Information Services (IIS) Daar krijg je het volgende scherm te zien:
C.1 Installatie web services
90
Figuur C.1: Internet Information Services (IIS)
In de lijst onder ’Default Web Site’ ziet men alle mappen van de web services: ArtsenService, Monitor, MPFLOPService, RegelService, TarrificatieService en TriggerService. Nu moeten we de web services enkel nog registreren bij de IIS. Klik met de rechtermuisknop op de map Monitor en selecteer eigenschappen. U krijgt dan volgend scherm:
C.1 Installatie web services
Figuur C.2: Eigenschappen van de MonitorService instellen
Om de web service te registreren klik op de ’Create’-knop en vink ’Script source access’ aan.
Figuur C.3: Eigenschappen van de MonitorService instellen
91
C.1 Installatie web services
92
Als we dan op ’OK’ klikken en terugkeren naar het hoofdscherm van de IIS dan zien we dat de map Monitor een ander icoontje heeft gekregen.
Figuur C.4: Internet Information Services (IIS) na registratie MonitorService
Herhaal deze procedure voor alle andere web services. Als controle of de service wel goed geregistreerd is, kan men de webbrowser openen en surfen naar http://localhost/Monitor/MonitorService.asmx/ Als alles goed is zou men een overzicht moeten krijgen van alle methodes die de MonitorService bevat.
Na het installeren moet men nog de databankgegevens aanpassen in de SybaseTriggerService. Ga daarvoor naar de map C:\Inetpub\wwwroot\TriggerService en open het bestand ’DatabaseSettings.xml’ met een editor (bv. Wordpad). Men krijgt dan de volgende tekst te zien:
<source>url van databank
C.2 Installatie gebruikersinterface en timer
93
<port>poort waarop de databank draait <user>gebruikersnaam <password>paswoord van de gebruiker Vul tussen de tags de juiste informatie in en sla het bestand op. Nu zijn alle web services klaar voor gebruik!
C.2
Installatie gebruikersinterface en timer
De installatie van de gebruikersinterface is veel eenvoudiger. Hiervoor kan men de set-up uitvoeren vanaf de bijgeleverde cd-rom. Men moet dan gewoon de installatie-instructies volgen en de grafische user interface en de TimerService worden ge¨ınstalleerd.
Figuur C.5: Installatie gebruikersinterface en timer
Bij dit scherm klikt men gewoon op ’Next’.
C.2 Installatie gebruikersinterface en timer
94
Figuur C.6: Installatie gebruikersinterface en timer - installatiemap instellen
Men kan hier kiezen in welke map men alles wilt installeren en of het programma enkel door de huidige gebruiker of door alle gebruikers van de computer kan gebruikt worden. Als alles goed is ingesteld, klikt men op ’Next’.
C.2 Installatie gebruikersinterface en timer
95
Figuur C.7: Installatie gebruikersinterface en timer - bevestiging gegevens
Dit scherm vraagt nog eens een bevestiging of het programma wel degelijk mag ge¨ınstalleerd worden. Het volgende scherm geeft dan de voortgang van de installatie weer. Daarna bekomt men het laatste scherm van de set-up. Als men op ’Close’ klikt is de installatie voltooid en kan men de applicatie gebruiken.
C.2 Installatie gebruikersinterface en timer
Figuur C.8: Installatie gebruikersinterface en timer - voortgang installatie
Figuur C.9: Installatie gebruikersinterface en timer - voltooid
96
BIBLIOGRAFIE
97
Bibliografie [1] World Wide Web Consortium, http://www.w3c.org. [2] BALLINGER, K., .NET Web Services: Architecture and Implementation, Addison-Wesley, Pearson Education, Boston, 2003. [3] CERAMI, E., Web services essentials, O’Reilly, Cambridge, 2002. [4] FOGGON, D., MAHARRY D., ULLMAN, C., WATSON, K., Programming Microsoft .NET XML Web Services, Microsoft Press, Redmond, Washington, 2004. [5] ERL, T., Service-Oriented Architecture: A Field Guide to Integrating XML and Web Services. Pearson Education, Prentice Hall PTR, New Jersey, 2004. [6] PELTZ, C. (2003). Web services orchestration, a review of emerging technologies, tools, and standards Hewlett Packard, Co., 01/2003 [7] MSDN Library, Microsoft, http://msdn.microsoft.com/library/ [8] OH, H., RIZO, C., ENKIN, L, JADAD, A. (2005). tematic review of published definitions.
What is eHealth(3):
A sys-
Journal of Medical Internet Research, 7(1),
http://www.jmir.org/2005/1/e1. [9] EYSENBACH, G. (2001). What is e-Health? Journal of Medical Internet Research, 3(2), http://www.jmir.org/2001/2/e20. [10] eEurope2005
-
eHealth,
Europese
Commissie,
Information
Society
http://europa.eu.int/informationsociety/eeurope/2005/allabout/ehealth/texten.htm. [11] UZ Gent, http://www.ucu.be.
BIBLIOGRAFIE
98
[12] ERL, T., Service-Oriented Architecture: Concepts, Technology, and Design Pearson Education, Prentice Hall PTR, New Jersey, 2005, http://www.serviceorientation.org . [13] GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J., Design patterns - de Nederlandse editie: Elementen van herbruikbare objectgeori¨enteerde software. Pearson Education, 2000. [14] Federale Overheidsdienst Volksgezondheid, Cel Informatica, Telematica en Communicatie binnen de sector van de Gezondheidszorg, http://www.health.fgov.be/telematics/. [15] Health Level Seven, http://www.hl7.org.
LIJST VAN FIGUREN
99
Lijst van figuren
2.1
Modulaire opbouw van een web service . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Een cyclus van een web service . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1
Technische omgeving IZIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3.2
Probleemstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
3.3
Doelstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.1
Use case - Monitor als systeemactor . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.2
Use case - Administratief beheerder IZ . . . . . . . . . . . . . . . . . . . . . . . .
24
4.3
Sequentieschema van het ophalen van de data . . . . . . . . . . . . . . . . . . . .
26
4.4
Sequentieschema van de opbouw van een tarificatieformulier . . . . . . . . . . . .
27
4.5
Sequentieschema van de MPFLOP . . . . . . . . . . . . . . . . . . . . . . . . . .
27
5.1
Mediator ontwerppatroon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.2
Facade ontwerppatroon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
5.3
Proxy ontwerppatroon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.4
Globale architectuur eHealth toepassing . . . . . . . . . . . . . . . . . . . . . . .
36
7.1
Resultaten van de prestatiemetingen . . . . . . . . . . . . . . . . . . . . . . . . .
60
7.2
Grafiek van prestatiemetingen op GetPrestaties . . . . . . . . . . . . . . . . . . .
61
7.3
Grafiek van prestatiemetingen op de generatie van tarificatieformulieren . . . . .
62
A.1 Hoofdmenu eHealth Tarificatie applicatie
. . . . . . . . . . . . . . . . . . . . . .
66
LIJST VAN FIGUREN
100
A.2 Menu Tarificatieformulieren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
A.3 Venster met te controleren tarificatieformulieren
. . . . . . . . . . . . . . . . . .
67
A.4 Weergave van een tarificatieformulier . . . . . . . . . . . . . . . . . . . . . . . . .
68
A.5 Toevoegen van een prestatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
A.6 Menu MPFLOP-bestanden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
A.7 Venster met te controleren MPFLOP-bestanden . . . . . . . . . . . . . . . . . . .
70
A.8 Weergave van een MPFLOP-bestand . . . . . . . . . . . . . . . . . . . . . . . . .
71
A.9 Toevoegen van een prestatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.10 Zoeken van een MPFLOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
72
A.11 De gevonden MPFLOP-bestanden . . . . . . . . . . . . . . . . . . . . . . . . . .
73
A.12 Weergave van tarificatieformulier voor afdruk . . . . . . . . . . . . . . . . . . . .
74
A.13 Menu Instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.14 Algemene instellingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
75
A.15 Menu instellingen m.b.t. artsen . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
A.16 Instellen van artsen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
77
A.17 Toevoegen van een arts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
78
A.18 Foutdetectie bij het toevoegen van een arts . . . . . . . . . . . . . . . . . . . . .
78
A.19 Foutdetectie en info bij het toevoegen van een arts . . . . . . . . . . . . . . . . .
79
A.20 Verlofdata instellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
79
A.21 Toevoegen van een verlofperiode . . . . . . . . . . . . . . . . . . . . . . . . . . .
80
A.22 Overzicht van de specialisatiecodes . . . . . . . . . . . . . . . . . . . . . . . . . .
80
A.23 Toevoegen van een specialisatiecode . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.24 Feestdagen instellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
A.25 Toevoegen van een feestdag . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
82
A.26 Overzicht van de Medisch Technische Prestaties . . . . . . . . . . . . . . . . . . .
82
A.27 Toevoegen van een prestatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
83
A.28 Instellen van RIZIV-regels: Hoeveelheidsregels . . . . . . . . . . . . . . . . . . . .
84
LIJST VAN FIGUREN
101
A.29 Toevoegen van een hoeveelheidsregel . . . . . . . . . . . . . . . . . . . . . . . . .
84
A.30 Instellen van RIZIV-regels: Splitsingsregels . . . . . . . . . . . . . . . . . . . . .
85
A.31 Toevoegen van een splitsingsregel . . . . . . . . . . . . . . . . . . . . . . . . . . .
85
C.1 Internet Information Services (IIS) . . . . . . . . . . . . . . . . . . . . . . . . . .
90
C.2 Eigenschappen van de MonitorService instellen . . . . . . . . . . . . . . . . . . .
91
C.3 Eigenschappen van de MonitorService instellen . . . . . . . . . . . . . . . . . . .
91
C.4 Internet Information Services (IIS) na registratie MonitorService . . . . . . . . .
92
C.5 Installatie gebruikersinterface en timer . . . . . . . . . . . . . . . . . . . . . . . .
93
C.6 Installatie gebruikersinterface en timer - installatiemap instellen . . . . . . . . . .
94
C.7 Installatie gebruikersinterface en timer - bevestiging gegevens . . . . . . . . . . .
95
C.8 Installatie gebruikersinterface en timer - voortgang installatie . . . . . . . . . . .
96
C.9 Installatie gebruikersinterface en timer - voltooid . . . . . . . . . . . . . . . . . .
96
