Nieuwe eHealth-toepassingen voor ziekenhuizen (toegang tot

Nieuwe eHealth-toepassingen voor
ziekenhuizen
Frank Robben
Administrateur-generaal eHealth-platform
Sint-Pieterssteenweg 375
B-1040 Brussel
E-mail: [email protected]
Website eHealth-platform: https://www.ehealth.fgov.be
Persoonlijke website: www.law.kuleuven.be/icri/frobben
Raadpleging van het Rijksregister en van
de KSZ-registers
Algemeen overzicht
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
•
•
•
•
•
•
•
•
08/10/2009
rijksregisternummer
naam
voornamen
geslacht
geboorteplaats
geboortedatum
overlijdensdatum
hoofdverblijfplaats
3
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
•
•
•
•
•
•
•
•
08/10/2009
identificatienummer van de sociale zekerheid (zie verder)
naam
voornamen
geslacht
geboorteplaats
geboortedatum
overlijdensdatum
hoofdverblijfplaats
4
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
08/10/2009
5
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
08/10/2009
6
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_2009-1-.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/09-039-n063-1-NL.pdf)
08/10/2009
7
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.html
08/10/2009
8
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)
08/10/2009
9
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)
08/10/2009
10
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-NLFinal.doc
 overmaken van een verzoek aan het eHealth-platform
•
•
•
•
•
08/10/2009
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-omtoestemming-voor-gebruik.pdf
11
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
08/10/2009
12
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
08/10/2009
13
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
08/10/2009
14
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
•
08/10/2009
opzoeking van de historiek van de mutaties van de beschikbare
persoonsgegevens
15
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
08/10/2009
16
Informatieveiligheidsmaatregelen
 eHealth-platform zal een overleg met de ziekenhuizen
organiseren
 « overlegstructuur » zal de ziekenhuizen bijstaan bij het
opstellen en implementeren van informatieveiligheidspolicies
08/10/2009
17
Raadpleging van het Rijksregister en
van de KSZ-registers
Technische aspecten en procedure
Overzicht











webservice RN Consult
webservice IdentifyPerson
webservice PhoneticSearch
webservice ManageInscription
webservice MutationSender
webservice PersonHistory
protocol
overzicht van de architectuur
contact
procedure
eHealth-certificaten
08/10/2009
19
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 Kruispuntbankregisters
08/10/2009
20
WebService IdentifyPerson
 via de webservice ‘IdentifyPerson’ kan een ziekenhuis de
gegevens in het Rijksregister en in de Kruispuntbankregisters 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:
•
•
•
•
•
08/10/2009
de naam en voorna(a)m(en)
de geboortedatum en -plaats
het geslacht
de hoofdverblijfplaats
de datum van overlijden
21
WebService IdentifyPerson
Request
08/10/2009
22
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="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ns1="urn:be:fgov:ehealth:consultRN:1_0:protocol">
<Organisation>
<Id>71099911</Id>
<Type>NIHII</Type>
<SubType>HOSPITAL</SubType>
</Organisation>
<ApplicationID>xxxxxxxxxxx</ApplicationID>
<Inscription>
<SSIN>xxxxxxxxxxx</SSIN>
<QualityCode>1</QualityCode>
<Period>
<BeginDate>2009-04-20</BeginDate>
<EndDate>2009-06-20</EndDate>
</Period>
</Inscription>
</ns1:SearchBySSINRequest>















08/10/2009
23
WebService IdentifyPerson
Reply
08/10/2009
24
WebService IdentifyPerson
<?xml version="1.0" encoding="UTF-8"?>
<ns1:SearchBySSINReply Id="1234567890123" xsi:schemaLocation="urn:be:fgov:ehealth:consultRN:1_0:protocol
IdentifyPerson-1-0.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
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>00010100000</SSIN>
<PersonData>
<Birth>
<Date>2000-01-01</Date>
<Localisation>
<Description Lang="FR">JEMEPPE-SURSAMBRE</Description>
<Municipality>
<InsCode>92140</InsCode>
</Municipality>
<Country>
<InsCode>150</InsCode>
</Country>
</Localisation>
</Birth>
08/10/2009
25
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>
08/10/2009
26
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 :
•
•
•
•
•
08/10/2009
de naam en voorna(a)m(en)
de geboortedatum en -plaats
het geslacht
de hoofdverblijfplaats
de datum van overlijden
27
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
08/10/2009
28
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
08/10/2009
29
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
08/10/2009
30
Overzicht van de architectuur
eHealth platform
Mutation of the
national register’s
subscription
08/10/2009
CBSS
CBSS
reference
repertory
31
National register
BIS
register
National
register
Overzicht van de architectuur
1. raadpleging via WS
1. raadpleging via WS
ESB BCSS
OSB eHealth
RR
2. ophalen van de
mutaties
1. raadpleging via WS
2. ophalen van de
mutaties via WS
Mutation Sender
Ziekenhuizen,...
Batch BCSS
mutaties
betreffende de
ziekenhuizen
Webservices :
manageInscription
identifyPerson
phoneticSearch
mutationSender
Een mutatiebestand
wordt 1-maal
per dag
verstuurd
depotserver
van de
mutaties
DB
autorisations
DB
abonnementendienst
batch eHealth
verwerking mutaties
webtoepassing
veiligheidsconsultent
08/10/2009
32
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
• 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
08/10/2009
33
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 eHealthwebservices 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
08/10/2009
34
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 ([email protected])
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 eHealthacceptieomgeving 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
[email protected]
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 [email protected]
er wordt technische ondersteuning geboden door eHealth:
[email protected]
08/10/2009
35
Contact
 contact dienst PPKB
 [email protected]
 technisch contact RN Consult
 [email protected]
08/10/2009
36
eHealth-certificaat
Belangrijk: het eHealth-certificaat kan voor meerdere
toepassingen worden gebruikt
08/10/2009
37
Het elektronisch geneesmiddelvoorschrift (ePrescription) binnen
ziekenhuizen
Algemeen overzicht
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
08/10/2009
39
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
08/10/2009
40
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
08/10/2009
41
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 overeenkomstencommissie 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
08/10/2009
42
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
08/10/2009
43
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
08/10/2009
44
Voorwaarden voor een elektronisch voorschrift
Ziekenhuis
eHealth-platform
1
voorschrift A
6
voorschrift B
archief
hashing
2
hashcode
A
hashcode
B
5
elektronische
handtekening
3
timestamp bag
4
elektronische
datering
6
archief
08/10/2009
45
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
08/10/2009
46
Voorwaarden voor een elektronisch voorschrift
 deze werkwijze is een treffend voorbeeld van out-of-thebox 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
08/10/2009
47
Voorwaarden voor een elektronisch voorschrift
 juridische teksten (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
08/10/2009
48
Het elektronisch geneesmiddelenvoorschrift (ePrescription) binnen
ziekenhuizen
Technische aspecten en procedure
08/10/2009
49
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
08/10/2009
50
Overzicht van de architectuur
08/10/2009
51
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 referentieimplementatie worden aangeleverd
08/10/2009
52
Timestamp bags
08/10/2009
53
Protocol timestamp client - timestamp server
 protocol Oasis-DSS volgens het timestampprofiel (zie
http://www.oasis-open.org/committees/dss/)
 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
08/10/2009
54
Beheer van de verschillende klinische systemen
van eenzelfde ziekenhuis
08/10/2009
55
Beheer van de verschillende klinische systemen
van eenzelfde ziekenhuis
Time stamp client
program
Access
plugin
Access
plugin
Buffer of journal
entries to be time
stamped
Hospital archive
System 1
Time stamp client
program
Access
plugin
Access
plugin
Buffer of journal
entries to be time
stamped
eHealth platform
time stamp server
Hospital archive
System 2
Time stamp client
program
Access
plugin
Access
plugin
Buffer of journal
entries to be time
stamped
Hospital archive
System 3
08/10/2009
56
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
08/10/2009
57
Overzicht van de archivering
eHealth platform archive
Hospital archive
TSBag
TSBag
TSBag 1
TSBag 1
Ref 1
JE 1
Ref 1
Hash (JE 1)
Search fields JE 1
Ref 1
Hash (JE 1)
Ref 2
JE 2
Ref 2
Hash (JE 2)
Search fields JE 2
Ref 2
Hash (JE 2)
Ref 3
JE 3
Ref 3
Hash (JE 3)
Search fields JE 3
Ref 3
Hash (JE 3)
Ref 4
JE 4
Ref 4
Hash (JE 4)
Search fields JE 4
Ref 4
Hash (JE 4)
Ref 5
JE 5
Ref 5
Hash (JE 5)
Search fields JE 5
Ref 5
Hash (JE 5)
Timestamp
TSBag
TSBag
TSBag 2
TSBag 2
Ref 6
JE 6
Ref 6
Hash (JE 6)
Search fields JE 6
Ref 6
Hash (JE 6)
Ref 7
JE 7
Ref 7
Hash (JE 7)
Search fields JE 7
Ref 7
Hash (JE 7)
Ref 8
JE 8
Ref 8
Hash (JE 8)
Search fields JE 8
Ref 8
Hash (JE 8)
Ref 9
JE 9
Ref 9
Hash (JE 9)
Search fields JE 9
Ref 9
Hash (JE 9)
Timestamp
TSBag
TSBag 3
Ref 10
JE 10
Ref 10
Hash (JE 10)
Search fields JE 10
Ref 10
Hash (JE 10)
Ref 11
JE 11
Ref 11
Hash (JE 11)
Search fields JE 11
Ref 11
Hash (JE 11)
Ref 12
JE 12
Ref 12
Hash (JE 12)
Search fields JE 12
Ref 12
Hash (JE 12)
Ref 13
JE 13
Ref 13
Hash (JE 13)
Search fields JE 13
Ref 13
Hash (JE 13)
Ref 14
JE 14
Ref 14
Hash (JE 14)
Search fields JE 14
Ref 14
Hash (JE 14)
Timestamp
Info on patient 1
Info on patient 2
Info on patient 3
Info on patient 4
Timestamp
TSBag
TSBag 3
08/10/2009
Timestamp
58
Timestamp
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
08/10/2009
59
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
08/10/2009
60
Functionaliteiten timestamp visualiseren
Search parameters
Flag indicating the
result of the check of
the timestamp. Red
bullet means
problem, check mark
means OK
08/10/2009
List of journal entries
matching the search criteria
Visualisation of the selected journal entry
61
Functionaliteiten timestamp visualiseren
08/10/2009
62
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
08/10/2009
63
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
08/10/2009
64
Nieuw controledocument en document voor de
weergave van de plug-ins
 document viewer plug-in
 document inspector plug-in
08/10/2009
65
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
08/10/2009
66
Installatie van de referentie-implementatie
 installatie van visualiseren
• toevoeging van een gebruiker aan de database
• plug-ins
• configuratie
-
08/10/2009
cache
sql server datasources
Kmehr.xsl
gebruikersinterface in verschillende talen
67
eHealth-certificaten
Belangrijk: het eHealth-certificaat kan voor meerdere
toepassingen worden gebruikt
08/10/2009
68
Contact + testprocedure


het ziekenhuis neemt contact op met eHealth 
[email protected]
we sturen een mail met de verschillende stappen voor de verbinding met de
timestampingdienst:
•
•
•
•
•
•
08/10/2009
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
[email protected]
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
[email protected]
wanneer de testen in productie afdoende zijn, kan het ziekenhuis de
timestampingdienst in productie gebruiken; het ziekenhuis is ertoe gehouden een
overeenkomst te ondertekenen
69
PharmaFormulary
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
08/10/2009
71
Geneesmiddelen & farmaceutische specialiteiten
Voorschrijvers en gebruikers
Economische zaken
FAGG
?
Voorschrift
BCFI
PharmaFormulary
RIZIV - CTG
FOD Volksgezondheid
ABPH/BVZA
ABPH / BVZA
08/10/2009
72
PharmaFormulary
 beheerinstrument en verspreiding van het therapeutisch
ziekenhuisformulier
 toegankelijk voor alle beroepsbeoefenaars van de
gezondheidszorg
• www.health.fgov.be/telematics
• www.afphb.be
 gebruikt de DB van het BCFI die is verrijkt met
geneesmiddelen die specifiek zijn voor de ziekenhuizen
(infuus, ...)
 samenwerking ABPH/BVZA – CBIP/BCFI
08/10/2009
73
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
08/10/2009
74
MatMedFormulary
 betreft: medische hulpmiddelen
 project: integratie in Pharmaformulary
 DB in opbouw
08/10/2009
75
Medische hulpmiddelen & medische implantaten
Voorschrijvers en gebruikers
Economische zaken
ABPH/BVZA
Voorschrift
Terugbetaalbaar
Factureerbaar
FAGG
________________
BMF
MatMedFormulary
RIZIV - CTG
UNAMEC
ABPH / BVZA
08/10/2009
82
End-to-end vercijfering
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
08/10/2009
84
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
08/10/2009
85
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
08/10/2009
86
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
08/10/2009
87
Schema generatie asymmetrisch sleutelpaar
eHealth-platform
Internet
Healthcare actor
Person or entity
1
3
Connector or
other software to
generate key pair
Web service
Register key
Identification
certificate
Sends
public key
Identification
certificate
2
Authenticates sender
4
Stores
public key
2
Stores private key
in a secure way
08/10/2009
Public keys
repository
88
1
Asks for public key
Web service
Ask public key
Internet
Identification
certificate
Message originator
Identification
certificate
Schema asymmetrische ver/ontcijfering
eHealth-platform
2
Authenticates sender
3
4
Sends
public key
Encrypts
message
Identification
certificate
Message recipient
5
Decrypts message
08/10/2009
Stored
private
key
89
Public keys
repository
Schema symmetrische ver/ontcijfering
Key
Management
/ Depot
5 receives key
2 sends key
1 asks for key
4 justifies right to
obtain key
User 1
Originator
4 justifies right to
obtain message
3 sends encrypted message
5 receives message
Messages
Depot
Message encrypted with
symmetric key
08/10/2009
90
User 2
Recipient
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
08/10/2009
91
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
08/10/2009
92
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
08/10/2009
93