De presentatie wordt gedownload. Even geduld aub

De presentatie wordt gedownload. Even geduld aub

Nieuwe eHealth-toepassingen voor ziekenhuizen Frank Robben Administrateur-generaal eHealth-platform Sint-Pieterssteenweg 375 B-1040 Brussel

Verwante presentaties


Presentatie over: "Nieuwe eHealth-toepassingen voor ziekenhuizen Frank Robben Administrateur-generaal eHealth-platform Sint-Pieterssteenweg 375 B-1040 Brussel"— Transcript van de presentatie:

1 Nieuwe eHealth-toepassingen voor ziekenhuizen Frank Robben Administrateur-generaal eHealth-platform Sint-Pieterssteenweg 375 B-1040 Brussel Website eHealth-platform: https://www.ehealth.fgov.behttps://www.ehealth.fgov.be Persoonlijke website:

2 Raadpleging van het Rijksregister en van de KSZ-registers Algemeen overzicht

3 3 08/10/2009 Rijksregister: wat?  persoonsgegevensbank met basisidentificatiegegevens  over natuurlijke personen ingeschreven in de bevolkingsregisters en vreemdelingenregisters van de gemeenten in de registers van de diplomatieke zendingen en de consulaire posten in het wachtregister van de kandidaat - politieke vluchtelingen  beheerd door de FOD Binnenlandse Zaken  bevat onder meer per betrokkene rijksregisternummer naam voornamen geslacht geboorteplaats geboortedatum overlijdensdatum hoofdverblijfplaats

4 4 08/10/2009 Kruispuntbankregisters: wat?  persoonsgegevensbank met basisidentificatiegegevens  over natuurlijke personen die niet zijn ingeschreven in het Rijksregister of van wie niet alle gegevens systematisch worden bijgewerkt in het Rijksregister  voor zover hun identificatie vereist is voor het toepassen van de sociale zekerheid voor het uitvoeren van de opdrachten van de Belgische overheid voor het vervullen van de taken van algemeen belang -van natuurlijke personen -van openbare of private instellingen van Belgisch recht  beheerd door de Kruispuntbank van de Sociale Zekerheid  bevat onder meer per betrokkene identificatienummer van de sociale zekerheid (zie verder) naam voornamen geslacht geboorteplaats geboortedatum overlijdensdatum hoofdverblijfplaats

5 5 08/10/2009 Verhouding tussen beide  de Kruispuntbankregisters zijn complementair ten opzichte van het Rijksregister: de Kruispuntbankregisters vormen een aanvulling op het Rijksregister en worden enkel gebruikt wanneer het Rijksregister de gewenste persoonsgegevens niet of niet meer kan leveren  de Kruispuntbankregisters zijn subsidiair ten opzichte van het Rijksregister: er moet prioriteit worden gegeven aan het Rijksregister van zodra over een persoon persoonsgegevens worden opgeslagen en geactualiseerd in het Rijksregister  er vindt een regelmatige synchronisatie tussen beide persoonsgegevensbanken plaats

6 6 08/10/2009 Identificatienummer van de sociale zekerheid  als een natuurlijke persoon over een rijksregisternummer beschikt gebruik van het rijksregisternummer als unieke identificatiesleutel ook al bevindt de betrokkene zich inmiddels in de Kruispuntbankregisters voor het gebruik van het rijksregisternummer is een machtiging van het sectoraal comité van het Rijksregister vereist  als een natuurlijke persoon niet over een rijksregisternummer beschikt gebruik van een door de Kruispuntbank van de Sociale Zekerheid toegekend identificatienummer als unieke identificatiesleutel tot op het ogenblik dat de betrokkene eventueel alsnog een rijksregisternummer zou toegekend krijgen het gebruik van het identificatienummer toegekend door de Kruispuntbank van de Sociale Zekerheid is vrij

7 7 08/10/2009 Toegang (1/2)  is beperkt tot bepaalde categorieën bestemmelingen o.a. de openbare en private instellingen van Belgisch recht voor de informatie die zij nodig hebben voor het vervullen van hun taken van algemeen belang (→ ziekenhuizen)  vereist een machtiging van het bevoegde sectoraal comité van de Commissie Bescherming Persoonlijke Levenssfeer  toegang tot het Rijksregister sectoraal comité van het Rijksregister voor ziekenhuizen: beraadslaging nr. 21/2009 van 25 maart 2009 (zie https://www.ehealth.fgov.be/binaries/website/nl/pdf/beraadslaging_RR_0 21_ pdf) https://www.ehealth.fgov.be/binaries/website/nl/pdf/beraadslaging_RR_0 21_ pdf  toegang tot de Kruispuntbankregisters sectoraal comité van de sociale zekerheid en van de gezondheid voor ziekenhuizen: beraadslaging nr. 09/39 van 7 juli 2009 (zie https://www.ehealth.fgov.be/binaries/website/nl/pdf/ n NL.pdf) https://www.ehealth.fgov.be/binaries/website/nl/pdf/ n NL.pdf

8 8 08/10/2009 Toegang (2/2)  algemene machtiging voor ziekenhuizen toegang tot bepaalde persoonsgegevens van het Rijksregister en de Kruispuntbankregisters (identificatienummer, naam, voornamen, geslacht, geboorteplaats, geboortedatum, overlijdensdatum en hoofdverblijfplaats) gebruik van het identificatienummer  voorwaarden (zie verder) slechts voor welbepaalde doeleinden geen onbeperkte bewaring van de persoonsgegevens beperking van de toegang tot de persoonsgegevens via een beveiligd platform  verplichtingen (zie verder) overmaken van documenten aan sectoraal comité en eHealth-platform aanduiden van een informatieveiligheidsconsulent uitwerken van een informatieveiligheidsbeleid  voor meer informatie: zie portaalsite eHealth-platform https://www.ehealth.fgov.be/nl/page_menu/website/home/platform/sourc es/nationalregister.htmlhttps://www.ehealth.fgov.be/nl/page_menu/website/home/platform/sourc es/nationalregister.html

9 9 08/10/2009 Voorwaarden (1/2)  slechts voor welbepaalde doeleinden controleren/actualiseren van identificatiegegevens van patiënten ondubbelzinnige identificatie van patiënten in het medisch dossier facturatiebeheer  bewaartermijn ziekenhuisdiensten die instaan voor registratie en beheer van het medisch dossier -tot 30 jaar na het laatste contact met de patiënt ziekenhuisdiensten die instaan voor facturering en/of invordering -niet langer dan tot het einde van de invorderingsprocedure -en niet langer dan de wettelijke verjaringstermijn van de rechtsvorderingen van zorgverstrekkers voor de door hen geleverde prestaties (= 2 jaar te rekenen vanaf het einde van de maand waarin de prestaties werden geleverd)

10 10 08/10/2009 Voorwaarden (2/2)  beperking van de toegang tot bepaalde personeelsleden aantal personeelsleden tot een minimum beperken hen een vertrouwelijkheidsverklaring laten ondertekenen opstellen, actualiseren en ter beschikking houden van een lijst van personeelsleden die om functionele redenen daadwerkelijk toegang hebben  via een beveiligd platform het eHealth-platform of een ander platform dat vergelijkbare waarborgen inzake informatieveiligheid biedt en onderworpen is aan de controle van het sectoraal comité van de sociale zekerheid en van de gezondheid (bestaat vandaag niet)

11 11 08/10/2009 Verplichtingen  overmaken van bepaalde documenten aan het sectoraal comité van de sociale zekerheid en van de gezondheid schriftelijke en ondertekende verbintenis tot instemming met de voorwaarden van de beraadslaging kopie van de beslissing tot erkenning van één of meerdere ziekenhuisdiensten evaluatieformulier aangaande de referentiemaatregelen voor de beveiliging van de verwerking van persoonsgegevens -inlichtingen over de informatieveiligheidsconsulent (zie verder) -inlichtingen over het informatieveiligheidsbeleid (zie verder) https://www.ehealth.fgov.be/binaries/website/nl/doc/Brief-template-NL- Final.dochttps://www.ehealth.fgov.be/binaries/website/nl/doc/Brief-template-NL- Final.doc  overmaken van een verzoek aan het eHealth-platform verzoek inzake gebruik van webservices (zie verder) overmaken aan de dienst Programma-, Project- en Klantenbeheer bekomen van een eHealth-certificaat (identificatie/authenticatie) testen https://www.ehealth.fgov.be/binaries/website/nl/pdf/Verzoek-om- toestemming-voor-gebruik.pdfhttps://www.ehealth.fgov.be/binaries/website/nl/pdf/Verzoek-om- toestemming-voor-gebruik.pdf

12 12 08/10/2009 Inlichtingen informatieveiligheidsconsulent  identiteit en contactgegevens  opleiding en kwalificaties  beschrijving van de functie  plaats in de organisatie  tijd te besteden aan de functie  eventuele andere (niet onverenigbare) functies

13 13 08/10/2009 Inlichtingen informatieveiligheidsbeleid (1/2) 1.gebruik maken van de diensten van een informatieveiligheidsconsulent 2.evalueren van risico’s en veiligheidsbehoeften op het vlak van de verwerking van persoonsgegevens 3.bijhouden van een geschreven versie van het informatieveiligheidsbeleid 4.identificeren van de diverse dragers waarop persoonsgegevens worden verwerkt 5.informeren van de personeelsleden over hun vertrouwelijkheids- en veiligheidsplichten 6.nemen van maatregelen tegen niet-gemachtigde of onnodige toegang tot persoonsgegevens 7.nemen van maatregelen tegen fysieke schade die persoonsgegevens in gevaar zou kunnen brengen

14 14 08/10/2009 Inlichtingen informatieveiligheidsbeleid (2/2) 8.nemen van maatregelen ter bescherming van de verschillende geconnecteerde netwerken 9.beschikken over een actuele lijst van personen die toegang hebben tot persoonsgegevens en hun toegangsniveau 10.installeren van een mechanisme voor toegangsmachtiging op de informatiesystemen 11.beschikken over een systeem van registratie van de personen die toegang hebben tot de persoonsgegevens 12.controleren van de geldigheid en de doeltreffendheid in de tijd van de organisatorische en technische maatregelen 13.beschikken over urgentieprocedures in geval van veiligheidsincidenten 14.beschikken over een bijgewerkte documentatie betreffende de veiligheidsmaatregelen

15 15 08/10/2009 Webservices 1.IdentifyPerson opzoeking van persoonsgegevens op basis van het identificatienummer van de sociale zekerheid van de patiënt naam, voornamen, geslacht, geboorteplaats, geboortedatum, overlijdensdatum, hoofdverblijfplaats en de historiek van de wijzigingen (voor de sociale dienst van het ziekenhuis) 2.PhoneticSearch opzoeking van dezelfde persoonsgegevens op basis van (eventueel zelfs onvolledige) fonetische criteria van de patiënt (naam, voornaam, geboortedatum) 3.ManageInscription toevoeging/verwijdering van een bepaalde patiënt (geïdentificeerd met zijn identificatienummer van de sociale zekerheid) aan/uit de abonnementsdienst het ziekenhuis kan zo de mutaties (= wijzigingen van de beschikbare persoonsgegevens) ontvangen 4.MutationSender dagelijks ter beschikking stellen van de mutaties (= wijzigingen van de beschikbare persoonsgegevens) aan het ziekenhuis 5.PersonHistory opzoeking van de historiek van de mutaties van de beschikbare persoonsgegevens

16 16 08/10/2009 Andere behoeften?  eHealth-platform biedt geïntegreerde toegang tot bepaalde persoonsgegevens uit Rijksregister en Kruispuntbankregisters (zie hoger)  Rijksregister en Kruispuntbankregisters bevatten echter ook nog andere persoonsgegevens nationaliteit plaats van overlijden beroep burgerlijke staat wettelijke samenwoning gezinssamenstelling vermelding van het betrokken register administratieve toestand van kandidaat - politieke vluchtelingen verblijfstoestand van vreemdelingen  eventuele behoeften kunnen voor verder (juridisch / praktisch) onderzoek aan het eHealth-platform gemeld worden

17 17 08/10/2009 Informatieveiligheidsmaatregelen  eHealth-platform zal een overleg met de ziekenhuizen organiseren  « overlegstructuur » zal de ziekenhuizen bijstaan bij het opstellen en implementeren van informatie- veiligheidspolicies

18 Raadpleging van het Rijksregister en van de KSZ-registers Technische aspecten en procedure

19 19 08/10/2009 Overzicht  webservice RN Consult  webservice IdentifyPerson  webservice PhoneticSearch  webservice ManageInscription  webservice MutationSender  webservice PersonHistory  protocol  overzicht van de architectuur  contact  procedure  eHealth-certificaten

20 20 08/10/2009 WebService RN Consult  de webservice RN Consult bestaat uit 5 onafhankelijke subwebservices: IdentifyPerson: identificatie van een natuurlijke persoon aan de hand van het INSZIdentifyPerson PhoneticSearch: identificatie van een natuurlijke persoon op basis van fonetische criteriaPhoneticSearch ManageInscription: invoeging in en verwijdering uit de abonnementendienstManageInscription MutationSender: beschikbaarstelling van mutatiesMutationSender PersonHistory: beschikbbaarstelling van de historiek van de gegevens van het Rijksregister en van de Kruispuntbank- registers

21 21 08/10/2009 WebService IdentifyPerson  via de webservice ‘IdentifyPerson’ kan een ziekenhuis de gegevens in het Rijksregister en in de Kruispuntbank- registers raadplegen voor een patiënt aan de hand van diens INSZ (identificatienummer van de sociale zekerheid)  op basis van het door het ziekenhuis ingegeven INSZ vraagt de webservice ‘IdentifyPerson’ de volgende gegevens op: de naam en voorna(a)m(en) de geboortedatum en -plaats het geslacht de hoofdverblijfplaats de datum van overlijden

22 22 08/10/2009 WebService IdentifyPerson Request

23 23 08/10/2009 WebService IdentifyPerson  For example:    NIHII  HOSPITAL   xxxxxxxxxxx   xxxxxxxxxxx  1    

24 24 08/10/2009 WebService IdentifyPerson Reply

25 25 08/10/2009 WebService IdentifyPerson 100 Success JEMEPPE-SUR- SAMBRE

26 26 08/10/2009 WebService IdentifyPerson PERSONNE TEST UNKNOWN STRAAT ONBEKEND ANTWERPEN 150 BELGIË

27 27 08/10/2009 WebService PhoneticSearch  aan de hand van de webservice ‘PhoneticSearch’ kan een ziekenhuis in het Rijksregister en in de Kruispuntbank-registers de gegevens van een patiënt raadplegen op basis van diens naam en geboortedatum  op basis van de « fonetische » criteria (naam, voornaam, geboortedatum), ook al zijn ze niet volledig, tracht de webservice ‘PhoneticSearch’ de volgende gegevens op te halen : de naam en voorna(a)m(en) de geboortedatum en -plaats het geslacht de hoofdverblijfplaats de datum van overlijden

28 28 08/10/2009 WebService ManageInscription  aan de hand van de webservice ‘ManageInscription’ kan een ziekenhuis een patiënt inschrijven of uitschrijven op de abonnementendienst voor de mutaties  voor het ziekenhuis is het de bedoeling om de bijwerkingen van de verschillende beschikbare gegevens te krijgen  om een inschrijving toe te voegen of te verwijderen deelt het ziekenhuis het INSZ (identificatienummer van de sociale zekerheid) van een persoon mee alsook de periode waarin hij de mutaties gedurende 6 maanden wenst te ontvangen  wanneer het ziekenhuis deze periode wenst te verlengen, voegt hij de nieuwe gewenste periode toe  indien het ziekenhuis deze periode wenst in te korten, verwijdert het de overbodige periode

29 29 08/10/2009 WebService MutationSender  aan de hand van de webservice ‘MutationSender’ kan een ziekenhuis de wijzigingen met betrekking tot de beschikbare gegevens ontvangen  het eHealth-platform stelt dagelijks een bestand ter beschikking van het ziekenhuis waarin alle wijzigingen van de voor zijn patiënten beschikbare gegevens zijn opgenomen.  dit bestand blijft beschikbaar gedurende 60 dagen

30 30 08/10/2009 WebService PersonHistory  aan de hand van de webservice ‘PersonHistory’ kan een sociale dienst van een ziekenhuis de historiek van de gegevens in het Rijksregister en in de Kruispuntbank-registers voor een patiënt raadplegen aan de hand van een INSZ (identificatienummer van de sociale zekerheid)  op basis van het door het ziekenhuis ingegeven INSZ haalt de webservice ‘PersonHistory’ naar keuze de volgende gegevens op: historiek van de naam en van de voorna(a)m(en) historiek van de geboortedatum en -plaats historiek van het geslacht historiek van de hoofdverblijfplaats historiek van de datum van overlijden  met betrekking tot de registratie en het beheer van het medisch dossier kunnen voormelde gegevens gedurende een periode van 30 jaar na het laatste contact met de patiënt worden bewaard  met betrekking tot de facturatie bedraagt de bewaarduur van voormelde gegevens 2 jaar te rekenen vanaf het einde van de maand waarin de medische verstrekkingen werden verricht

31 31 08/10/2009 Overzicht van de architectuur

32 32 08/10/2009 Overzicht van de architectuur

33 33 08/10/2009 Protocol  voor de veiligheid van de webservices worden de standaardnormen gehanteerd: SSL one way een X.509-certificaat. Het bevat het identificatiemiddel van de aanroeper: RIZIV-nummer of KBO-nummer -voor meer info over de inhoud van de certificaten en over de manier om een dergelijk certificaat te ontvangen: https://www.ehealth.fgov.be/nl/page_menu/website/home/platform/basicservi ces/certificates.html https://www.ehealth.fgov.be/nl/page_menu/website/home/platform/basicservi ces/certificates.html levensduur van een bericht : één minuut op basis van de handtekening van de timestamp, de body en de binary security token kan het eHealth-platform de integriteit van het bericht en de identiteit van de verzender van het bericht nagaan geen encryptie van het bericht

34 34 08/10/2009 Integratieprocedure  het ziekenhuis dat de webservice in één van zijn toepassingen wenst te integreren moet een schriftelijke verbintenis aan het sectoraal comité van de sociale zekerheid en van de gezondheid overmaken waarin het verklaart de in de beraadslaging beschreven voorwaarden te aanvaarden, samen met een in te vullen evaluatieformulier over de referentie-maatregelen inzake veiligheideen schriftelijke verbintenis aan het sectoraal comité van de sociale zekerheid en van de gezondheidwaarin het verklaart de in de beraadslaging beschreven voorwaarden te aanvaarden een machtigingsaanvraag voor het gebruik van eHealth- webservices indienen deze aanvraag gebeurt aan de hand van het formulier dat door het ziekenhuis moet worden ingevuld en waarin het aanduidt tot welke webservices het toegang wenstformulier het ingevulde formulier moet naar het volgende adres worden verstuurd: eHealth-platform, dienst PPKB, Sint-Pietersteenweg 375 te 1040 Brussel

35 35 08/10/2009 Integratieprocedure  na het eerste contact met de dienst PPKB, volgt de integratie met de volgende stappen: het eHealth-platform biedt technische ondersteuning (cookbook’s, url's van de testdiensten, WSDL) aan het IT-contactpunt van het ziekenhuis dat wordt aangeduid er moet een integratieplan worden meegedeeld aan eHealth ontwikkeling op het niveau van het ziekenhuis het ziekenhuis test zijn klant, eerst met een testdienst indien test met mock-up service afdoend is, mag het ziekenhuis de eHealth- acceptieomgeving gebruiken om zijn integratie- en functionele testen uit te voeren (testduur minimaal : 1 maand) eHealth levert geen test case, eHealth raadt echter aan om de testen uit te voeren die worden vermeld in het testverslag van de dienst PPKB indien de acceptatietesten afdoende zijn, stuurt het ziekenhuis zijn testresultaten aan de hand van het formulier dat hij van de dienst PPKB heeft gekregen op naar het adres indien alles OK is, spreken eHealth en het ziekenhuis een datum van inproductiestelling af. eHealth zou de aansluiting op de productieomgeving moeten voorbereiden en het URL van de productieomgeving moeten meedelen aan het ziekenhuis tijdens de dag van inproductiestelling levert het ziekenhuis feed-back over het resultaat van de inproductiestellingtesten aan  er wordt technische ondersteuning geboden door eHealth:

36 36 08/10/2009 Contact  contact dienst PPKB   technisch contact RN Consult 

37 37 08/10/2009 eHealth-certificaat Belangrijk: het eHealth-certificaat kan voor meerdere toepassingen worden gebruikt

38 Het elektronisch geneesmiddel- voorschrift (ePrescription) binnen ziekenhuizen Algemeen overzicht

39 39 08/10/2009 Elektronisch voorschrift binnen ziekenhuizen  medische voorschriften zijn onderworpen aan talloze voorwaarden wat betreft vorm en inhoud  essentieel: elk voorschrift moet worden ondertekend en gedagtekend door de voorschrijver, al dan niet elektronisch  wat betreft het voorschrift binnen ziekenhuizen is een afwijking mogelijk: gebruik van een elektronisch document zonder elektronische handtekening van de voorschrijver doch met tijdsregistratie en garantie van integriteit door een bevoegde instantie, bv. het eHealth-platform

40 40 08/10/2009 Functionaliteiten  functionaliteiten waaraan ieder elektronisch voorschrift moet voldoen: authenticatie van de identiteit en verificatie van de hoedanigheid van de voorschrijver elektronische datering binnen korte termijn na het opmaken van het voorschrift systeem dat waarborgt dat het voorschrift niet meer onmerkbaar gewijzigd kan worden na de toepassing van de elektronische datering en van de methode voor het waarborgen van de integriteit opsporen van wie wanneer welke verwerking heeft verricht met betrekking tot het aanmaken van het voorschrift (bijgehouden gedurende een vastgelegde periode) mogelijkheid tot locale validatie en verificatie van de inhoud van het voorschrift en van het feit dat het voorschrift na het toepassen van de methode voor het waarborgen van de integriteit niet gewijzigd is

41 41 08/10/2009 Voorwaarden voor een elektronisch voorschrift  het betreft momenteel enkel het geneesmiddelenvoorschrift van de geneesheer en de tandarts binnen ziekenhuizen, dus voor intern gebruik ten aanzien van de ziekenhuisapotheek  binnen ieder ziekenhuis moet een overeenkomst worden afgesloten tussen het ziekenhuis en iedere voorschrijver dat het volgende omvat: de beschrijving van de procedure voor de authenticatie van de voorschrijver de beschrijving van de procedure voor de elektronische datering en het waarborgen van de integriteit van het elektronisch document

42 42 08/10/2009 Voorwaarden voor een elektronisch voorschrift  de procedure van elektronische datering en de methode van het waarborgen van de integriteit moet voldoen aan de voorwaarden opgenomen in een protocol dat werd goedgekeurd door de bevoegde overeenkomsten- commissie in de schoot van het RIZIV  voor het gebruik van het eHealth-platform als dienst voor elektronische datering werd een dergelijk protocol goedgekeurd dat volgende procedures omvat procedure ter authenticatie van de voorschrijver -de authenticatie van de identiteit van de voorschrijver geschiedt locaal, binnen het ziekenhuis -de authenticatie kan door middel van  een gebruikersnaam en paswoord, of  het authenticatiecertificiaat op de eID of een ander geldig certificaat

43 43 08/10/2009 Voorwaarden voor een elektronisch voorschrift procedure voor elektronische datering en de methode voor het waarborgen van de integriteit -het ziekenhuis maakt het voorschrift aan met de eigen software  vermelding van geauthenticeerde identiteit van voorschrijver  vermelding van alle benodigde gegevens mbt het voorschrift -het ziekenhuis past een hashing procedure toe op elk voorschrift -de hashresultaten (dus niet het inhoudelijk voorschrift zelf!) worden periodiek gegroepeerd (in een ‘timestamp bag’) en overgemaakt aan de dienst voor elektronische datering van het eHealth-platform -de dienst voor elektronische datering van het eHealth-platform voert een elektronische datering uit en ondertekent het resultaat elektronisch -de aan de elektronische datering onderworpen en elektronisch ondertekende hashresultaten worden teruggestuurd naar het ziekenhuis -het ziekenhuis slaat het elektronisch voorschrift en de elektronisch gedateerde en elektronisch ondertekende hashresultaten op in haar archief -het ziekenhuis voorziet dat de elektronische voorschriften kunnen worden gelezen gedurende een periode van 10 jaar

44 44 08/10/2009 Voorwaarden voor een elektronisch voorschrift procedure van elektronische datering en de methode voor het waarborgen van de integriteit (vervolg) -het eHealth-platform archiveert eveneens alle elektronisch gedateerde en elektronisch ondertekende hashresultaten teneinde de betrokken partijen bij te staan in geval van betwistingen -zowel het ziekenhuis zelf als de controle-instanties beschikken over de mogelijkheid om de elektronische voorschriften opnieuw te hashen en na te gaan of het hashresultaat overeenkomt met het hashresultaat dat door het eHealth-platform elektronisch werd gedateerd en ondertekend, indien dit het geval is, dan heeft men de zekerheid dat het voorschrift niet werd gewijzigd

45 45 08/10/2009 Voorwaarden voor een elektronisch voorschrift Ziekenhuis voorschrift A 1 hashcode A eHealth-platform 2 hashing voorschrift B hashcode B timestamp bag 3 elektronische datering 4 elektronische handtekening 5 archief 6 6

46 46 08/10/2009 Voorwaarden voor een elektronisch voorschrift  het elektronisch voorschrift binnen ziekenhuizen met toepassing van de procedure voor tijdsregistratie door het eHealth-platform voldoet aan alle functionele vereisten: de authenticatie van de voorschrijver wordt toevertrouwd aan het ziekenhuis zelf elektronische datering op korte termijn na het opmaken van het voorschrift gebruik van de hashingprocedure en elektronische handtekening van het eHealth-platform waarborgt dat het voorschrift niet meer onmerkbaar gewijzigd kan worden archivering door het eHealth-platform van alle elektronisch gedateerde en ondertekende hashresultaten voor latere betwistingen

47 47 08/10/2009 Voorwaarden voor een elektronisch voorschrift  deze werkwijze is een treffend voorbeeld van out-of-the- box denken waarbij de voordelen van de informatisering worden gecombineerd met de garanties van authenticiteit en integriteit, met inbegrip van een geldige tijdsaanduiding  dit model kan evenwel worden toegepast op tal van andere attesten en documenten in de gezondheidszorg

48 48 08/10/2009 Voorwaarden voor een elektronisch voorschrift  juridische teksten (www.juridat.be)www.juridat.be koninklijk besluit nr. 78 van 10 november 1967 betreffende de uitoefening van de gezondheidsberoep, B.S. 14 november 1967 koninklijk besluit van 7 juni 2009 tot regeling van het elektronisch document ter vervanging, binnen de ziekenhuizen, van de voorschriften van de bevoegde geneesheer en van de bevoegde beoefenaar van de tandheelkunde, in uitvoering van artikel 21, tweede lid, van het koninklijk besluit nr. 78 van 10 november 1967 betreffende de uitoefening van de gezondheidsberoepen, B.S. 1 juli 2009

49 49 08/10/2009 Het elektronisch geneesmiddelen- voorschrift (ePrescription) binnen ziekenhuizen Technische aspecten en procedure

50 50 08/10/2009 Overzicht  overzicht van de architectuur  details van de architectuur timestamp bags protocol tussen timestamp klanten et timestamp server beheer van de verschillende klinische systemen binnen eenzelfde ziekenhuis overzicht van de archivering keuze van de sleutellengte voor de digitale handtekening en het hashingalgoritme functionaliteiten van timestamp visualiseren aanmaken van een nieuw controledocument en van een document voor de weergave van de plug-ins  installatie van de referentie-implementatie  eHealth-certificaten  contact + testprocedure

51 51 08/10/2009 Overzicht van de architectuur

52 52 08/10/2009 Hashing-algoritme  alvorens de timestamping te kunnen gebruiken, moet het ziekenhuis een hashing-procedure toepassen op de gegevens (het voorschrift)  om de beveiligde informatie tot in 2030 te kunnen bewaren, moet de hashing op zijn minst met een Secure Hash Algorithm (SHA) 224 gebeuren  wat de referentie-implementatie betreft, werd beslist dat het ziekenhuis derhalve binnen zijn informaticasysteem over een hashing tool moet beschikking die op libraries met SHA 256 algoritmes is gebaseerd  de libraries van deze algoritmes zijn vervat in de verschillende componenten die via de referentie- implementatie worden aangeleverd

53 53 08/10/2009 Timestamp bags

54 54 08/10/2009 Protocol timestamp client - timestamp server  protocol Oasis-DSS volgens het timestampprofiel (zie  de ziekenhuizen hebben toegang tot de timestampserver van het eHealth-platform via het internet  in een eerste toegangscontrolelaag zal het eHealth-platform enkel verbindingen via gekende IP-adressen aanvaarden  op die manier wordt onze dienst zo veel mogelijk tegen aanvallen beschermd.  in een tweede toegangscontrolelaag moet de timestamprequest door de client timestamp worden ondertekend  enkel de ondertekende requests waarvan een certificaat bij het eHealth-platform werd geregistreerd, zullen worden behandeld.  de 'distinguished name' van de handtekening zal worden gebruikt om de vragende client timestamp te identificeren  het proces wordt in detail uitgelegd in het WSDL-bestand van de timestampdienst van het platform

55 55 08/10/2009 Beheer van de verschillende klinische systemen van eenzelfde ziekenhuis

56 56 08/10/2009 Beheer van de verschillende klinische systemen van eenzelfde ziekenhuis

57 57 08/10/2009 Overzicht van de archivering  het trusted archief van het eHealth-platform de timestampserver bewaart alle requests en antwoorden in een archief; deze archieven worden gedurende een periode X bewaard en het ziekenhuis moet ook de berichten archiveren die "gestimestampt" werden (30 jaar, 5 jaar online)  de timestampelementen op de afbeelding vertegenwoordigen de volledige tijdstempel zoals die door de timestampdienst werd geleverd; deze bevat minstens: de hashcode van de TSBag de datum en het uur van de timestamp, gegenereerd door de timestampserver een timestampvolgnummer, door de timestampserver gegenereerd de digitale handtekening van al deze gegevens, door de timestampserver gegenereerd

58 58 08/10/2009 Overzicht van de archivering

59 59 08/10/2009 Overzicht van de archivering  de ziekenhuizen en het eHealth-platform zullen de archieven moeten bewaren die garanderen dat het ziekenhuislogboek, de TSBags en de timestamps op een beveiligde wijze en volledig ongewijzigd worden opgeslagen zolang het ziekenhuislogboek wordt bewaard  zowel het ziekenhuis als de archieven van het eHealth-platform zullen de identificatie van de vragende client timestamp, de datum en het uur van de timestamp en het volgnummer van de timestamp als sleutels gebruiken om toegang te hebben tot de archieven. Op die manier kunnen de twee archieven gemakkelijk door de inspectiediensten worden vergeleken.  periode van archivering: het logboek van de ingangen, de TSBags en de timestamps zullen gedurende 30 jaar moeten worden gearchiveerd

60 60 08/10/2009 Sleutellengte digitale handtekening  bij de eerste versie van de timestampdienst van het eHealth-platform zal een sleutellengte van 2048 bits worden gebruikt voor de digitale handtekening van de timestamps

61 61 08/10/2009 Functionaliteiten timestamp visualiseren

62 62 08/10/2009 Functionaliteiten timestamp visualiseren

63 63 08/10/2009 Inspectiedienst RIZIV - Timestamping  de inspectiedienst zal verder dezelfde informatie vragen als die hij nu vraagt  de inspectiedienst zal eveneens bepaalde elementen van de referentie-implementatie gebruiken om hun controle te verrichten: 'de weergave'  de inspecteur zal aan het ziekenhuis een uittreksel uit het logboek kunnen vragen, het kunnen inbrengen in zijn computer en zijn onderzoeken kunnen verrichten aan de hand van de weergave het uittreksel zal in een zip-bestand worden geformateerd en overgemaakt via memory stick, CD,... het RIZIV is van plan om een systeem in te voeren waarbij gebruik wordt gemaakt van een secure FTP voor het versturen van het uittreksel uit het logboek  bovendien kan het RIZIV het archief van het eHealth-platform ook raadplegen wanneer hij bepaalde getimestamped TSBAG uit het archief van eHealth wenst te vergelijken met het uittreksel uit het logboek

64 64 08/10/2009 Functionaliteiten timestamp visualiseren  aangezien het ziekenhuislogboek informatie bevat en de artsen wettelijk verantwoordelijk zijn, zullen de ziekenhuizen de optie timestamp visualiseren ter beschikking van hun zorgverstrekkers moeten stellen  de optie timestamp visualiseren, die ook door het intern personeel wordt gebruikt, moet de verplichting van vertrouwelijkheid van de ziekenhuizen in acht nemen: wanneer bepaalde informatie voor iemand niet beschikbaar is via het operationele informatiesysteem van het ziekenhuis, zal deze informatie ook niet beschikbaar zijn via timestamp visualiseren

65 65 08/10/2009 Nieuw controledocument en document voor de weergave van de plug-ins  document viewer plug-in  document inspector plug-in

66 66 08/10/2009 Installatie van de referentie-implementatie  installatie van de client timestamp aanmaak van een buffer database aanmaak van een archiefgegevensbank van het ziekenhuis configuratie -verbinding met de bufferdatabase -verbinding met de database -document inspectie -configuratie van de klassen voor de plug-ins -configuratie van de veiligheid -configuratie van de proxy-eigenschappen -configuratie van de timestampservercertificaten -URL's van de timestampdiensten van het eHealth-platform installatie van de client timestamp als dienst test van de programma's installatie van de archiefcoherentiecontroller programma voor registratie van het incidentenrapport de-bugginstools -een bag visualiseren -de serienummers van de timestamparchieven van het eHealth-platform visualiseren

67 67 08/10/2009 Installatie van de referentie-implementatie  installatie van visualiseren toevoeging van een gebruiker aan de database plug-ins configuratie -cache -sql server datasources -Kmehr.xsl -gebruikersinterface in verschillende talen

68 68 08/10/2009 eHealth-certificaten Belangrijk: het eHealth-certificaat kan voor meerdere toepassingen worden gebruikt

69 69 08/10/2009 Contact + testprocedure  het ziekenhuis neemt contact op met eHealth   we sturen een mail met de verschillende stappen voor de verbinding met de timestampingdienst: het ziekenhuis moet een certificaat installeren in de acceptatieomgeving. De nodige documenten voor de aanvraag van het certificaat bij Fedict (de procedure en het formulier) zijn in de mail of op het portaal te vinden; deze aanvraag wordt behandeld door de dienst AccessCoordination van Smals wanneer het certificaat geïnstalleerd is, kan het ziekenhuis testen uitvoeren in de acceptatieomgeving; gedurende deze periode is het contactpunt wanneer de acceptatietesten afdoende zijn, kan het ziekenhuis testen in de productieomgeving uitvoeren voor de productieomgeving kan het ziekenhuis ofwel een nieuw certificaat, ofwel hetzelfde certificaat als voor de acceptatie installeren; in het eerste geval moeten de vorige stappen worden herhaald wanneer het certificaat geïnstalleerd is, kan het ziekenhuis testen uitvoeren in de productieomgeving; gedurende deze periode is het contactpunt wanneer de testen in productie afdoende zijn, kan het ziekenhuis de timestampingdienst in productie gebruiken; het ziekenhuis is ertoe gehouden een overeenkomst te ondertekenen

70 PharmaFormulary

71 71 08/10/2009 Behoeften van de ziekenhuisapothekers  elektronisch voorschrift van de farmaceutische specialiteiten, van de medische hulpmiddelen (MH) en van de medische implantaten (MI) voor de in een ziekenhuis opgenomen patiënten en voor de ambulante patiënten  elektronisch voorschrift voor een extramuros bestemmeling (officina-apotheker, rust- en verzorgingstehuis, andere ziekenhuizen, …..)  beheer van het therapeutisch ziekenhuisformulier farmaceutische specialiteiten -> PharmaFormulary ok MH en MI -> MatMedFormulary niet ok  integratie van het boekhoudplan  noodzaak van een authentieke database die gratis beschikbaar is voor alle actoren die bij het elektronisch voorschrift zijn betrokken

72 72 08/10/2009 ? BCFI FOD Volksgezondheid FAGG ABPH / BVZA Voorschrijvers en gebruikers RIZIV - CTG PharmaFormulary Voorschrift Economische zaken ABPH/BVZA Geneesmiddelen & farmaceutische specialiteiten

73 73 08/10/2009 PharmaFormulary  beheerinstrument en verspreiding van het therapeutisch ziekenhuisformulier  toegankelijk voor alle beroepsbeoefenaars van de gezondheidszorg  gebruikt de DB van het BCFI die is verrijkt met geneesmiddelen die specifiek zijn voor de ziekenhuizen (infuus,...)  samenwerking ABPH/BVZA – CBIP/BCFI

74 74 08/10/2009 PharmaFormulary  maandelijkse bijwerkingen van de DB (12/2009) garanderen de geldigheid van het document  personalisering op verschillende vlakken – verspreiding van de informatie over het geneesmiddel  verspreiding van het formulier in verschillende bijkomende formaten: afdruk intranet pocket pc

75 75 08/10/2009 MatMedFormulary  betreft: medische hulpmiddelen  project: integratie in Pharmaformulary  DB in opbouw

76

77

78

79

80

81

82 82 08/10/2009 Terugbetaalbaar Factureerbaar ________________ BMF RIZIV - CTG ABPH/BVZA Voorschrijvers en gebruikers FAGG MatMedFormulary Voorschrift UNAMEC Economische zaken Medische hulpmiddelen & medische implantaten

83 End-to-end vercijfering

84 84 08/10/2009 Basisdoelstelling  end-to-end encryption (ETEE) of vercijfering moet het mogelijk maken dat actoren in de gezondheidszorg onderling elektronische berichten over open netwerken kunnen uitwisselen zonder dat iemand anders dan de verzender en de uiteindelijke bestemmeling de inhoud ervan kunnen zien (aspect confidentialiteit) en met de waarborg dat de vercijferde inhoud niet gewijzigd is sedert de verzending (aspect integriteit)  de vercijferde inhoud van de elektronische berichten kan dus niet kunnen worden ontcijferd of veranderd door tussenkomende instanties, zoals het eHealth-platform of een organisatie belast met de tijdelijke opslag van de berichten

85 85 08/10/2009 Functionele behoeften  het systeem van end-to-end vercijfering moet toelaten om elektronische berichten end-to-end te vercijferen indien de bestemmeling van het bericht gekend is op het ogenblik van de vercijfering elektronische berichten end-to-end te vercijferen indien de bestemmeling van het bericht niet gekend is op het ogenblik van de vercijfering elektronische berichten bij tijdelijke opslag te vercijferen zodat enkel degene die ze heeft aangemaakt ze kan ontcijferen  het systeem moet kunnen worden gebruikt door alle actoren in de gezondheidszorg in België voor zoveel mogelijk toepassingen zonder per partner of toepassing specifieke standaarden te moeten afspreken

86 86 08/10/2009 Gebruikte systemen van vercijfering  asymmetrische vercijfering de sleutel gebruikt voor vercijfering is een andere dan de sleutel gebruikt voor ontcijfering elke actor genereert onder zijn toezicht een sleutelpaar wat vercijfert wordt met de ene sleutel van het sleutelpaar kan enkel worden ontcijferd met de andere sleutel van hetzelfde sleutelpaar de ene sleutel van het sleutelpaar is opgeslagen in een openbare gegevensbank, de andere sleutel is veilig opgeslagen bij de titularis wordt gebruikt wanneer de bestemmeling gekend is op het ogenblik van de vercijfering door de verzender

87 87 08/10/2009 Gebruikte systemen van vercijfering  symmetrische vercijfering de sleutel gebruikt voor vercijfering is dezelfde als de sleutel gebruikt voor de ontcijfering de sleutel wordt gegenereerd door het eHealth-platform, ter beschikking gesteld aan de verzender en bij het eHealth-platform bijgehouden in relatie tot een uniek nummer van het vercijferde elektronische bericht het vercijferde elektronische bericht wordt NOOIT opgeslagen binnen de invloedssfeer van het eHealth-platform de uiteindelijke gemachtigde ontvanger van het vercijferde bericht bewijst zijn recht op ontcijfering en verkrijgt van het eHealth-platform de sleutel voor de ontcijfering van het betrokken bericht wordt gebruikt wanneer de bestemmeling niet gekend is op het ogenblik van de vercijfering door de verzender of voor de tijdelijke vercijferde opslag van elektronische berichten

88 88 08/10/2009 Schema generatie asymmetrisch sleutelpaar eHealth-platform Healthcare actor Person or entity Internet Identification certificate Identification certificate Web service Register key Connector or other software to generate key pair Sends public key Stores private key in a secure way Public keys repository Authenticates sender Stores public key 3 4

89 89 08/10/2009 Schema asymmetrische ver/ontcijfering Internet eHealth-platform Identification certificate Public keys repository Authenticates sender Sends public key 2 3 Message originator Identification certificate Asks for public key Encrypts message 4 1 Message recipient Decrypts message 5 Stored private key Identification certificate Web service Ask public key Send message Any protocol

90 90 08/10/2009 Schema symmetrische ver/ontcijfering User 2 Recipient User 1 Originator Key Management / Depot Messages Depot 1 asks for key 2 sends key Symmetric key Encrypted with public key of user 1 3 sends encrypted message Message encrypted with symmetric key Encrypted with public key of Message depot Message encrypted with symmetric key 4 justifies right to obtain key 4 justifies right to obtain message Symmetric key Encrypted with public key of user 2 5 receives key 5 receives message Message encrypted with symmetric key Encrypted with public key of User 2

91 91 08/10/2009 Uitgewerkte diensten  voor asymmetrische vercijfering en ontcijfering systeem is beschikbaar en gevalideerd door COSIC bestaat uit software library met bijhorende documentatie (cookbook) die kan worden geïntegreerd in softwarepakketten van actors in de gezondheidssector, die toelaat om -sleutelparen veilig locaal te genereren -de private sleutel van het sleutelpaar veilig locaal op te slaan -de publieke sleutel van het sleutelpaar op te slaan in een openbare gegevensbank bij het eHealth-platform via een webservice -de publieke sleutel van de bestemmeling via een webservice op te zoeken in de openbare gegevensbank bij het eHealth-platform en het elektronische bericht te vercijferen -een verkregen vercijferd bericht te ontcijferen met de eigen private sleutel -bij dit alles ook de nodige digitale handtekeningen te plaatsen en de bijhorende certificaten te gebruiken en de geldigheid ervan na te gaan

92 92 08/10/2009 Uitgewerkte diensten  voor symmetrische vercijfering en ontcijfering systeem is in ontwikkeling en allicht beschikbaar tegen einde 2009 zal ter validatie worden voorgelegd aan COSIC bestaat uit -een webservice met bijhorende documentatie die kan worden aangeroepen bij het eHealth-platform voor het verkrijgen van een symmetrische sleutel ter vercijfering van een bepaald elektronisch bericht -een webservice met bijhorende documentatie die kan worden aangeroepen bij het eHealth-platform voor het verkrijgen van een symmetrische sleutel ter ontcijfering van een bepaald elektronisch bericht -een software library met bijhorende documentatie die kan worden geïntegreerd in softwarepakketten van actors in de gezondheidssector, die toelaat om  het elektronische bericht te vercijferen met de symmetrische sleutel  het elektronisch bericht te ontcijferen met de symmetrische sleutel  bij dit alles ook de nodige digitale handtekeningen te plaatsen en de bijhorende certificaten te gebruiken en de geldigheid ervan na te gaan

93 93 08/10/2009 Deliverables reeds ter beschikking  volgende documentatie en componenten van de ETEE omgeving zijn reeds ter beschikking op het portaal van het eHealth-platform een ‘architectuur-document’ met een beschrijving van de conceptuele en technische componenten van het globale systeem een ‘cookbook’ dat voorziet in de documentatie met betrekking tot de vercijferingsstandaarden en de protocols die door het eHealth-platform worden aanbevolen, en de procedure tot het bekomen van ‘authenticatie-certificaten‘ de ‘technische specificaties’ van de reeds beschikbare componenten specifiek voor de versleuteling van geadresseerde berichten -de toepassing voor het genereren van sleutelparen en het verkrijgen van encryptiecertificaten -de gegevensbank waarin de openbare sleutels kunnen worden opgeslaan en opgezocht, toegankelijk via gedocumenteerde webservices -de toepassing/utility/source code voor de vercijfering en de ontcijfering


Download ppt "Nieuwe eHealth-toepassingen voor ziekenhuizen Frank Robben Administrateur-generaal eHealth-platform Sint-Pieterssteenweg 375 B-1040 Brussel"

Verwante presentaties


Ads door Google