Differences

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

--- fmk:ddv:1.4.0:sikkerhedsmodel [2018-12-27 06:14] – nig
+++ fmk: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
-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.:
@@ Line 15: / Line 15: @@
 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
 headeren. Det er derfor ikke bundet til en session, men kan variere fra en forespørgsel til næste.
@@ Line 33: / Line 33: @@
   * 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 ==
@@ Line 50: / Line 50: @@
 Der introduceres en ny SOAP header, som indeholder navnet på afsendersystemet.
-|Navn|sdsd:SysteName|
+|Navn|sdsd:SystemName|
 |Type|xs:string|
 |Aritet|1|
@@ Line 105: / Line 105: @@
 </code>
+==== Fejlmeddelser for system authorisation ====
+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).
+==== Roller og rettigheder ====
+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.
+==== 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.