User Tools

Site Tools


fmk:ddv:1.4.0:sikkerhedsmodel

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
fmk:ddv:1.4.0:sikkerhedsmodel [2018-12-27 06:18] nigfmk:ddv:1.4.0:sikkerhedsmodel [2026-03-06 08:53] (current) – external edit 127.0.0.1
Line 2: Line 2:
  
 Sikkerhedsmodellen for DDV bygger i lighed med Det Fælles Medicinkort på MedComs "den gode Sikkerhedsmodellen for DDV bygger i lighed med Det Fælles Medicinkort på MedComs "den gode
-webservice" og SOSI projektet. Se [sosi] og [dgws].+webservice" og SOSI projektet. Se ([[http://www.sosi.dk|sosi]]) og ([[https://www.medcom.dk/standarder/webservice-standarder/den-gode-webservice|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.: 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.:
  
Line 15: Line 15:
  
 Der foretages autorisation af klient systemer. Denne er whitelist-baseret, og skal sikre at kun software, der 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 +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 medicinkortet. Bemærk at denne+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 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. headeren. Det er derfor ikke bundet til en session, men kan variere fra en forespørgsel til næste.
Line 33: Line 33:
   * RequestedRole   * RequestedRole
  
-System autorisation er tænkt som en udvidelse af DGWS og under standardisering i NSI regi.+System autorisation er tænkt som en udvidelse af DGWS og under standardisering i SDS regi.
  
 == SystemOwnerName == == SystemOwnerName ==
Line 50: Line 50:
 Der introduceres en ny SOAP header, som indeholder navnet på afsendersystemet. Der introduceres en ny SOAP header, som indeholder navnet på afsendersystemet.
  
-|Navn|sdsd:SysteName|+|Navn|sdsd:SystemName|
 |Type|xs:string| |Type|xs:string|
 |Aritet|1| |Aritet|1|
Line 137: Line 137:
   * Web administrator   * Web administrator
  
-Hvis der angives en rolle som personen ikke er berettiget til returnerer DDV fejlbeskeden:+Hvis der angives en rolle som personen ikke er berettiget tilreturnerer DDV fejlbeskeden:
   * “Brugeren er ikke berettiget til rollen <rolle>”.   * “Brugeren er ikke berettiget til rollen <rolle>”.
 Hvis der ikke kan findes en gyldig rolle for brugeren returneres: Hvis der ikke kan findes en gyldig rolle for brugeren returneres:
Line 147: Line 147:
 <RequestedRole>Tandlæge<RequestedRole> <RequestedRole>Tandlæge<RequestedRole>
  
-Det kræves af serviceaftager systemet, at den pågældende person er valideret og at opslaget på borgerens+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 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 anvende de nye roller skal disse felter derfor specificeres i SOAP headeren. Se afsnit om System autorisation
Line 153: Line 153:
  
 Adgang som medhjælp for en sundhedsfaglig person, kræver at der angives en MOCES signatur Adgang som medhjælp for en sundhedsfaglig person, kræver at der angives en MOCES signatur
-(medarbejder signatur), samt at strukturen OnBehalfOf sættes i SOAP headeren (se afsnit om Medhjælp for+(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 sundhedsfaglig). Et medhjælp-sundhedsfaglig forhold valideres altid mod det centrale
-bemyndigelsesregister eller systemets lokale replika heraf, baseret på data udstillet via NSP. Registeret kan+bemyndigelsesregister eller systemets lokale replikering heraf, baseret på data udstillet via NSP. Registeret kan
 vedligeholdes af den sundhedfaglige via eksempelvis medicin-it.dk. vedligeholdes af den sundhedfaglige via eksempelvis medicin-it.dk.
  
 +==== Medhjælp for sundhedsfaglig ====
  
 +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”:
 +
 +<code xml>
 +
 +<ddv:OnBehalfOf>
 +    <ddv:AuthorisationIdentifier>BR56T</ddv:AuthorisationIdentifier>
 +</ddv:OnBehalfOf>
 +
 +</code>
 +
 +==== Logning ====
 +
 +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:
 +
 +<code xml>
 +
 +<saml:Attribute Name="medcom:CareProviderName">
 +    <saml:AttributeValue>Anæstesiologisk overafd., Gentofte hospital</saml:AttributeValue>
 +</saml:Attribute>
 +
 +</code>
 +
 +CareProviderName må maximalt være på 50 tegn.
fmk/ddv/1.4.0/sikkerhedsmodel.1545891499.txt.gz · Last modified: (external edit)

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki