Sikkerhedsmodellen for DDV bygger i lighed med Det Fælles Medicinkort på MedComs “den gode webservice” og SOSI projektet. Se (sosi) og (dgws). Data, der anvendes forretningsmæssigt, f.eks. sygehusafdelingsnummer, ydernummer og autorisationsnummer, bør medsendes i den forretningsmæssige del af dokumentet, og ikke hentes fra dokumentheaderen. Det kan ikke udelukkes at f.eks.:

• En sekretær på en sygehusafdeling logger ind med SKS-sygehusafdelingsnummer med 6 cifre og foretager en opdatering af data på et afsnit angivet med 7 cifre.
• En læge har to ydernumre, og logger ind med det ene men sender data for begge.

Skal der senere opstilles regler for hvorvidt dette skal være muligt bør valideringen af disse regler holdes adskilt fra den forretningsmæssige implementering. Dette bør ske for at minimere risikoen for at ændringer i sikkerhedsmodellen påvirker denne.

Der foretages autorisation af klient systemer. Denne er whitelist-baseret, og skal sikre at kun software, der er godkendt til at benytte vaccinationsregisteret, kan kalde dets services. Konkret skal der tilføjes SOAP header blocks, der unikt identificerer det software, der ønsker at kalde vaccinationsregisteret. Bemærk at denne identifikation ikke er en del af ID kortet, men implementeres som selvstændige XML elementer i SOAP headeren. Det er derfor ikke bundet til en session, men kan variere fra en forespørgsel til næste.

Der tilføjes et XML element, WhiteListingHeader, til SOAP headeren. Dette indeholder et antal elementer, der alle er af type xs:string:

• SystemOwnerName
• SystemName
• SystemVersion
• OrgResponsibleName
• OrgUsingID
• OrgUsingName
• RequestedRole

System autorisation er tænkt som en udvidelse af DGWS og under standardisering i NSI regi.

Der introduceres en ny SOAP header, som indeholder det entydige navn på leverandøren af afsendersystemet.

Der introduceres en ny SOAP header, som indeholder navnet på afsendersystemet.

Der introduceres en ny SOAP header, som indeholder det entydige navn på den organisation, der har ansvaret for it-systemet. Det bemærkes, at organisationen meget vel kan være en ikke-sundhedsfaglig organisation der måske endda ikke engang kan identificeres via en klassifikation som CVR som i tilfældet en driftsafdeling i en region. Derfor anvendes der ikke klassifikationer for denne attribut. OrgResponsibleName er entydig.

Der introduceres en ny SOAP header, som indeholder det entydige id på den organisation, hvor brugeren aktuelt befinder sig når webservice kaldet udføres. Klassifikationen hvortil id’et hører er angivet i attributten OrgUsingID@NameFormat og headeren OrgUsingName angiver navnet på organisationen hørende til id’et

<ns:WhiteListingHeader>
    <ns1:SystemOwnerName>Leverandør A</ns1:SystemOwnerName>
    <ns1:SystemName>System A</ns1:SystemName>
    <ns1:SystemVersion>1.5</ns1:SystemVersion>
    <ns1:OrgResponsibleName>ROS It-afdeling</ns1:OrgResponsibleName>
    <ns1:OrgUsingName>ROS Testafdeling </ns1:OrgResponsibleName>
    <ns1:OrgUsingID NameFormat="medcom:skscode">3800AOJ</ns1:OrgUsingID>
    <ns1:RequestedRole>Assistent for Læge</ns1:RequestedRole>
</ns:WhiteListingHeader>

Hvis en af de krævede elementer mangler, eller det kaldende system ikke er autoriseret til at kalde DDV, returneres en SOAP fault med fejlkode 4300 (Manglende system autorisation).

Rollen tildeles på baggrund af CPR nummeret, autorisationsnummeret specificeret i SOSI ID kortet, uddannelseskode (findes ud fra autorisationsnummer) samt evt. RequestedRole element i SOAP headeren. RequestedRole kan eksempelvis benyttes hvis en person har to autorisationer, læge og tandlæge og det ønskes at præcisere rollen, eks. “tandlæge”. Hvis der angives en rolle skal den være en af følgende:

• Læge
• Tandlæge
• Jordemoder
• Sygeplejer
• Social- og sundhedsassistent
• Social- og sundhedshjælper
• Sundhedsplejerske
• Farmaceut
• Farmakonom
• Assistent for Læge
• Assistent for Tandlæge
• Assistent for Sygeplejer
• Assistent for Jordemoder
• Assistent for Social- og sundhedsassistent
• Borger
• Forældermyndighed
• Værge
• Web administrator

Hvis der angives en rolle som personen ikke er berettiget til, returnerer DDV fejlbeskeden:

• “Brugeren er ikke berettiget til rollen <rolle>”.

Hvis der ikke kan findes en gyldig rolle for brugeren returneres:

• ”Ingen roller passer på brugeren”

Hvis der ikke er angivet en ønsket rolle og der findes flere gyldige roller for brugeren returneres:

• ”Flere forskellige roller passer på brugeren - angiv ønsket rolle”

Eks. på brug af RequestedRole: <RequestedRole>Tandlæge<RequestedRole>

Det kræves af serviceaftagersystemet, at den pågældende person er valideret og at opslaget på borgerens data er relevant. At kaldet er relevant, eksempelvis at der er en behandlerrelation, bygger på “trust” til det pågældende IT-system, den ansvarlige IT-afdeling og brugerens organisatoriske tilhørsforhold. For at anvende de nye roller skal disse felter derfor specificeres i SOAP headeren. Se afsnit om System autorisation for yderligere oplysninger.

Adgang som medhjælp for en sundhedsfaglig person, kræver at der angives en MOCES signatur (medarbejdersignatur), samt at strukturen OnBehalfOf sættes i SOAP headeren (se afsnit om Medhjælp for sundhedsfaglig). Et medhjælp-sundhedsfaglig forhold valideres altid mod det centrale bemyndigelsesregister eller systemets lokale replikering heraf, baseret på data udstillet via NSP. Registeret kan vedligeholdes af den sundhedfaglige via eksempelvis medicin-it.dk.

Under normal anvendelse af DDV vil det være den sundhedsfaglige som udfører opdateringer og opslag med sin digitale signatur. Eksempelvis læger har dog ofte en lægesekretær til at foretage selve tastearbejdet, hvorfor der er et teknisk behov for at medhjælperen kan lave opslag og opdateringer på vegne af den sundhedsfaglige person.

Følgende to regler gælder for medhjælp for sundhedsfaglig:

• medhjælperen benytter sin egen digitale medarbejder signatur, idet SOSI ID kortet bliver signeret

med medhjælperens signatur.

• Medhjælperen angiver autorisationsnummeret på den sundhedsfaglige person som hun handler på

vegne af. Autorisationsnummeret skrives ind i soap headeren.

Eksempel på angivelse af ”På vegne af”:

<ddv:OnBehalfOfStructure>
    <ddv:AuthorisationIdentifier>BR56T</ddv:AuthorisationIdentifier>
</ddv:OnBehalfOfStructure>

Regler for logning er bestemt af persondataloven og sundhedsloven.

For at kunne logge hvilken organisation der står for et opslag/opdatering af DDV, er det nødvendigt at CareProviderName i SOSI ID kortet er udfyldt. Det er DDV klient systemets ansvar at den er korrekt angivet, idet den ikke kan valideres i DDV.

Eksempel på angivelse af organisation:

<saml:Attribute Name="medcom:CareProviderName">
    <saml:AttributeValue>Anæstesiologisk overafd., Gentofte hospital</saml:AttributeValue>
</saml:Attribute>

CareProviderName må maximalt være på 50 tegn.