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 medicinkortet, kan kalde dets services. Konkret skal der tilføjes SOAP header blocks, der unikt identificerer det software, der ønsker at kalde medicinkortet. 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>