Download de presentatie
De presentatie wordt gedownload. Even geduld aub
GepubliceerdDennis Devos Laatst gewijzigd meer dan 10 jaar geleden
1
Nieuwe eHealth-toepassingen voor ziekenhuizen
Frank Robben Administrateur-generaal eHealth-platform Sint-Pieterssteenweg 375 B-1040 Brussel Website eHealth-platform: Persoonlijke website: 1
2
Raadpleging van het Rijksregister en van de KSZ-registers Algemeen overzicht
2
3
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
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
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
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
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 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
8
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
9
Voorwaarden (1/2) slechts voor welbepaalde doeleinden bewaartermijn
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
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
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) 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
12
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
Inlichtingen informatieveiligheidsbeleid (1/2)
gebruik maken van de diensten van een informatieveiligheidsconsulent evalueren van risico’s en veiligheidsbehoeften op het vlak van de verwerking van persoonsgegevens bijhouden van een geschreven versie van het informatieveiligheidsbeleid identificeren van de diverse dragers waarop persoonsgegevens worden verwerkt informeren van de personeelsleden over hun vertrouwelijkheids- en veiligheidsplichten nemen van maatregelen tegen niet-gemachtigde of onnodige toegang tot persoonsgegevens nemen van maatregelen tegen fysieke schade die persoonsgegevens in gevaar zou kunnen brengen
14
Inlichtingen informatieveiligheidsbeleid (2/2)
nemen van maatregelen ter bescherming van de verschillende geconnecteerde netwerken beschikken over een actuele lijst van personen die toegang hebben tot persoonsgegevens en hun toegangsniveau installeren van een mechanisme voor toegangsmachtiging op de informatiesystemen beschikken over een systeem van registratie van de personen die toegang hebben tot de persoonsgegevens controleren van de geldigheid en de doeltreffendheid in de tijd van de organisatorische en technische maatregelen beschikken over urgentieprocedures in geval van veiligheidsincidenten beschikken over een bijgewerkte documentatie betreffende de veiligheidsmaatregelen
15
Webservices IdentifyPerson PhoneticSearch ManageInscription
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) PhoneticSearch opzoeking van dezelfde persoonsgegevens op basis van (eventueel zelfs onvolledige) fonetische criteria van de patiënt (naam, voornaam, geboortedatum) 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 MutationSender dagelijks ter beschikking stellen van de mutaties (= wijzigingen van de beschikbare persoonsgegevens) aan het ziekenhuis PersonHistory opzoeking van de historiek van de mutaties van de beschikbare persoonsgegevens
16
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
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
18
19
Overzicht webservice RN Consult webservice IdentifyPerson
webservice PhoneticSearch webservice ManageInscription webservice MutationSender webservice PersonHistory protocol overzicht van de architectuur contact procedure eHealth-certificaten
20
WebService RN Consult de webservice RN Consult bestaat uit 5 onafhankelijke subwebservices: IdentifyPerson: identificatie van een natuurlijke persoon aan de hand van het INSZ PhoneticSearch: identificatie van een natuurlijke persoon op basis van fonetische criteria ManageInscription: invoeging in en verwijdering uit de abonnementendienst MutationSender: beschikbaarstelling van mutaties PersonHistory: beschikbbaarstelling van de historiek van de gegevens van het Rijksregister en van de Kruispuntbank-registers
21
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
WebService IdentifyPerson
Request
23
WebService IdentifyPerson
For example: <?xml version="1.0" encoding="UTF-8"?> <ns1:SearchBySSINRequest xsi:schemaLocation="urn:be:fgov:ehealth:consultRN:1_0:protocol IdentifyPerson-1-0.xsd" xmlns:xsi=" xmlns:ns1="urn:be:fgov:ehealth:consultRN:1_0:protocol"> <Organisation> <Id> </Id> <Type>NIHII</Type> <SubType>HOSPITAL</SubType> </Organisation> <ApplicationID>xxxxxxxxxxx</ApplicationID> <Inscription> <SSIN>xxxxxxxxxxx</SSIN> <QualityCode>1</QualityCode> <Period> <BeginDate> </BeginDate> <EndDate> </EndDate> </Period> </Inscription> </ns1:SearchBySSINRequest>
24
WebService IdentifyPerson
Reply
25
WebService IdentifyPerson
<?xml version="1.0" encoding="UTF-8"?> <ns1:SearchBySSINReply Id=" " xsi:schemaLocation="urn:be:fgov:ehealth:consultRN:1_0:protocol IdentifyPerson-1-0.xsd" xmlns:xsi=" xmlns:eH="urn:be:fgov:ehealth:commons:1_0:core" xmlns:ns1="urn:be:fgov:ehealth:consultRN:1_0:protocol"> <eH:Status> <Code>100</Code> <Message>Success</Message> </eH:Status> <Person> <SSIN> </SSIN> <PersonData> <Birth> <Date> </Date> <Localisation> <Description Lang="FR">JEMEPPE-SUR-SAMBRE</Description> <Municipality> <InsCode>92140</InsCode> </Municipality> <Country> <InsCode>150</InsCode> </Country> </Localisation> </Birth>
26
WebService IdentifyPerson
<Name> <First>PERSONNE</First> <Last>TEST</Last> </Name> <Gender>UNKNOWN</Gender> <Address> <StandardAddress> <Street> <Description Lang="NL">STRAAT ONBEKEND</description> </Street> <Housenumber>25</Housenumber> <Municipality> <InsCode>11002</InsCode> <PostalCode>2000</PostalCode> <Description>ANTWERPEN</Description> </Municipality> <Country> <InsCode>150</InsCode> <Description Lang="NL">BELGIË</Description> </Country> </StandardAddress> </Address> </PersonData> </Person> </ns1:SearchBySSINReply>
27
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
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
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
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
Overzicht van de architectuur
32
Overzicht van de architectuur
mutaties betreffende de ziekenhuizen depotserver van de Webservices : manageInscription identifyPerson phoneticSearch mutationSender DB autorisations abonnemen- tendienst ESB BCSS Ziekenhuizen,... veiligheidsconsultent webtoepassing RR 1. raadpleging via WS 2. ophalen van de OSB eHealth Batch BCSS batch eHealth verwerking mutaties mutaties via WS Mutation Sender Een mutatie- bestand wordt 1-maal per dag verstuurd
33
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: 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
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 veiligheid 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 wenst het ingevulde formulier moet naar het volgende adres worden verstuurd: eHealth-platform, dienst PPKB, Sint-Pietersteenweg 375 te 1040 Brussel
35
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
Contact contact dienst PPKB Request@ehealth.fgov.be
technisch contact RN Consult
37
eHealth-certificaat Belangrijk: het eHealth-certificaat kan voor meerdere toepassingen worden gebruikt
38
Het elektronisch geneesmiddel-voorschrift (ePrescription) binnen ziekenhuizen Algemeen overzicht
38
39
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
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
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
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
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
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
Voorwaarden voor een elektronisch voorschrift
Ziekenhuis eHealth-platform 1 6 voorschrift A voorschrift B archief hashing 2 hashcode A hashcode B 5 elektronische handtekening 3 timestamp bag 4 elektronische datering 6 archief
46
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
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
Voorwaarden voor een elektronisch voorschrift
juridische teksten ( 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
Het elektronisch geneesmiddelen-voorschrift (ePrescription) binnen ziekenhuizen Technische aspecten en procedure 49
50
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
Overzicht van de architectuur
52
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
Timestamp bags
54
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
Beheer van de verschillende klinische systemen van eenzelfde ziekenhuis
56
Beheer van de verschillende klinische systemen van eenzelfde ziekenhuis
57
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
Overzicht van de archivering
59
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
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
Functionaliteiten timestamp visualiseren
62
Functionaliteiten timestamp visualiseren
63
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
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
Nieuw controledocument en document voor de weergave van de plug-ins
document viewer plug-in document inspector plug-in
66
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
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
eHealth-certificaten
Belangrijk: het eHealth-certificaat kan voor meerdere toepassingen worden gebruikt
69
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 70
71
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 ABPH/BVZA : Belgische vereniging van ziekenhuisapothekers MH Medische hulpmiddelen MI Medische implantaten
72
Geneesmiddelen & farmaceutische specialiteiten
Economische zaken Voorschrijvers en gebruikers ? BCFI FAGG Voorschrift RIZIV - CTG PharmaFormulary FOD Volksgezondheid CTG: commissie tegemoetkoming geneesmiddelen ABPH/BVZA ABPH / BVZA
73
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
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
MatMedFormulary betreft: medische hulpmiddelen
project: integratie in Pharmaformulary DB in opbouw
76
Op de homepagina van de downloadsite wordt u gevraagd om u te identificeren en het soort gebruik van de software te bepalen: Ontwikkeling van het ziekenhuisformulier Ontwikkeling van een formulier voor rusthuizen Persoonlijk formulier voor de arts
77
Dia 7 version NL
78
Dia 8 version NL
79
Dia 9 version NL
80
Dia 10 version NL
81
Dia 11 version NL
82
Medische hulpmiddelen & medische implantaten
Voorschrijvers en gebruikers Economische zaken ABPH/BVZA Terugbetaalbaar Factureerbaar ________________ BMF Voorschrift FAGG MatMedFormulary RIZIV - CTG Project van de ziekenhuisapothekers : toegankelijkheid tot een volledige database over de medische hulpmiddelen en medische implantanten, naar aanleiding van de invoering van de notificatieprocedure van de implantaten in mei 2010 op het RIZIV. In een eerste fase zal de database worden beperkt tot de medische implantaten die aan het RIZIV werden meegedeeld CTI Commissie Tegemoetkoming Implantaten UNAMEC erkende beroepsvereniging van ondernemingen die medische hulpmiddelen produceren, importen en/of verdelen UNAMEC ABPH / BVZA
83
End-to-end vercijfering
83
84
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
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
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
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
Schema generatie asymmetrisch sleutelpaar
Healthcare actor Person or entity eHealth-platform Internet 1 3 Connector or other software to generate key pair Authenticates sender 4 2 Identification certificate Identification certificate Stores public key Sends public key Web service Register key 2 Public keys repository Stores private key in a secure way
89
Schema asymmetrische ver/ontcijfering
eHealth-platform Message originator Internet 1 Web service Ask public key Identification certificate Identification certificate 2 Asks for public key Authenticates sender Send message Any protocol 3 4 Sends public key Encrypts message Identification certificate Public keys repository Message recipient Stored private key 5 Decrypts message
90
Schema symmetrische ver/ontcijfering
Key Management / Depot Symmetric key Encrypted with public key of user 1 Encrypted with public key of user 2 Symmetric key 2 sends key 5 receives key User 1 Originator 1 asks for key User 2 Recipient 4 justifies right to obtain key 4 justifies right to obtain message 3 sends encrypted message Encrypted with public key of Message depot 5 receives message Encrypted with public key of User 2 Message encrypted with symmetric key Messages Depot Message encrypted with symmetric key Message encrypted with symmetric key
91
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
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
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
Verwante presentaties
© 2024 SlidePlayer.nl Inc.
All rights reserved.