Nieuwe ehealth toepassingen voor ziekenhuizen
This presentation is the property of its rightful owner.
Sponsored Links
1 / 93

Nieuwe eHealth-toepassingen voor ziekenhuizen PowerPoint PPT Presentation


  • 69 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Nieuwe eHealth-toepassingen voor ziekenhuizen

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Nieuwe ehealth toepassingen voor ziekenhuizen

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

Raadpleging van het Rijksregister en van de KSZ-registersAlgemeen overzicht


Rijksregister wat

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


Kruispuntbankregisters wat

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


Verhouding tussen beide

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


Identificatienummer van de sociale zekerheid

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


Toegang 1 2

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_021_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)


Toegang 2 2

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/sources/nationalregister.html


Voorwaarden 1 2

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)


Voorwaarden 2 2

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)


Verplichtingen

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.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.pdf


Inlichtingen informatieveiligheidsconsulent

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


Inlichtingen informatieveiligheidsbeleid 1 2

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


Inlichtingen informatieveiligheidsbeleid 2 2

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


Webservices

Webservices

  • 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)

  • 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


Andere behoeften

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


Informatieveiligheidsmaatregelen

Informatieveiligheidsmaatregelen

  • eHealth-platform zal een overleg met de ziekenhuizen organiseren

  • « overlegstructuur » zal de ziekenhuizen bijstaan bij het opstellen en implementeren van informatie-veiligheidspolicies


Raadpleging van het rijksregister en van de ksz registers technisch e aspecten en procedure

Raadpleging van het Rijksregister en van de KSZ-registersTechnische aspecten en procedure


Overzicht

Overzicht

  • webservice RN Consult

  • webservice IdentifyPerson

  • webservice PhoneticSearch

  • webservice ManageInscription

  • webservice MutationSender

  • webservice PersonHistory

  • protocol

  • overzicht van de architectuur

  • contact

  • procedure

  • eHealth-certificaten


Webservice rn consult

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


Webservice identifyperson

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


Webservice identifyperson1

WebService IdentifyPerson

Request


Webservice identifyperson2

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>


Webservice identifyperson3

WebService IdentifyPerson

Reply


Webservice identifyperson4

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-SUR-SAMBRE</Description>

<Municipality>

<InsCode>92140</InsCode>

</Municipality>

<Country>

<InsCode>150</InsCode>

</Country>

</Localisation>

</Birth>


Webservice identifyperson5

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>


Webservice phoneticsearch

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


Webservice manageinscription

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


Webservice mutationsender

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


Webservice personhistory

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


Overzicht van de architectuur

Overzicht van de architectuur


Overzicht van de architectuur1

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

Ziekenhuizen,...

mutaties via WS

Batch BCSS

Mutation Sender

mutaties

betreffende de

Webservices :

ziekenhuizen

manageInscription

identifyPerson

Een mutatie-

phoneticSearch

bestand

mutationSender

wordt 1-maal

per dag

verstuurd

depotserver

van de

mutaties

DB

DB

abonnemen-

autorisations

tendienst

batch eHealth

verwerking mutaties

webtoepassing

veiligheidsconsultent

Overzicht van de architectuur


Protocol

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/basicservices/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


Integratieprocedure

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


Integratieprocedure1

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 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 [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]


Contact

Contact

  • contact dienst PPKB

    [email protected]

  • technisch contact RN Consult

    [email protected]


Ehealth certificaat

eHealth-certificaat

  • Belangrijk: het eHealth-certificaat kan voor meerdere

  • toepassingen worden gebruikt


Het elektronisch geneesmiddel voorschrift eprescription binnen ziekenhuizen algemeen overzicht

Het elektronisch geneesmiddel-voorschrift (ePrescription) binnen ziekenhuizenAlgemeen overzicht


Elektronisch voorschrift binnen ziekenhuizen

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


Functionaliteiten

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


Voorwaarden voor een elektronisch voorschrift

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


Voorwaarden voor een elektronisch voorschrift1

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


Voorwaarden voor een elektronisch voorschrift2

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


Voorwaarden voor een elektronisch voorschrift3

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


Voorwaarden voor een elektronisch voorschrift4

Voorwaarden voor een elektronisch voorschrift

Ziekenhuis

eHealth-platform

1

6

voorschrift A

voorschrift B

archief

hashing

2

hashcode B

hashcode A

5

elektronische

handtekening

3

timestamp bag

4

elektronische

datering

6

archief


Voorwaarden voor een elektronisch voorschrift5

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


Voorwaarden voor een elektronisch voorschrift6

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


Voorwaarden voor een elektronisch voorschrift7

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


Nieuwe ehealth toepassingen voor ziekenhuizen

Het elektronisch geneesmiddelen-voorschrift (ePrescription) binnen ziekenhuizenTechnische aspecten en procedure


Overzicht1

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


Overzicht van de architectuur2

Overzicht van de architectuur


Hashing algoritme

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


Timestamp bags

Timestamp bags


Protocol timestamp client timestamp server

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


Beheer van de verschillende klinische systemen van eenzelfde ziekenhuis

Beheer van de verschillende klinische systemenvan eenzelfde ziekenhuis


Beheer van de verschillende klinische systemen van eenzelfde ziekenhuis1

Beheer van de verschillende klinische systemenvan eenzelfde ziekenhuis


Overzicht van de archivering

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


Overzicht van de archivering1

Overzicht van de archivering


Overzicht van de archivering2

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


Sleutellengte digitale handtekening

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


Functionaliteiten timestamp visualiseren

Functionaliteiten timestamp visualiseren


Functionaliteiten timestamp visualiseren1

Functionaliteiten timestamp visualiseren


Inspectiedienst riziv timestamping

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


Functionaliteiten timestamp visualiseren2

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


Nieuw controledocument en document voor de weergave van de plug ins

Nieuw controledocument en document voor de weergave van de plug-ins

document viewer plug-in

document inspector plug-in


Installatie van de referentie implementatie

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


Installatie van de referentie implementatie1

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


Ehealth certificaten

eHealth-certificaten

  • Belangrijk: het eHealth-certificaat kan voor meerdere toepassingen worden gebruikt


Contact testprocedure

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:

    • 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


Pharmaformulary

PharmaFormulary


Behoeften van de ziekenhuisapothekers

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


Geneesmiddelen farmaceutische specialiteiten

Geneesmiddelen & farmaceutische specialiteiten

Economische zaken

Voorschrijvers en gebruikers

?

BCFI

FAGG

Voorschrift

RIZIV - CTG

PharmaFormulary

FOD Volksgezondheid

ABPH/BVZA

ABPH / BVZA


Pharmaformulary1

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


Pharmaformulary2

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


Matmedformulary

MatMedFormulary

  • betreft: medische hulpmiddelen

  • project: integratie in Pharmaformulary

  • DB in opbouw


Medische hulpmiddelen medische implantaten

Medische hulpmiddelen & medische implantaten

Voorschrijvers en gebruikers

Economische zaken

Terugbetaalbaar

Factureerbaar

________________

BMF

ABPH/BVZA

Voorschrift

FAGG

MatMedFormulary

RIZIV - CTG

UNAMEC

ABPH / BVZA


End to end vercijfering

End-to-end vercijfering


Basisdoelstelling

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


Functionele behoeften

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


Gebruikte systemen van vercijfering

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


Gebruikte systemen van vercijfering1

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


Schema generatie asymmetrisch sleutelpaar

Schema generatie asymmetrisch sleutelpaar

eHealth-platform

Healthcare actor

Person or entity

Internet

3

1

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


Schema asymmetrische ver ontcijfering

Schema asymmetrische ver/ontcijfering

eHealth-platform

Message originator

Internet

Web service

Ask public key

1

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


Schema symmetrische ver ontcijfering

Encrypted with public key of user 1

Symmetric key

Schema symmetrische ver/ontcijfering

Key

Management

/ Depot

Encrypted with public key of user 2

Symmetric key

5 receives key

2 sends key

1 asks for key

User 2

Recipient

User 1

Originator

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


Uitgewerkte diensten

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


Uitgewerkte diensten1

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


Deliverables reeds ter beschikking

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


  • Login