Connectivity Eisen. Design document. Versie Vanaf softwareversie 6.0

Transcriptie

1 Connectivity Eisen Design document Versie Vanaf softwareversie augustus 2013

2 Inhoudsopgave 1 Doelstelling van dit document Functionele beschrijving van de communicatie ISO/OSI-lagen Laag 7. Applicatielaag Laag 6. Presentatielaag Laag 5. Sessielaag Laag 4. Transportlaag Laag 3. Netwerklaag Laag 2. Datalink-laag Laag 1. Fysieke laag Eisen Technische Eisen Applicatie (laag 7) Berichten (laag 6,7) HTTP (Laag 7) SSL/TLS (Laag 5 en 6) Toegang tot de grouper Toegang tot de grouper Firewall Whitelist Controle aanwezigheid van IP-adres in Firewall whitelist SOAP-Actions Inleiding De SOAP Service SOAP Location SOAP Action URL Action: gettock Voorbeeld: http header bij COMT_IN113113NLbericht Voorbeeld: COMT_IN113113NLbericht Ondersteunde SOAP Actions: (Geen) Gebruik maken de WSDL DBC-Onderhoud 2 22

3 Documenthistorie Versie Publicatiedatum Wijzigingen Initiele versie Reviewopmerkingen BS Aangepast aan de hand van opmerkingen van B. Schat 2.3b OID uitgifte voor ZI toegevoegd 2.3b Eisen aan IOD s voor Zorginstelingen verwijderd Crypto Algoritme Toegevoegd Toevoeging van ontbrekenden SOAP-Actions and SOAP-Locations 3.0a Correctie Soap actions en voorbeeld http headers 3.0b Benoemen toegestane SOAP actions in hoofdstuk 3, corrigeren verwijzing naar interne service DBC-O 3.0c SOAP-actions laden tabellen verwijderd De naamgeving van de hashcode voor DIS is in de specificaties aangepast volgens de werking van de grouper. De hashcode voor DIS wordt ook DIS genoemd i.p.v. ZPZA. Beschrijving van extra SOAP-action getdeclaratieresult02. Bij het gebruik van de nieuwe SOAP-action wordt aanlevering van de afsluitreden verplicht. De afsluitreden wordt tevens opgenomen in de hashberekening voor DIS en ZPZV versie 201. Aanvulling op de aansluiteisen t.a.v. de SSL/TSL laag in verband met de nieuwe certificaat hiërarchie uitgegeven door PKI-Overheid. Geplande datum voor invoering is: 1 september 2011 op de acceptatieomgeving getdeclaratieresult en getdeclaratieresult02 1 oktober 2011 op de productieomgeving getdeclaratieresult en getdeclaratieresult02 1 januari 2012 op productieomgeving getdeclaratieresult02 3.3a Toegevoegd advies t.a.v. de connectiviteits-eisen van de HTTP-laag voor aanleverende systemen van zorginstellingen welke grote declaratiedatasets aanbieden waarmee een lange verwerkingstijd van de grouper gepaard gaat. Aanvulling op de beschrijving van de public keys in hoofstuk 4.2. Naast de functionaliteit in de grouper, worden de keys voortaan ook via de website van DBC-Onderhoud beschikbaar gesteld. Toevoeging codering public keys. Concept specificatie betreffende grouper v4.0. Wijzigingen: Specificatie om berichtverwerking van grote datasets te faciliteren. DBC-Onderhoud 3 22

4 Versie Publicatiedatum Wijzigingen De public key kan vanaf 1 mei 2012 uitsluitend via de website van DBC-Onderhoud verkregen worden. Deze conceptversie wordt verstuurd aan deelnemers van het ICT-leveranciers en overige bij DBC-Onderhoud aangemelde ICT-leveranciers van de grouper. De definitieve versie wordt begin maart gepubliceerd op de website van DBC- Onderhoud Concept specificatie. Correctie van de URL van de grouperomgevingen. Definitieve versie van de specificaties voor de grouper softwareversie 4.0 welke uitgerold wordt binnen de RZ12c. Geen inhoudelijke wijzigingen t.a.v. voorgaande versie. Naast tekstuele correcties zijn een aantal eisen t.a.v. de HTTP-laag omgezet in adviezen. Ook is de eis t.a.v. de maximale openstellingstijd van de TSL/SSL sessie gewijzigd van 900 naar 600 seconden. Navolgende onderwerpen eisen zijn gewijzigd en/of toegevoegd Paragraaf 2.2 -Eisen verwijderd t.a.v. failovermechanism -Ondersteuning IPv Paragraaf 3.3 -Minimale ondersteuning cookies Paragraaf KNP-CA -Eisen m.b.t. aansluiting middels vecozocertificaat Toevoeging van hoofdstuk 4: toegang en firewall van de grouper Wijziging hoofdstuk 4, toegangscontrole is aanvullend mogelijk via http, waar voorheen enkele controle via https-protocol mogelijk was. Wijzigingen als gevolg van nieuwe berichtversie: - Paragraaf 3: Eis m.b.t. SOAP-bericht (paragraaf 3.2) en tabel met services en SOAP-actions Update Figuur 3 - Paragraaf 5.3.1: Toevoeging dat geldigheid SOAP-action afhankelijk is van ingangsdatum hoofdsubtraject en overzicht van eigenschappen per berichtversie - Informatie SOAP-action GetKey verwijderd (paragraag 5.1). DBC-Onderhoud 4 22

5 1 Doelstelling van dit document Het voorliggende document beschrijft de eisen die aan de connectie tussen de Ziekenhuis systemen en de grouper worden gesteld. Bij connectiviteit en communicatie is er altijd sprake van verschillende niveaus waarop afspraken moeten worden gemaakt om elkaar informatie te kunnen verstrekken en om elkaar te kunnen verstaan. Dit is evenzo het geval bij elektronische communicatie tussen de ziekenhuissystemen en de DBC-grouper. Bij elektronische communicatie is het ISO-OSI model een zeer bekend referentiekader. Dit document beschrijft daarom de connectiviteitseisen op alle zeven lagen van het ISO-OSI model. Het document dient dermate gedetailleerd te zijn, dat bij het opvolgen van alle eisen de connectiviteit tussen de systemen verzekerd is (er kunnen berichten heen-en-weer gestuurd worden). Interoperabiliteit van de systemen vereist daarnaast dat getest wordt op de semantisch correcte verwerking binnen de communicerende systemen. Over dit laatste doet het voorliggende document geen uitspraken, de desbetreffende eisen dienen uit internationale standaarden (zoals HL7v3) en andere specificaties omtrent de grouper te worden ontleend. Geraadpleegde bronnen Bron Omschrijving LSPGBZ Programma van eisen voor een GBZ, versie 6 LSPBER Implementatiehandleiding Berichttransport DBC-Onderhoud 5 22

6 2 Functionele beschrijving van de communicatie ISO/OSI-lagen Figuur 1 ISO/OSI Lagen Laag 7. Applicatielaag De applicatielaag of toepassingslaag is het enige deel van de communicatie dat de gebruiker kan zien. En dan nog hoeft de gebruiker niet te zien wat de toepassing doet, om een boodschap voor verzending via het netwerk voor te bereiden. De laag vertaalt de voor de mens leesbare boodschap in bits en voegt een kopje (header) toe dat de zender en ontvanger bevat Laag 6. Presentatielaag De presentatielaag zorgt ervoor dat de boodschap verzonden wordt in een taal die de ontvangende computer kan verwerken (meestal ASCII). Deze laag vertaalt de data indien nodig en comprimeert en versleutelt ze. De laag voegt een ander kopje toe dat de taal, de compressie- en versleutelmethode beschrijft Laag 5. Sessielaag De sessielaag opent de communicatie en heeft tot taak de communicatie tussen alle nodes van het netwerk in het gareel te houden. De sessielaag bepaalt het begin en het einde van de boodschap en bepaalt of deze half duplex (computers zenden en ontvangen om de beurt) of full duplex (computers zenden en ontvangen tegelijkertijd) wordt verzonden Laag 4. Transportlaag De transportlaag beschermt de verzonden data. Deze laag verdeelt de data in segmenten en berekent controle-totalen (checksums) waarmee later bepaald wordt of de data gecodeerd is. De transportlaag 1 Bron : DBC-Onderhoud 6 22

7 kan ook reservekopieën van de data maken. De transportheader bevat de checksum van elk segment en de locatie van dat segment binnen de gehele boodschap Laag 3. Netwerklaag De netwerklaag selecteert een route voor de boodschap. Deze laag plaatst data in pakketjes, telt deze en voegt een header toe waarin de volgorde van de pakketjes en het adres van de doelcomputer opgenomen zijn Laag 2. Datalink-laag De datalink-laag of koppelingslaag houdt toezicht op de verzending. Deze laag bevestigt de checksum en adresseert en dupliceert de pakketjes. Deze laag houdt een kopie van elk pakket aan tot bevestigd is dat het pakket onbeschadigd zijn bestemming heeft bereikt Laag 1. Fysieke laag De fysieke laag past de pakketjes aan, aan het medium dat ze transporteert. De pakketjes worden bijvoorbeeld in analoge signalen vertaald als ze via de telefoonlijn worden verzonden. De fysieke laag plaatst de pakketjes op het medium. 2.2 Eisen Over de lagen 1-4 is het niet nodig om voor de DBC-grouper specifieke afspraken te maken. Deze lagen worden door standaard protocollen gedekt (zoals TCP, IP en Ethernet) en ook de eisen die betrekking hebben op deze protocollen zijn standaard. Figuur 2 Protocollen Eis: Voor de communicatie met de DBC grouper geldt dan ook als redelijk eenvoudige eis dat communicatie plaatsvindt over het TCP/IP protocol. De DBC Grouper ondersteund vooralsnog geen IPv6, communicatie kan daarom alleen op basis van IPv4 plaatsvinden. DBC-Onderhoud 7 22

8 Eis: Voor de adressering binnen de communicatie tussen Ziekenhuis en DBC grouper wordt gebruik gemaakt van DNS (dus niet van rechtstreekse adressering op IP-nummer). Toekenning van DNS-naam en gekoppeld IP-nummer vindt plaats door DBC-Onderhoud. Bij de adressering zal aansluiting worden gezocht bij de praktijk zoals toegepast binnen de AORTA architectuur 2. Voor de aansluitingen aan de DBC-grouper zijn voor de lagen 5, 6 en 7gedetailleerde afspraken vereist. Hier zijn de technologieën van HTTP en SSL terug te vinden en het sessiemanagement. De eisen worden in het volgende hoofdstuk niet uitgesplitst naar laag, omdat sommige eisen betrekking kunnen hebben op meerdere lagen. De genoemde eisen zijn eisen gesteld aan de cliëntimplementatie bij de zorginstelling en dienen ook op dat niveau ingevuld te worden. 2 Zie DBC-Onderhoud 8 22

9 3 Technische Eisen 3.1 Applicatie (laag 7) Eis: Ieder Bericht heeft een per zorginstelling unieke ID. Dit betekent dat de complete id (OID + Unieke BerichtId) uniek is door het hele land. Eis: Ieder DeclaratieDataset heeft een per zorginstelling unieke ID. Dit betekent dat de complete id (OID + unieke DeclaratieDatasetId) uniek is door het hele land. Eis: Ieder Zorgtraject heeft een per zorginstelling unieke ID. Dit betekent dat de complete id (OID + Unieke ZorgtrajectNummer) uniek is door het hele land. Eis: Ieder subtraject heeft een per zorginstelling unieke ID. Dit betekent dat de complete id (OID + Unieke subtrajectnummer) uniek is door het hele land. Eis: Ieder Uitgevoerde Zorgactiviteit heeft een per zorginstelling unieke ID. Dit betekent dat de complete id (OID + Unieke Uitgevoerde ZorgactiviteitNummer) uniek is door het hele land. 3.2 Berichten (laag 6,7) Eis: De zorginstelling moet een SOAP bericht versturen zoals beschreven in de tabel services SOAP-actions. Eis: Voor de uitwisseling van de berichten naar de grouper is er gekozen om altijd in UTF-8 formaat uit te wisselen. Eis: Berichten worden uitgewisseld in welgevormd XML 1.0 Eis: Berichten worden verpakt volgends de SOAP standaard Eis: De berichten moeten valide zijn aan de HL7 XSD s FICR_IN900101NL01.xsd en FICR_IN910101NL01.xsd. Eis: De Maximale omvang van een automatisch te verwerken bericht is voorlopig gesteld op 22,5Mb. Indien een bericht wordt ingestuurd dat groter is dan dit maximum wordt er een SOAP error terug gestuurd met als errorcode DBC065 (Bericht overschrijdt maximale omvang). In dien deze error ontvangen wordt, dient er contact te worden opgenomen met DBC-Onderhoud. Eis: De minimale omvang van een automatisch te verwerken bericht is voorlopig gesteld op 1kb. Indien een bericht wordt ingestuurd dat kleiner is dan dit minimum wordt er een SOAP error terug gestuurd met als errorcode DBC067 (Bericht kleiner dan minimale omvang). Indien deze error ontvangen wordt, is er geen bericht verstuurd en dit wijst op een vermoedelijke fout in de software van de leverancier. 3 (spec body 1.1) DBC-Onderhoud 9 22

10 Note: Er worden in de grouper verschillende categorieën van bericht omvang onderscheiden. Binnen deze categorieën kunnen een bepaald aantal berichten worden verwerkt. Indien er geen capaciteit aanwezig is voor de verwerking van een bepaalde omvang, wordt er een SOAP error terug gestuurd met als errorcode DBC066. Eis: ziekenhuis systeem moet op basis van melding DBC066: Momenteel geen capaciteit voor berichten van deze omvang minimaal 600 sec wachten voor het bericht nogmaals kan worden opgestuurd. 3.3 HTTP (Laag 7) Eis: de ondersteunde protocol versie is HTTP/1.0 of HTTP/1.1, deze laatste is het meest gangbaar. Eis: Een library die gebruikt wordt, moet de minimaal volgende RFC betreffende cookies ondersteunen: RFC 6265 (HTTP State Management Mechanism). Eis: Een zorginstelling heeft ten hoogste 3 HTTP sessies tegelijk open naar de grouper Eis: Een HTTP sessie naar de grouper moet minimale time-out hebben van 300 seconden en een maximale time-out van 630 seconden. Advies: Indien het bericht een time-out oplevert, is het het ZIS toegestaan om een nieuw bericht sturen naar de grouper met eenzelfde Bericht id en met hetzelfde DeclaratieDatasetId. Advies: Indien er na 3 herhalingen geen antwoord is geretourneerd door de grouper, kan het ZIS een foutmelding geven aan de gebruiker van het systeem. Het is de verantwoording van het ziekenhuis om dit te monitoren. Als na drie herhalingen geen antwoord is geretourneerd door de grouper mag het ZIS later (na 15 minuten) nogmaals starten met drie pogingen. Eis: De HTTP header van het bericht dient voorzien te zijn van een geldige SOAP action. Op dit moment worden de volgende SOAP actions ondersteund (zie ook voorbeelden hoofdstuk 4): Service SOAP action Toelichting DBC.WS.Management DBC.WS.Declaraties gettock getdeclaratieresult02 Sturen van een ping t.b.v. verificatie bereikbaarheid. Sturen van een declaratie naar de grouper. DBC.WS.Declaraties Tabel: Services en SOAP-actions getdeclaratieresult03 Sturen van een declaratie naar de Grouper. DBC-Onderhoud 10 22

11 3.4 SSL/TLS (Laag 5 en 6) Eis: Voor het opzetten van de verbinding tussen het ZIS en de DBC grouper wordt gebruik gemaakt van tweezijdige authenticatie en versleuteling middels het SSL 3.0/TLS 1.0 (of hoger) protocol. Eis: De zorginstelling zet de sessie met de grouper op basis van de DNS-naam op. De grouper levert vervolgens het door PKI-Overheid uitgegeven servercertificaat aan. De zorginstelling dient te controleren of de Common Name (CN) in dit aangereikte servercertificaat overeenkomt met de DNS-naam in de aanroep en indien dit niet overeenkomt een waarschuwing naar de gebruiker te generen. Deze controle vindt meestal standaard al plaats in de SSL/TLS implementatie van de client. Eis: Het servercertificaat is uitgegeven door de 2e generatie (G2) van de PKIO CA-hierarchie. Deze certificaten zijn voorzien van het type SHA-2. Meer informatie hieromtrent is terug te vinden op webiste van PKI-Overheid. De zorginstelling dient de certificaatketen van grouper servercertificaat tot root-certificaat (Staat der Nederlanden Root CA) te valideren. Deze controle vindt meestal standaard al plaats in de SSL/TLS implementatie. De specifieke CA-keten is: Servercertificaat van de grouper Getronics CSP Organisatie CA G2 en/of KPN Corporate Market CSP Organisatie CA - G2 Staat der Nederlanden Organisatie CA G2 Staat der Nederlanden Root CA G2 Deze keten wordt door de grouper tijdens de SSL/TLS onderhandeling met het Grouperservercertificaat mee verstuurd maar het Root-certificaat dient reeds lokaal op het ZIS systeem aanwezig te zijn Het huidige grouper certificaat is uitgegeven door de Getronics CSP (Certificate Service Provider). KPN heeft als gevolg van de overname van Getronics een nieuwe KPN CA opgezet wat betekent dat eventuele nieuwe PKIO certificaten dan uitgegeven worden door deze KPN CA. De grouper zal dit nieuwe CA-certificaat na installatie tijdens de onderhandeling meesturen, zodat dit bij uitrol van een nieuw certificaat geen gevolgen heeft voor de ZIS-systemen. Eis: Tijdens de vervolgonderhandeling vraagt de grouper het ZIS om een UZI productie - of Vecozo server-certificaat zoals deze door het UZI register respectievelijk Vecozo verstrekt worden. De sessie wordt door de grouper afgebroken indien de ZIS geen certificaat aanlevert. Het UZI-register kent een G2 certificaatboom (SHA1 hash) en G21 (SHA2 hash) boom. Nieuwer uitgegeven certificaten zullen van het G21 type zijn. Meer informatie over ondersteuning van deze certificaten op systeemniveau is te vinden bij het UZI-Register (SHA-2 Technische vragen). Ook hierbij wordt aangesloten bij de praktijk binnen de AORTA architectuur. Bij gebruik van een Vecozo certificaat op het ZIS systeem dient het Vecozo G2 root certificaat lokaal op het ZIS systeem geplaatst te worden.. In het geval van een Vecozo testcertificaat dient het bijbehorende Vecozo TEST G2 root certificaat geplaatst te worden. Meer informatie over het gebruik van Vecozo certificaten is te vinden op de Vecozo website. DBC-Onderhoud 11 22

12 Eis: Indien de verzendende instelling een zorginstelling is dient deze te beschikken over een UZIservercertificaat en te zijn aangevraagd door de betreffende zorginstelling. Conditionele eis: Indien de verzendende instelling geen aanspraak kan maken op een registratie als abonnee van het UZI-register, omdat het een servicebureau betreft of een niet-nederlandse organisatie, dient deze te beschikken over een VECOZO-servercertificaat. Eis: Een zorginstelling heeft ten hoogste 3 SSL/TLS sessies tegelijk open naar de grouper Eis: Een SSL/TLS sessie naar de grouper mag ten hoogste 600 seconden open staan zonder dat er data getransporteerd wordt ( time-out ) DBC-Onderhoud 12 22

13 4 Toegang tot de grouper 4.1 Toegang tot de grouper Al het netwerkverkeer naar de Grouper wordt eerst gecontroleerd door een Firewall. Als het IP-adres van de afzender hier bekend is zal het verdere verkeer richting Grouper worden doorgelaten. Mocht het adres hier nog niet of niet meer bekend zijn dan wordt het verkeer verder tegengehouden en krijgt de afzender een foutmelding (afhankelijk van browser, netwerkomgeving etc.) Firewall Whitelist De Grouper gebruikt een zogenaamde whitelist van IP-adressen die mogen verbinden. In deze whitelist zijn IP-adressen opgenomen die door klanten van DBC-Onderhoud tijdens de aanmeldprocedure zijn aangemeld. Verbinden vanaf andere IP-adressen dan in de whitelist voorkomen is niet mogelijk Controle aanwezigheid van IP-adres in Firewall whitelist U kunt testen of het door u gebruikte IP-adres is opgenomen in de whitelist, door in de browser de URL van de betreffende omgeving in te typen: Omgeving Acceptatie Grouper Productie Grouper URL http(s)://acceptatie.dbcogrouper.nl/connection http(s)://productie.dbcogrouper.nl/connection Wanneer uw IP-adres in de whitelist is opgenomen, verschijnt daarna het volgende scherm met daarop oa. de melding: De verbinding is geslaagd. Let op: Voorwaarde voor het uitvoeren van deze controle met een https protocol is dat een geldig Vecozo of UZI-ceritifcaat is geïnstalleerd. Toegang tot de productieomgeving wordt pas verleend wanneer de volledige aanmeldprocedure is doorlopen. DBC-Onderhoud 13 22

14 5 SOAP-Actions 5.1 Inleiding De grouper heeft verschillende SOAP services voor het uitvoeren van zijn functionaliteit. InlezenBoomBestanden InlezenReferentieBestanden DBC.WS.InlezenBestanden InlezenZorgInstelling getdeclaratieresult02 Grouper Components:: Grouper (Mediator Pattern) gettock DBC.WS.Declaraties DBC.WS.Management getdeclaratieresult03 Figuur 3 SOAP De SOAP-Service DBC.WS.InlezenBestanden wordt alleen gebruikt door DBC-Onderhoud voor het bijwerken van de diverse standaard gegevens in de grouper. De rest van de services worden door de gebruikers van de grouper gebruikt De SOAP Service Een SOAP service is een vorm van een webpagina die gebruikt kan worden om data naar toe te sturen en te ontvangen op een standaard manier, op een vooraf gedefinieerde locatie. De definities van de webservice bestaat uit twee delen: 1) De Soap Location 2) De Soap Action Het is opgedeeld in twee delen, omdat het mogelijk is dat een bepaalde SOAP location meer dan één SOAP action ondersteunt. Een voorbeeld hiervan is de SOAP location DBC.WS.InlezenBestanden. DBC-Onderhoud 14 22

15 5.1.2 SOAP Location Dit is de plaats waar de data moet worden afgeleverd. De SOAP location bestaat uit een URL en de klasse die de Service gaat uitvoeren. Het is van belang om de juiste SOAP location te gebruiken, om te vorkomen dat de verkeerde data op de verkeerde plaats wordt afgeleverd SOAP Action De SOAP action is de functie die door de klasse, die verantwoordelijk is voor het uitvoeren van de functies op de SOAP location, kan worden uitgevoerd. Een SOAP location kan meerdere SOAP actions ondersteunen en door het meegeven van de SOAP action wordt aan de uitvoerende klasse aangegeven welke functie moet worden uitgevoerd URL Onderstaande tabel geldt voor alle SOAP-Actions. Omgeving Acceptatieomgeving Productieomgeving URL acceptatie.dbcogrouper.nl productie.dbcogrouper.nl Action: gettock Deze functie wordt gebruik voor het uitvoeren van een ping naar het systeem d.m.v. een Tick-Tock bericht. (COMT_IN113113NL) Voorbeeld: http header bij COMT_IN113113NLbericht Content-Type: text/xml; charset=utf-8 Content-Length: xxx (berichtlengte) SOAPAction: gettock Voorbeeld: COMT_IN113113NLbericht <?xml version="1.0" encoding="utf-8"?> <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:body> <!-- TICK Voorbeeld (Communication verification Request) --> <!--This is an example only. Examples are not normative, see the implementation guide for normative descriptions.--> <COMT_IN113113NL xmlns:xsi=" xsi:schemalocation="urn:hl7-org:v3../../../../dbc/databases/dbc0300/xml/schemas/comt_in113113nl.xsd" xmlns="urn:hl7-org:v3"> <id extension="200104" root=" "/> <creationtime value=" "/> DBC-Onderhoud 15 22

16 <versioncode code="nictized2005-okt"/> <interactionid extension="comt_in113113nl" root=" "/> <profileid root=" " extension="810"/> <processingcode code="t"/> <processingmodecode code="t"/> <!-- acceptackcode = AL in HL7 Tick interacties --> <acceptackcode code="al"/> <receiver> <device> <id extension="807" root=" "/> </device> </receiver> <sender> <device> <id extension="1" root=" "/> </device> </sender> <ControlActProcess moodcode="evn"> <effectivetime value=" "/> <authororperformer typecode="aut"> <participant> <AssignedDevice> <id extension=" " root=" "/> <Organization> <id extension=" " root=" "/> <name>tick test organisatie</name> </Organization> </AssignedDevice> </participant> </authororperformer> <!-- geen payload --> </ControlActProcess> </COMT_IN113113NL> </soap:body> </soap:envelope> DBC-Onderhoud 16 22

17 Ondersteunde SOAP Actions: Onderstaande tabel toont de SOAP actions die via deze service worden ondersteund. De beschikbaarheid van een webservice is gekoppeld aan de begindatum van het hoofdsubtraject. Indien deze niet in de aangegeven range valt (Begindatum Subtraject vanaf --- Begindatum Subtraject tot/met), is het niet toegestaan om deze webservice te gebruiken. SOAP Action Inbericht Uitbericht getdeclaratie FICR_IN FICR_IN910101_ Result02 _NL01 NL01 getdeclaratie FICR_IN FICR_IN910101_ Result03 _NL03 NL03 Begindatum Begindatum ZAZV ZPZA ZPZV Subtraject Subtraject Hash Hash Hash vanaf tot/met /1/ /12/ /01/ SOAP Action XSD Inbericht XSD Uitbericht Profile ID IH Versie getdeclaratie Result02 getdeclaratie Result03 FICR_IN900101_NL01.XSD FICR_IN910101_NL01.XSD FICR_IN900101_NL03.XSD FICR_IN910101_NL03.XSD DBC-Onderhoud 17 22

18 6 (Geen) Gebruik maken de WSDL Hoewel er bij de HL7 documenten een WSDL wordt aangeleverd, is deze niet binnen alle generatoren te gebruiken. Dit heeft te maken met de manier waarop de generatoren werken. Deze WSDL welke beschikbaar gesteld wordt voor de grouper is geen echte representatie van de webservice. De Webservice is veel eenvoudiger. Die verwacht niet meer dan alleen een string. Deze string is het FICR bericht. Het gevolg is dat het gebruikt van de WSDL geen inherente voordelen biedt. Het gebruik van alle generatoren is dus niet echt nodig. In de meeste gevallen is het eenvoudiger om het bericht handmatig op te bouwen. Als voorzet is een template bijgevoegd in HTML::KTemplate format: <?xml version="1.0" encoding="utf-8"?> <!-- IF SOAP --> <soap:envelope xmlns:soap=" xmlns:xsi=" xmlns:xsd=" <soap:body> <!-- END SOAP --> <FICR_IN900101NL01 xmlns:xsi=" xsi:schemalocation="urn:hl7-org:v3 file:/c:/dbc/databases/dbc0300/xml/schemas/ficr_in900101nl01.xsd" xmlns="urn:hl7-org:v3"> <id extension="[% DDSGUID %]" root=" "/> <creationtime value="[% CREATIONTIME %]"/> <versioncode code="nictized2005-okt"/> <interactionid extension="ficr_in900101nl01" root=" "/> <profileid root=" " extension="dot2010"/> <processingcode code="t" /> <processingmodecode code="t" /> <acceptackcode code="ne" /> <receiver> <device> <id extension="1" root=" "/> </device> </receiver> <sender> <device> <id root=" " extension="[% DDSURA %]" /> </device> </sender> <ControlActProcess moodcode="evn"> <effectivetime value="[% EFFECTIVETIME %]"/> <authororperformer typecode="aut"> DBC-Onderhoud 18 22

19 <participant> <AssignedDevice> <Organization> <id root=" " extension="[% DDSURA %]" /> </Organization> </AssignedDevice> </participant> </authororperformer> <overseer typecode="resp"> <AssignedPerson> <Organization> <id/> </Organization> </AssignedPerson> </overseer> <subject> <Declaratiedataset classcode="adjud" moodcode="rqo"> <id root=" " extension="[% DDSGUID %]"/> <code codesystem=" " code="grouper"/> <statuscode code="active"/> <author typecode="aut"> <assignedorganization> <id root=" " extension="[% DDSORG %]"/> </assignedorganization> </author> <subject typecode="sbj"> <patient classcode="pat"> <patientperson> <administrativegendercode codesystem=" " code="[% DDSGSL %]"> <translation codesystem=" " code="[% DDSGSLINT %]" /> </administrativegendercode> </patientperson> <subjectof typecode="sbj"> <leeftijd classcode="obs" moodcode="evn"> <code codesystem=" " code="leeftijd"/> <value xsi:type="int" value="[% DDSAGE %]"/> </leeftijd> </subjectof> DBC-Onderhoud 19 22

20 </patient> </subject> <!-- BEGIN SUBTRAJECT --> <component typecode="comp"> <!-- IF PNUMMER --> <prioritynumber value="1"/> <!-- END PNUMMER --> <subtraject classcode="acct" moodcode="evn"> <id root=" " extension="[% STNUMMER %]"/> <code codesystem=" " code="[% ZTCODE %]"/> <statuscode code="completed"/> <effectivetime> <low value="[% STELOW %]"/> <!-- IF STEHIGH --> <high value="[% STEHIGH %]"/> <!-- END STEHIGH --> </effectivetime> <!-- BEGIN Zorgactiviteit --> <debit typecode="debit"> <zorgactiviteit classcode="xact" moodcode="evn"> <id root=" " extension="[% UZAID %]"/> <code codesystem=" " code="[% UZACODE %]"/> <effectivetime value="[% UZADATE %]"/> <repeatnumber value="[% UZAREPEAT %]"/> <performer typecode="prf"> <assignedperson classcode="assigned"> <code codesystem=" " code="[% UZAUIT %]"/> <!-- IF UITORG --> <Organization> <id extension="[% UITORG %]"/> </Organization> <!-- END UITORG --> </assignedperson> </performer> <infulfillmentof typecode="flfs"> <aanvraag classcode="act" moodcode="rqo"> DBC-Onderhoud 20 22

21 <author typecode="aut"> <assignedperson classcode="assigned"> <code codesystem=" " code="[% UZAAAN %]"/> <!-- IF AANORG --> <Organization> <id extension="[% AANORG %]"/> </Organization> <!-- END AANORG --> </assignedperson> </author> </aanvraag> </infulfillmentof> </zorgactiviteit> </debit> <!-- END Zorgactiviteit --> <derivedfrom typecode="driv"> <zorgtraject> <id root=" " extension="[% STDZN %]"/> <responsibleparty> <assignedperson> <code codesystem=" " code="[% STSPEC %]"/> </assignedperson> </responsibleparty> <!-- IF ZORGVRAAG --> <reason> <zorgvraag> <code codesystem=" " code="zorgvraag"/> <value codesystem=" " code="[% ZORGVRAAG %]"/> </zorgvraag> </reason> <!-- END ZORGVRAAG --> </zorgtraject> </derivedfrom> <pertinentinformation1 typecode="pert"> <prioritynumber value="1"/> <typerendediagnose classcode="obs" moodcode="evn"> <code codesystem=" " code="dx"/> <value codesystem=" " code="[% TYPEDIAG %]"/> DBC-Onderhoud 21 22

22 </typerendediagnose> </pertinentinformation1> <subjectof> <afsluiting> <code codesystem=" " code="afsluiting"/> <!-- if AFSLUITING --> <reasoncode codesystem=" " code="[% AFSLUITING %]"/> <!-- END AFSLUITING --> </afsluiting> </subjectof> </subtraject> </component> <!-- END SUBTRAJECT --> <subjectof typecode="subj"> <aanspraakzvw classcode="obs" moodcode="evn"> <code codesystem=" " code="aanspraak"/> <!-- if AANSPRAAK --> <value value = "[% AANSPRAAK %]"/> <!-- ELSE AANSPRAAK --> <value nullflavor="unk"/> <!-- END AANSPRAAK --> </aanspraakzvw> </subjectof> </Declaratiedataset> </subject> </ControlActProcess> </FICR_IN900101NL01> <!-- IF SOAP --> </soap:body> </soap:envelope> <!-- END SOAP --> DBC-Onderhoud 22 22