ISD Productcodes iWmo en iJw
-
Voor zowel gemeenten als zorgaanbieders heeft het werken met de standaardlijsten veel voordelen.
De administratieve afdelingen van zorgaanbieders die werken voor meerdere gemeenten moeten op dit moment extra mankracht inzetten voor het administratief verwerken van de veelvoud aan productcodes. Daarbij maken zij veelal gebruik van een eigen vertaaltabel of systematiek. Dat levert onnodige extra mankracht op de administratie en bij ICT op.
Ook bij gemeenten leidt de grote hoeveelheid aan productcodes op dit moment tot veel verwarring in de uitvoering. Er wordt veel extra onnodige tijd gestoken in het ontcijferen van productcodes. Dit geldt onder andere bij het toewijzen van zorg. Daarnaast bieden de standaardlijsten het voordeel dat gemeenten zelf geen lijsten hoeven te beheren. Door gebruik te maken van de standaardlijst kunnen de administratieve processen bij gemeenten en zorgaanbieders vereenvoudigd worden.
- Bijsluiter productcodelijsten iWmo en iJw 2016 (VNG, oktober 2015, pdf)
- Bijsluiter productcodelijsten iWmo en iJw 2016 (VNG, oktober 2015, pdf)
-
Nu een standaardproductcodetabel beschikbaar is gekomen, wordt de ondersteuning voor gemeentespecifieke lijsten in 2016 teruggebracht. Het is nog steeds mogelijk om met afwijkende codes te werken, maar gemeenten zijn zelf verantwoordelijk om daarover afspraken te maken met zorgaanbieders en de codetabellen beschikbaar te stellen.
De Verwijsindex productcodes Wmo en Jeugd, een centrale voorziening voor gemeente-specifieke lijsten, zal in 2016 nog wel raadpleegbaar blijven, maar mutaties zijn niet meer mogelijk.
-
In het iWmo- en iJw-berichtenverkeer worden vanaf versie 2.0 drie uitvoeringsvarianten onderscheiden: inspannings-, output- en taakgericht.
De standaardproductcodetabel is bruikbaar in de inspannings- en outputgerichte uitvoeringsvariant, waar de gemeente op cliëntniveau gegevens uitwisselt met de aanbieder van zorg of ondersteuning.
- Handreiking Uitvoeringsvarianten iWmo en iJw (VNG, augustus 2015, pdf)
ISD SaaS informatiebeveiliging en privacy
-
Jaarlijks is een TPM of eigen audit nodig. Maak vooraf afspraken met betrekking tot het zogenoemde ‘right to audit’, zodat de gemeente of een auditor in opdracht van de gemeente in staat gesteld wordt om bepaalde processen en de gegevensverwerking te kunnen controleren en beoordelen.
-
De beveiligingseisen zijn afhankelijk van de soort gegevens, applicatie en dienst die u als gemeente in de SaaS-oplossing (Software as a Service) wilt gaan gebruiken. Een voorbeeld is te vinden in het operationele Baseline Informatiebeveiliging Nederlandse Gemeenten (BIG)-product Bewerkersovereenkomst van de Informatie Beveiligingsdienst (IBD). Hierin zijn ook de moogelijke maatregelen opgenomen.
Als gemeente bent u zelf verantwoordelijk voor het maken van een inschatting of de genomen maatregelen afdoende dekkend zijn voor de risico's die gelopen worden.
-
Toegang voor burgers kan op dezelfde manier geregeld worden als bij een eigen oplossing vanuit de gemeente. Er moet een portaal komen waar de burger met DigiD kan inloggen, waar de informatie dan getoond wordt als er een klantcase is. Bij SaaS moet er dus een portaal zijn die aparte informatie ontsluit. Een mogelijke oplossing is de digitale berichtenbox van mijnoverheid.nl.
-
Bij een SaaS-oplossing gaat de gemeente niet meer over functioneel en technisch beheer. Functioneel beheer zoals het (functioneel) parametriseren van de applicatie en gebruikersbeheer kan nog wel door de gemeente worden uitgevoerd.
- BIG - Cloud computing (IBD, november 2013, pdf)
-
Het identificatie- en authenticatieproces is het vaststellen wie iemand is. Het autorisatieproces is het bepalen en vastleggen welke toegang deze persoon heeft binnen een bepaald informatiesysteem. De autorisatie kan met speciale tooling worden beheerd (IAM-tools) en indien een koppeling bestaat met een applicatie kunnen de gegevens worden uitgewisseld.
Er zijn niet veel gemeenten die dit op deze manier doen. In de praktijk staan eindgebruikers in een adresgids (LDAP of active directory). Los daarvan wordt vaak per applicatie bijgehouden welke eindgebruikers waar toegang hebben in de applicatie zelf. Dit is vaak een handmatig proces op basis van bijvoorbeeld een getekend autorisatieformulier van een manager. Deze autorisaties worden dan door een functioneel beheerder middels een aparte beheerpagina in een webapplicatie verwerkt.
- BIG - Beleid logische toegangsbeveiliging (IBD, juli 2014, pdf)
-
Vanaf welke locaties toegang tot de SaaS-oplossing moet worden toegestaan is van een aantal zaken afhankelijk, zoals:
- de gegevens (inhoud)
- de plaats (geografisch)
- wetgeving (soms is het niet toegestaan met bepaalde gegevens te werken buiten de gemeentelocatie)
Meer informatie
- BIG - Handreiking Dataclassificatie (IBD, april 2018, pdf)
- BIG - Cloud computing (IBD, november 2013, pdf)
- BIG - Mobile Device Management (IBD, oktober 2013, pdf)
- BIG - Telewerkbeleid (IBD, april 2014, pdf)
-
Volledige vraag
Hoe garandeer ik de continuïteit van de SaaS-applicatie en de beschikbaarheid van de data in geval van een faillissement van de SaaS-leverancier, of wanneer de leverancier anderszins in gebreke blijft?Antwoord
Zowel de gemeente (cloudafnemer) als hun leveranciers dienen hun verantwoordelijkheid te nemen, door bijvoorbeeld een continuïteitsplan op te stellen. Het doel van dit continuïteitsplan is het onafgebroken gebruik veilig stellen. De calamiteit bij de cloud- of SaaS-leverancier moet zo min mogelijk gevolgen hebben voor de bedrijfsprocessen van de afnemer.Neem minimaal de volgende onderwerpen in een contract op:
- dat de data altijd eigendom blijft van de gemeente en in een vastgesteld formaat verstrekt wordt in bepaalde omschreven situaties;
- broncode-escrowregeling zodat het gebruik, toegang, onderhoud en doorontwikkeling van de software wordt gewaarborgd;
- exitstrategie (exitplan), voor het geval dat de leverancier niet bevalt of niet meer kan leveren.
Meer informatie
- BIG - Cloud computing (IBD, november 2013, pdf)
-
Koppelingen tussen vertrouwde netwerken en niet-vertrouwde netwerken moeten bij voorkeur op de volgende manier worden beveiligd:
- Kanaalencryptie door middel van een PKIoverheid-SSL certificaat
- Apparaat authenticatie door middel van een PKIoverheid certificaat
- Filtering op basis van IP-nummers
- Scheiding van netwerken met verschillende beveiligingsniveaus
- Indringerdetectie
- (Technische) logging
Meer informatie
- BIG - Encryptiebeleid (PKI) (IBD, juni 2014, pdf)
- BIG - Aanwijzing logging (IBD, januari 2014, pdf)
- ICT-Beveiligingsrichtlijnen voor Webapplicaties (Nationaal Cyber Security Centrum | NCSC)
- NORA online (Nederlandse Overheid Referentie Architectuur | NORA)
-
Lees de volgende operationele BIG-producten:
- Inkoopvoorwaarden en informatiebeveiligingseisen (IBD, januari 2014, pdf)
Aanscherpen van de gemeentelijke inkoop voorwaarden. - Contractmanagement (IBD, april 2014, pdf)
Aandachtspunten voor contractmanagement, inkoop en beveiligingseisen.
- Inkoopvoorwaarden en informatiebeveiligingseisen (IBD, januari 2014, pdf)