Versions Compared

Old Version 85

changes.mady.by.user Kristian Dorland

Saved on

compared with

New Version Current

changes.mady.by.user Kristian Dorland

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Service ejer

Komponenter der registrerer til MinLog2

Services der registrerer til MinLog2  Ja /Nej

Juridisk grundlag

Dataansvarlig og Databehandler

Anvendersystem har ansvar for at sende  logregistrering til NSP

SDS

MinLog 2

  •  Ja

MinLog 2 logger sin egne log

SDS - dataansvarlig

  •  Ja via Dokumentdelingsservice 

SDS

Stamkortregister (SKR)

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6


SDS - dataansvarlig

Sundhed.dk - databehandler

  •  Ja via Dokumentdelingsservice 

Forudsætter kald med Niveau 4 ID-kort

SDS

Dokumentdelingsservice (DDS)

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Ja

SDS

Behandlingstestamenteregistret (BTR)

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS – dataansvarlig

  •  Ja via Dokumentdelingsservice 

SDS

Organdonorregistret (ODR)

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6


  •  Ja via Dokumentdelingsservice

SDS

Samtykke/Frabedelse

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Ja via Dokumentdelingsservice

SDS

Fælles Medicinkort (FMK)

  •  Ja

Sundhedslovens § 42c og § 157, stk. 14, nr. 3 samt FMK/DDV-bekendtgørelsens § 13.


SDS - dataansvarlig

  •  Nej Ikke via Dokumentdelingsservice

SDS

Det Danske Vaccinationsregistre (DDV)

  •  Ja

Sundhedslovens § 42 c og § 157a stk. 10 nr. 4 samt FMK/DDV-bekendtgørelsens § 13.

SSI - dataansvarlig

  •  Nej Ikke via Dokumentdelingsservice  

FUT

Telemedicin, K-PRO mv. via FUT

  •  Ja, men registrerer ikke via DDS

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

Den ansvarlige sundhedsmyndighed (kommuner og regioner)


  •  Nej Ikke via Dokumentdelingsservice

SDS

Graviditetsmappe GM

  •  Ja, anvendes p.t. ikke

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6


SDS - dataansvarlig

  •  Ja via Dokumentdelingsservice

SDS

Aftaler

  •  Ja 

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Ja via via Dokumentdelingsservice

Forudsætter kald med Niveau 4 ID-kort

SDS

Planer

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Ja via Dokumentdelingsservice

MedCom

PRO – metadata

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Ja via Dokumentdelingsservice

SDS

Fælles Stamkort (FSK)

  •  Ja

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Ja via Dokumentdelingsservice

SDS

Dokument Registrerings- og Opdateringsservice DROS

  •  Nej


SDS - dataansvarlig

  •  Nej

SDS

Behandlingsrelationsservice (BRS)

  •  Nej


SDS - dataansvarlig

  •  Nej

SDS

Nationaladviseringsservice (NAS)

  •  Nej


SDS - dataansvarlig

  •  Nej

SDS

Synkroniseringsservice til Fælles Stamkort (SFSK)

  •  Nej

For NSP:

Sundhedslovens § 193b, stk. 3, nr. 4 og NSP-bekendtgørelsens § 6

SDS - dataansvarlig

  •  Nej

SDS

Lægemiddelallergiregister (LAR)

  •  Nej bliver ikke brugt


-

-

Regioner

Elektroniskpatientjournal (EPJ)

  •  Nej

Logningsbekendtgørelsen:

Sundhedslovens § 42c, stk. 1 og 2. og bekendtgørelse nr. 200 af 
07/02/2022 samt ændring jvf. Bekendtgørelse 1201 af 25/08/2022 

Regioner - dataansvarlig

  •  Nej Ikke via Dokumentdelingsservice

LMST

Centrale Tilskudsregistre (CTR)

  •  Ja


LMST - dataansvarlig

  •  Nej Ikke via DokumentdelingsserviceS

LMST

Tilskudsansøgning (TAS)

  •  Ja


LMST - dataansvarlig

  •  Nej Ikke via Dokumentdelingsservice

SDS

Identitetssløring af Ansatte i Sundhedsvæsenet (IDSAS)

  •  JaNej



-

SDS

Fravalg af Genoplivning Ved Hjertestop Register  (FGVHR)

  •  Nej service der er på vej


-

-

SDS

Høremappen

  •  Nej service der er på vej


-

-



 

Dokumenthistorik




Definitioner og forkortelser

Definition

Version

Dato

Ansvarlig

Beskrivelse

1.810.02.2023SDSTilføjet 2.2  hvornår minlog2 anvendes
1.710-06-2020KvalitetsITTilføjet information om udløb af idkort. 
1.625-05-2020KvalitetsITTilføjet fejlkoder
1.526-04-2019OpenmindsTilføjelse af MinLog1 lookup
1.407-09-2018OpenmindsYderligere specifikation af borgerservice

1.3

12-11-2017

Openminds

Ny service

1.2

04-10-2017

Openminds

Skemaændringer i forbindelse med PersonIdentifiers

1.1

26-06-2017

Openminds

Tilføjelse af skemabeskrivelse og flere xml eksempler

1.0

15-06-2017

Openminds

Definitioner og forkortelser

...

Definition

...

Beskrivelse

...

NSP

...

Den nationale service platform (inden for sundheds-IT)

NSP

Den nationale service platform (inden for sundheds-IT)


Lookup (V2)/Lookupid

Der findes 2 services til opslag på log hændelser. 

Lookup.V2 og Lookupid anvender MinLog2 formaterne men differentiere sig dog på den anvendte sikkerhedsmodel. Lookup anvender DGWS principperne og Lookupid servicen OIOIDWS. Beskrivelser og anvendelse heraf ligger uden for nærværende dokuments område.

Autentifikation og autorisation

Autentifikation sikres med IDCard i SOAP header, som det er standard på NSP. Beskrivelsen af dette ligger uden for dette dokuments område.

Derudover er der indført whitelisting af snitflader, dvs. at for en given snitflade skal enten CVR eller certifikatets SSN være whitelisted i systemet af NSP. Dette skal gøres for den specifikke version af snitfladen man vil have adgang til.

Versioner

Lookup-services findes i disse aktuelle versioner:

  • Den oprindelige version fra 2017.
  • En ny version: 20250312 (som bl.a. overgår til nye ENUMs for organisationstype og persontype)
  • En nyere version (kun "lookupid"): 20251006 (hvor IDSWFault er fjernet)

Alle pånær nyeste version forventes udfaset når det er muligt.

Adresser, oprindelig version (2017)

Servicerne kan findes på:

  • https:

Lookup (V2)/Lookupid/Lookup (V1)

Der findes 3 services til opslag på log hændelser. 

Lookup.V2 og Lookupid anvender MinLog2 formaterne men differentiere sig dog på den anvendte sikkerhedsmodel. Lookup anvender DGWS principperne og Lookupid servicen OIOIDWS. Beskrivelser og anvendelse heraf ligger uden for nærværende dokuments område.

Adresse

...

  • //<host>:<port>/minlog2-lookup/LookupService
  • https://<host>:<port>/minlog2-lookupid/LookupidService

og wsdl'en erne på:

  • https://<host>:<port>/minlog2-lookup/LookupService?wsdl
  • https://<host>:<port>/minlog2-lookupid/LookupidService?wsdl

Autentifikation og autorisation

Autentifikation sikres på en af 2 måder

  1. For Lookup.V1 og Lookup.V2 - IDCard i SOAP header, som det er standard på NSP. Her gælder det at ID kortet maksimalt må være 9 timer gammelt. 
  2. For Lookupid - OIOIDWS

Lookup.V1 kræver autentifikationsniveau niveau 3 (FOCES/VOCES) og Lookup.V2 kræver autentifikationsniveau niveau 4 (MOCES).

Lookupid håndteres som implementeret i WSSEInInterceptor og foretager følgende:

  • Validering af signaturer
  • Validering af korrekt Audience
  • Validering af timestamp
  • Validering af eventuel fuldmagt
  • Udtræk af messageid og CPR/CVR til senere anvendelse

BeskedsID

Kaldere af servicen er forpligtet til at forsyne hvert kald med et unikt beskedsID (messageID) i headeren. Dette er standard NSP og beskrivelsen ligger uden for nærværende dokuments område.

Skemabeskrivelse

Skemaet til Lookup kan findes gennem servicen:

...

Adresser på udgaver med sikkerhedsheaders

For alle versioner gælder derudover,  at WSDL'erne også udstilles med sikkerhedsheaders:

  • https://<host>:<port>/minlog2-lookup/service-contract/secure-wsdl/minlog2-lookup.wsdl
  • https://<host>:<port>/minlog2-lookupid/service-contract/secure-wsdl/minlog2-lookupid.wsdl

Adresser, 2025-03-12-version

Servicerne kan findes på:

  • https://<host>:<port>/minlog2-lookup/20250312/LookupService

...

  • https://<host>:<port>/minlog2-lookupid/20250312/LookupidService

og wsdl'erne på:

  • https://<host>:<port>/minlog2-lookup/20250312/LookupService?wsdl
  • https

...

  • ://<host>:<port>/minlog2-lookupid/20250312/LookupidService?

...

  • wsdl

Adresser, 2025-10-06-version

Denne version findes kun for "lookupid".

Servicen kan findes på:

  • https://<host>:<port>/minlog2-lookupid/20250312/LookupidService

og wsdl'en på:

  • https://<host>:<port>/minlog2-lookupid/20250312/LookupidService?wsdl

Autentifikation og autorisation

Autentifikation sikres på en af 2 måder

  1. For Lookup.V2 - IDCard i SOAP header, som det er standard på NSP. Her gælder det at ID kortet maksimalt må være 9 timer gammelt. 
  2. For Lookupid - OIOIDWS

 Lookup.V2 kræver autentifikationsniveau niveau 4 (MOCES).

Lookupid håndteres som implementeret i WSSEInInterceptor og foretager følgende:

  • Validering af signaturer
  • Validering af korrekt Audience
  • Validering af timestamp
  • Validering af eventuel fuldmagt
  • Udtræk af messageid og CPR/CVR til senere anvendelse

BeskedsID

Kaldere af servicen er forpligtet til at forsyne hvert kald med et unikt beskedsID (messageID) i headeren. Dette er standard NSP og beskrivelsen ligger uden for nærværende dokuments område.

Skemabeskrivelse

Skemaet til Lookup kan findes gennem servicen:


http:// <host>:<port>/minlog2-lookup/LookupService?xsd=minlog2-lookup.xsd

http:// <host>:<port>/minlog2-lookupid/LookupidService?xsd=minlog2-lookup.xsd


De efterfølgende afsnit er udelukkende relateret til MinLog2 - request/response, operationer, fejl etc.

Request (MinLog2)

Følgende elementer anvendes request til opslaget:

Navn

Beskrivelse

Definition

Kardinalitet

LogStatementForCPRPersonRequest
LogStatementOnBehalfOfRequest

Rod-element for forespørgslen.


1

PersonIdentifier

CPR-nummer eller evt. erstatnings-CPR-nummer på borgeren der er slået op på.
Anvendes til "MinLog"-opslag.

Streng af længde 50

De efterfølgende afsnit er udelukkende relateret til MinLog2 - request/response, operationer, fejl etc.

Request (MinLog2)

Følgende elementer anvendes request til opslaget:

Navn

Beskrivelse

Definition

Kardinalitet

LogStatementForCPRPersonRequest
LogStatementOnBehalfOfRequest

Rod-element for forespørgslen.

1

PersonIdentifier

CPR-nummer eller evt. erstatnings-CPR-nummer på borgeren der er slået op på.
Anvendes til "MinLog"-opslag.

Streng af længde 50

0-1, valg mellem en af *PersonIdentifier-elementerne.

PersonIdentifier source attribut

Kilde til ID for borgerens CPR-nummer m.v.

CPR, E-CPR eller en Streng med max længde 200

1

OnBehalfOfPersonIdentifier

CPR-nummer, Initialer eller Autorisation af handlingen er udført på vegne af.
Anvendes til opslag i medhjælpsloggen.

Ved opslag på CPR-nummer beregner systemet hvilke autorisationer der hører til personen. Ved opslag på autorisation beregnes hvilket CPR-nummer der hører til autorisationen, og hvilke yderligere autorisationer der hører til CPR-nummeret. Registreringer for CPR-nummeret og alle tilhørende autorisationer returneres. Svaret er med andre ord det samme ved opslag på et CPR-nummer og personens tilhørende autorisationsnummer.

Streng af længde 501, valg mellem en af *OnBehalfOfPersonIdentifier-elementerne

0-1, valg mellem en af * OnBehalfOfPersonIdentifier PersonIdentifier-elementerne.

OnBehalfOfPersonIdentifier PersonIdentifier source attribut

Kilde til ID for OnBehalfOfPersonIdentifierborgerens CPR-nummer m.v.

CPR, E-CPR CPR, Initialer, Autorisation eller en Streng med max længde 200

1

OnBehalfOfPersonIdentifier

CPR-nummer, Initialer eller Autorisation af

Grouping

Angivelse af hvorledes svaret returneres:

  • Ikke grupperet
    eller grupperet efter:
  • Opslagssammenhæng (CorrelationId)
  • Dato
  • Organisation
  • Brugeren der har udført handlingen
    • Sundhedspersonen

    handlingen er udført på vegne af

    Streng, defineret som en union af en enumeration af
    "None",
    "Correlation", "Date", "Organisation", "UserPerson", "OnBehalfOfPerson" og en Streng med max længde 50

    1

    Details

    Angivelse af hvorvidt et grupperet svare skal indeholde detaljer. Alle detajler er pt. med i svaret uanset hvad denne er udfyldt med.

    Streng, defineret som en union af en enumeration af
    "All"

    0-1

    FilterPass

    Filtrering på kritikalitet og type af opslag der ønskes returneret

    0-1
    Valg mellem FilterPass, FilterStop eller intet filter

    .
    Anvendes til opslag i medhjælpsloggen.


    Ved opslag på CPR-nummer beregner systemet hvilke autorisationer der hører til personen. Ved opslag på autorisation beregnes hvilket CPR-nummer der hører til autorisationen, og hvilke yderligere autorisationer der hører til CPR-nummeret. Registreringer for CPR-nummeret og alle tilhørende autorisationer returneres. Svaret er med andre ord det samme ved opslag på et CPR-nummer og personens tilhørende autorisationsnummer.

    Streng af længde 501, valg mellem en af *OnBehalfOfPersonIdentifier-elementerne

    0-1, valg mellem en af * OnBehalfOfPersonIdentifier -elementerne

    OnBehalfOfPersonIdentifier source attribut

    Kilde til ID for OnBehalfOfPersonIdentifier

    CPR, Initialer, Autorisation eller en Streng med max længde 200

    1

    Grouping

    Angivelse af hvorledes svaret returneres:

    • Ikke grupperet
      eller grupperet efter:
    • Opslagssammenhæng (CorrelationId)
    • Dato
    • Organisation
    • Brugeren der har udført handlingen
    • Sundhedspersonen handlingen er udført på vegne af

    FilterPass/ Criticality

    Et antal angivelser af kritikalitet til filtreringen (privatmarkeret eller ingen angivelse)

    Streng, defineret som en union af en enumeration af niveau for kritikalitet, og en Streng med max længde 50 tegn

    0-*

    FilterPass/ Addition

    Et antal angivelser af tilføjelser til filtreringen (samtykke, værdispring eller ingen angivelse)

    Streng, defineret som en union af en enumeration af
    "None",
    "Correlation", "Date", "Organisation", "UserPerson", "OnBehalfOfPerson" og en Streng med max længde 50 tegn

    0-*1

    Details

    Angivelse af hvorvidt et grupperet svare skal indeholde detaljer. Alle detajler er pt. med i svaret uanset hvad denne er udfyldt med.

    Streng, defineret som en union af en enumeration af
    "All"

    0-1

    FilterPass

    Filtrering på kritikalitet og type af opslag der ønskes returneret

    FilterStop

    Filtrering på kritikalitet og type af opslag der ikke ønskes returneret.


    0-1
    Valg mellem FilterPass, FilterStop eller intet filter

    FilterStopFilterPass/ Criticality

    Et antal angivelser af kritikalitet til filtreringen (privatmarkeret eller ingen angivelse)

    Streng, defineret som en union af en enumeration af niveau for kritikalitet, og en Streng med max længde 50 tegn

    0-*

    FilterStopFilterPass/ Addition

    Et antal angivelser af tilføjelser til filtreringen (samtykke, værdispring eller ingen angivelse)

    Streng, defineret som en union af en enumeration, og en Streng med max længde 50 tegn

    0-*

    Chronologic

    Med true angives at data returneres i kronologisk rækkefølge, med false i omvendt kronologisk rækkefølge.

    Boolean

    1

    FilterStop

    Filtrering på kritikalitet og type af opslag der ikke ønskes returneret.


    0-1
    Valg mellem FilterPass, FilterStop eller intet filter

    FilterStop/ Criticality

    Et antal angivelser af kritikalitet til filtreringen (privatmarkeret eller ingen angivelse)

    Streng, defineret som en union af en enumeration af niveau for kritikalitet, og en Streng med max længde 50 tegn

    0-*

    FilterStop/ Addition

    Et antal angivelser af tilføjelser til filtreringen (samtykke, værdispring eller ingen angivelse)

    Streng, defineret som en union af en enumeration, og en Streng med max længde 50 tegn

    0-*

    Chronologic

    Med true angives at data returneres i kronologisk rækkefølge, med false i omvendt kronologisk rækkefølge.

    Boolean

    1

    DateTime

    DateTime-elementet indeholder en eksakt tidsangivelse for opslag.
    Dato og tid skal angives i zulu tid / UTC. I praksis gøres dette ved at tilføje Z efter tidsangivelsen, samt at korrigere for

    DateTime

    DateTime-elementet indeholder en eksakt tidsangivelse for opslag.
    Dato og tid skal angives i zulu tid / UTC. I praksis gøres dette ved at tilføje Z efter tidsangivelsen, samt at korrigere for de 1-2 timers forskel (henholdsvis vinter- og sommertid) der er mellem dansk tid og UTC. Tiden angives med en præcision i sekunder

    DateTime

    0-1

    FromDateTime

    Der returneres data fra og med dette tidspunkt, angivet med sekunders præcision.

    DateTime

    0-1
    Enten skal DateTime eller (FromDateTime og ToDateTime) forekomme

    ToDateTime

    Der returneres data til og med dette tidspunkt.

    DateTime

    0-1
    Enten skal DateTime eller (FromDateTime og ToDateTime) forekomme

    PageSize

    Det maksimale antal datasæt der ønskes returneret.
    Antallet gælder antal LogDataEntry i svaret.

    Integer, med en restriction > 0

    0-1

    PageNumber

    Element der anvendes ved paginering og angiver hvilken side der ønskes.

    Integer, med en restriction > 0

    0-1

    ...

    Navn

    Beskrivelse

    Definition

    Kardinalitet

    ListLogStatementsResponse

    Rod-element for svaret.


    1

    LogDataGroup

    Rod-elementet for en gruppe.


    0..*, dog ikke flere end evt. angivet i PageSize

    NumberOfLogDataEntries

    Antal logninger i gruppen, dvs. svarende til antal LogDataEntry-elementer der kan returneres.

    Integer, med en restriction > 0

    1

    LogDataGroup/Source

    ∩
    Opslagene kan være foretaget af samme kildesystem, men kan også komme fra en kæde af registreringskald fra forskellige systemer.


    0-1

    LogDataGroup/Source/ SystemName

    ∩
    Såfremt der er grupperet en kæde af opslag fra forskellige systemer vil systemnavnene være forskellige, og derfor ikke returneret i gruppen.

    ∩

    0-1

    LogDataGroup/Source/ CorrelationId

    ∩
    Såfremt CorrelationId er angivet i kaldet til registreringsservicen vil værdien være anvendt til gruppering og derfor forekomme for gruppen.

    ∩

    0-1

    LogDataGroup/Destination

    ∩

    ∩

    1

    LogDataGroup/Destination/ SystemName

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ Activity

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ Reason

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ Criticality

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ Addition

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ FromDateTime

    Ældste DateTime eller FromDateTime i gruppen

    DateTime

    1

    LogDataGroup/Destination/ ToDateTime

    Yngste DateTime eller ToDateTime i gruppen

    DateTime

    1

    LogDataGroup/Destination/ OrganisationId

    ∩

    ∩

    0-1

    LogDataGroup/ OrganisationId/Destination/ attribut source

    ∩

    ∩

    1

    LogDataGroup/Destination/ OrganisationName

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ PersonIdentifierPersonName

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ PersonIdentifiersource attribut

    ∩

    ∩

    1

    LogDataGroup/Destination/ PersonNamePersonIdentifierHash

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ CorrelationId

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ UserPersonIdentifierUserPersonName

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ UserPersonIdentifier source attributUserPersonIdentifierHash

    ∩

    ∩

    1

    LogDataGroup/Destination/ UserPersonName

    ∩

    ∩

    0-1

    LogDataGroupDestination/ UserRole

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ OnBehalfOfPersonIdentifierOnBehalfOfPersonName

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ OnBehalfOfPersonIdentifier source attributOnBehalfOfPersonIdentifierHash

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ OnBehalfOfPersonNameOnBehalfOfUserRole

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ OnBehalfOfUserRoleOwnActivity

    ∩

    ∩

    0-1

    LogDataGroup/Destination/ Filter

    ∩

    ∩

    0-1





    LogDataGroup/ LogDataEntry



    0-*

    LogDataGroup/ LogDataEntry/Source

    Element der indeholder information omkring det kaldende system, kildesystemet.
    Kildesystemet kan være udeladt i de tilfælde en bruger har slået direkte op på systemet.


    0-1

    LogDataGroup/ LogDataEntry/Source/Source[/...]

    Source-elementet kan igen indeholde et source-element. Dette anvendes såfremt kildesystemet igen er kaldt af et andet system.


    0-1

    LogDataGroup/ LogDataEntry/Source/ SystemName

    Navn, evt. forkortet, for det anvendte kilde-system

    Streng med max længde på 25 tegn

    0-1

    LogDataGroup/ LogDataEntry/Source/ CorrelationId

    Et teknisk id, medsendt fra kildesystemet. Værdien anvendes til at identificere den sammenhæng som handlingen er gennemført i, eksempelvis et id for behandlingen eller indlæggelsen (EPJ) eller kontakten (LPS).
    Værdien skal være unik for det anvendte system.

    Streng med max længde på 46 tegn.

    0-1

    LogDataGroup/ LogDataEntry/Destination

    Element der indeholder information omkring og fra det kaldte system, destinations-systemet, dvs. det system der foretager logningen.


    1

    LogDataGroup/ LogDataEntry/Destination/ SystemName

    Navn, evt. forkortet, for det anvendte system, f.eks. "FMK".

    Streng med max længde på 25 tegn

    1

    LogDataGroup/ LogDataEntry/Destination/Activity

    Tekst der beskriver af den handling, som brugeren har udført eller forsøgt udført på kildesystemet.
    Eksempelvis "hent medicinkort" på FMK.

    Streng, max længde på 75 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ Reason

    Optionel tekst der beskriver årsagen til den handling, som brugeren har udført eller forsøgt udført på kildesystemet. Teksten anvendes kun i særlige tilfælde, hvor borgeren ikke har direkte kontakt til brugeren, eksempelvis ved support, fejlsøgning og tilskudsansøgninger.
    Teksten udfyldes af systemet, som en eller få forud-definerede tekster, og må ikke være en fritekst udfyldt af brugeren.

    Streng, max længde på 50 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ Criticality

    Niveau for kritikalitet, f.eks:
    "Normal", "Værdispring", "Privatmarkerede data", …
    Er værdien ikke angivet svarer dette til "Normal".

    Streng med max længde 50 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/Addition

    Angivelse af type af opslag som tilføjelse til kritikalitet, aktuelt "Samtykke" eller "Værdispring"

    Streng med max længde 50 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ DateTime

    DateTime-elementet indeholder en tidsangivelse for opslag på eller forsøg på handling på borgerens data.

    DateTime

    0-1
    Enten skal DateTime eller (FromDateTime og ToDateTime) forekomme.

    LogDataGroup/ LogDataEntry/Destination/ FromDateTime

    Som alternativ til DateTime herover kan der være foretaget en gruppering af f.eks. FMK inden data er afleveret til MinLog 2. I så fald kan FromDateTime og ToDateTime angive det interval hvor hændelserne er sket.
    FMK kan gruppere samme type servicekald foretaget inden for et tidsrum på samme borger og af samme aktør m.v.

    DateTime

    0-1
    Enten skal DateTime eller (FromDateTime og ToDateTime) forekomme.

    LogDataGroup/ LogDataEntry/Destination/ ToDateTime

    Se FromDateTime herover.

    DateTime

    0-1Enten skal DateTime eller (FromDateTime og ToDateTime) forekomme.

    LogDataGroup/ LogDataEntry/Destination/ OrganisationId

    ID for brugerens organisation.

    Streng på max 200 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ OrganisationId attribut source

    Kilde til ID for brugerens organisation, defineret som en attribut på OrganisationId-elementet.

    SOR, SKS, Yder, CVR-P, CVR, Kommunekode og en Streng med max længde 200YDER, CVR eller EuropeanHealthcareOrganisation

    1

    LogDataGroup/ LogDataEntry/Destination/ OrganisationName

    Navn på brugens organisation

    Streng med max længde 200

    0-1

    LogDataGroup/ LogDataEntry/Destination/ PersonIdentifier

    CPR-nummer eller evt. erstatnings-CPR-nummer på borgeren.

    Streng af længde 50

    PersonName

    Borgerens navn.

    Streng med max længde 147 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ PersonIdentifier attribut source

    Kilde til ID for borgerens CPR-nummer eller erstatnings-CPR-nummer.
    F.eks. "CPR" for almindelige CPR-numre i CPR-regstret.

    CPR, E-CPR, ... og en Streng med max længde 200

    1

    PersonIdentifierHash

    Hash af personens identifier. Laves med et unikt salt for hvert response.

    Streng med max længde 64

    LogDataGroup/ LogDataEntry/Destination/ PersonName

    Borgerens navn.

    Streng med max længde 147 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ CorrelationID

    Et teknisk id, medsendt fra kildesystemet. Værdien anvendes til at identificere den sammenhæng som handlingen er gennemført i, eksempelvis et id for behandlingen eller indlæggelsen (EPJ) eller kontakten (LPS).
    Værdien skal være unik for det anvendte system.

    Streng med max længde på 46 tegn.

    0-1

    LogDataGroup/ LogDataEntry/Destination/ UserPersonIdentifierUserPersonName

    Navn CPR-nummer eller evt. erstatnings-CPR-nummer på brugeren der har udført handlingen.

    Streng af med max længde 50147 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ UserPersonIdentifier attribut source

    Kilde til UserPersonIndentifier.
    F.eks. "CPR" for almindelige CPR-numre i CPR-regstret.

    CPR, E-CPR, ... og en Streng med max længde 200

    1

    UserPersonIdentifierHash

    Hash af personens identifier. Laves med et unikt salt for hvert response.

    Streng med max længde 64

    LogDataGroup/ LogDataEntry/Destination/ UserPersonName

    Navn på brugeren der har udført handlingen.

    Streng med max længde 147 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ UserRole

    Brugerens rolle.

    Streng af længde 200 (svarende til FMK's RequestedRole)

    0-1

    LogDataGroup/ LogDataEntry/Destination/ OnBehalfOfPersonIdentifierOnBehalfOfPersonNavn

    Navn CPR-nummer eller evt. erstatnings-CPR-nummer på brugeren handlingen er udført på vegne af.

    Streng med max længde 50147 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ OnBehalfOfPersonIdentifier attribut source

    Kilde til OnBehalfOfPersonIdentifier.
    F.eks. "CPR" for almindelige CPR-numre i CPR-regstret.

    OnBehalfOfPersonIdentifierHash

    Hash af personens identifier. Laves med et unikt salt for hvert response.

    CPR, E-CPR, ... og en Streng med max længde 20064 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/ OnBehalfOfPersonNavn

    Navn på brugeren handlingen er udført på vegne af.

    OwnActivity

    Om det er personen, der laver opslagt, som der også bliver slået op på. Udfyldes kun ved IDWS.

    True eller falseStreng med max længde 147 tegn

    0-1

    LogDataGroup/ LogDataEntry/Destination/Filter

    Et eller flere felter der anvendes til angivelse af hvilken målgruppe logningen skal filtreres fra for.
    Udelades feltet er der underforstået at logningen er relevant for alle.

    Streng, aktuelt defineret som en union af en enumeration aktuelt indeholdende " Ikke borger" , "Ikke forældremyndighedsindehaver" og en Streng med max længde 50 tegn.

    0-*

    ...

    Denne operation anvendes når der skal foretages opslag i medhjælpsloggen, dvs. på handlinger der er foretaget på vegne af den sundhedsperson der slå op i medhjælpsloggen. Efterfølgende vises body-delen af soap requestet. Check evt. integrationtest GetStatementsOnBehalfOfTest for komplet soaprequest.

    Eksempel-request:

    Fra 20250312 snitfladen vil soapaction have prefix på sig GetLogStatementsOnBehalfOf_{Snitflade version}. Det kunne for eksempel være for 20250312 versionen: GetLogStatementsOnBehalfOf_20250312.

    Eksempel-request:

    …….
    …….
    <ml2:LogStatementOnBehalfOfRequest xmlns:ml2="http://www.sundhedsdatastyrelsen.dk/minlog/xml.schema/2017/03/01/minlog2-registration.xsd">
    <ns:OnBehalfOfPersonId source="CPR">0707701045</ns:OnBehalfOfPersonId>
    <ns:Grouping>None</ns:Grouping>
    <ns:Details>All</ns:Details>
    <ns:Chronologic>true</ns:Chronologic>
    </ml2:LogStatementOnBehalfOfRequest>
    …….
    …….

    ...

    …….
    …….
    <ns6:LogStatementsResponse

        xmlns:ns6="http://www.sundhedsdatastyrelsen.dk/minlog/xml.schema/2017/03/01/minlog2-lookup.xsd">
            <ns6:LogDataEntry>
                <ns6:Source>
                    <ns6:Source>
                        <ns6:SystemName>TestSubSystem</ns6:SystemName>
                        <ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
                    </ns6:Source>
                    <ns6:SystemName>TestSystem</ns6:SystemName>
                    <ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
                </ns6:Source>
                <ns6:Destination>
                    <ns6:SystemName>Integrationtest</ns6:SystemName>
                    <ns6:Activity>Inserting</ns6:Activity>
                    <ns6:Reason>h</ns6:Reason>
                    <ns6:Criticality>Ingen</ns6:Criticality>
                    <ns6:DateTime>2017-04-03T20:20:14.000+02:00</ns6:DateTime>
                    <ns6:OrganisationId source="Openminds">240971000016006</ns6:OrganisationId>
                    <ns6:OrganisationName>SOR</ns6:OrganisationName>
                    <ns6:PersonIdentifier source="CPR">2412752045</ns6:PersonIdentifier>
                    <ns6:PersonName>Test Tester</ns6:PersonName>
                    <ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
                    <ns6:UserPersonIdentifier source="CPR">2412751044</ns6:UserPersonIdentifier>
                    <ns6:UserPersonName>Sygeplejerske Jensen</ns6:UserPersonName>
                    <ns6:UserRole>UserRole</ns6:UserRole>
                    <ns6:OnBehalfOfPersonId source="CPR">2412751946OnBehalfOfPersonName>Læge Olsen</ns6:OnBehalfOfPersonId>OnBehalfOfPersonName>
                    <ns6:OnBehalfOfPersonName>Læge OlsenOnBehalfOfUserRole>OnBehalfOfUserRole</ns6:OnBehalfOfPersonName>OnBehalfOfUserRole>
                    <ns6:OnBehalfOfUserRole>OnBehalfOfUserRole</ns6:OnBehalfOfUserRole>
                    <ns6:Filter>Ikke forældremyndighedsindehaver</ns6:Filter>
                </ns6:Destination>
            </ns6:LogDataEntry>
            <ns6:LogDataEntry>
                <ns6:Source>
                    <ns6:Source>
                        <ns6:SystemName>TestSubSystem</ns6:SystemName>
                        <ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
                    </ns6:Source>
                    <ns6:SystemName>TestSystem</ns6:SystemName>
                    <ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
                </ns6:Source>
                <ns6:Destination>
                    <ns6:SystemName>Integrationtest</ns6:SystemName>
                    <ns6:Activity>Inserting</ns6:Activity>
                    <ns6:Reason>h</ns6:Reason>
                    <ns6:Criticality>Ingen</ns6:Criticality>
                    <ns6:DateTime>2017-06-16T09:23:13.000+02:00</ns6:DateTime>
                    <ns6:OrganisationId source="Openminds">240971000016006</ns6:OrganisationId>
                    <ns6:OrganisationName>SOR</ns6:OrganisationName>
                    <ns6:PersonIdentifier source="CPR">2412752045</ns6:PersonIdentifier>
                    <ns6:PersonName>Test Tester</ns6:PersonName>
                    <ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
                    <ns6:UserPersonIdentifier source="CPR">2412751044</ns6:UserPersonIdentifier>
                    <ns6:UserPersonName>Sygeplejerske Jensen</ns6:UserPersonName>
                    <ns6:UserRole>UserRole</ns6:UserRole>
                    <ns6:OnBehalfOfPersonId source="CPR">2412751946</ns6:OnBehalfOfPersonId>
                    <ns6:OnBehalfOfPersonName>Læge Olsen</ns6:OnBehalfOfPersonName>
                    <ns6:OnBehalfOfUserRole>OnBehalfOfUserRole</ns6:OnBehalfOfUserRole>
                    <ns6:Filter>Ikke forældremyndighedsindehaver</ns6:Filter>
                </ns6:Destination>
            </ns6:LogDataEntry>
    </ns6:LogStatementsResponse>

    …….
    …….

    Sløring af ansatte i sundhedsvæsenet (IDSAS)

    En del af responset kan være sløret, nærmere bestemt værdierne i:

    • UserPersonName
    • OnBehalfOfPersonName

    Dette vil ske, hvis der i requestets sikkerhedsbillet er angivet, at visse organisationers ansattes navne skal sløres. Hvis der i svaret er organisationer der matcher dette kriterie, vil navnene været udskiftet med et pseudonym, som er beregnet ud fra algoritmen beskrevet her: 3. (C) Pseudonymisering i datakilder til borgervendte brugergrænsefladesystemer
    IDSAS-servicen vedligeholder et register over alle borgere der skal sløres over for bestemte organisationer, og det er dette register der bruges, når sikkerhedsbilletten udstedes.

    Forældremyndighed - Subject Relations

    ns6:LogDataEntry>
    </ns6:LogStatementsResponse>

    …….
    …….


    Sløring af ansatte i sundhedsvæsenet (IDSAS)

    En del af responset kan være sløret, nærmere bestemt værdierne i:

    • UserPersonName
    • OnBehalfOfPersonName

    Dette vil ske, hvis der i requestets sikkerhedsbillet er angivet, at visse organisationers ansattes navne skal sløres. Hvis der i svaret er organisationer der matcher dette kriterie, vil navnene været udskiftet med et pseudonym, som er beregnet ud fra algoritmen beskrevet her: 3. (C) Pseudonymisering i datakilder til borgervendte brugergrænsefladesystemer
    IDSAS-servicen vedligeholder et register over alle borgere der skal sløres over for bestemte organisationer, og det er dette register der bruges, når sikkerhedsbilletten udstedes.

    Bemærk, at registreringer i minlog, hvor organisationen er registreret med et YderNr, også kan ende med at blive slørret, da der ved opslag mappes fra yder til CVR. Dvs. hvis det CVR, der mappes til, er en del af en afdelingssløring, vil opslaget blive slørret akkurat som hvis registreringen havde været på selve CVR-nummeret.

    Forældremyndighed - Subject Relations

    Det er muligt for en borger at tilgå minlog på vegne af et barn, hvis der er tale om gyldig forældremyndighed. Dette gøres i praksis ved at claime "Parental Custody" igennem Subject Relations Profile, når man får udstedt en borgerbillet fra STS'en. Se STS - Design- og Arkitekturbeskrivelse.

    Bemærk, at for at der bliver sløret korrekt, er det vigtigt at kaldet til NSP ifm. Minlog opslag indeholder det fornødne claim overfor STS ift. profilerne til  BlurringInstructions og SubjectRelations, som findes her: https://www.nspop.dk/pages/viewpage.action?pageId=214161460

    Værgemyndighed - Subject Relations

    Man kan også claime værgemyndighed, akkurat som man gør med forældremyndighed. Her kræver det dog, at kalderens certifikat er blevet whitelisted til at kunne claime "ward custody" igennem SubjectRelations. Denne whitelisting skal foretages både i STS'en og i MinLog-konfigurationen. I praksis er det kun FMK der vil få denne mulighed.

    Fuldmagt - Subject Relations

    Det er ligeledes muligt for en borger med en fuldmagt at tilgå minlog. Dette gøres ved at claime ”Basic Privilege” igennem Subject Relations Profile, når der udstedes en borgerbillet fra STS’en.

    Der er ligeledes her vigtigt at kaldet til NSP ifm. Minlog opslaget indeholder det fornødne claim overfor STS ift. profilerne til  BlurringInstructions og SubjectRelations, som findes her: https://www.nspop.dk/pages/viewpage.action?pageId=214161460Det er muligt for en borger at tilgå minlog på vegne af et barn, hvis der er tale om gyldig forældremyndighed. Dette gøres i praksis ved at claime "Parental Custody" igennem Subject Relations Profile, når man får udstedt en borgerbillet fra STS'en. Se STS - Design- og Arkitekturbeskrivelse.

    Fejl

    Fejl bliver returneret som SOAP faults. Nedenfor et par eksempler.

    ...


    <soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
            <soap:Header>
                <Header xmlns="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
                    <Linking>
                        <FlowID>flow_id</FlowID>
                        <MessageID>e2b70be5-1963-4075-9bb6-5a9f9f2abe2b</MessageID>
                        <InResponseToMessageID>AAABXKuWHvzAcmdMGdVr6VNPU0k=</InResponseToMessageID>
                    </Linking>
                    <FlowStatus>flow_finalized_succesfully</FlowStatus>
                </Header>
                <ns4:Security
                xmlns="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
                xmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion"
                xmlns:ns3="http://www.w3.org/2000/09/xmldsig#"
                xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd">
                    <Timestamp>
                        <Created>2017-06-15T11:49:21Z</Created>
                    </Timestamp>
                </ns4:Security>
            </soap:Header>
            <soap:Body>
                <ns7:RegistrationResponsexmlns:ns2="urn:oasis:names:tc:SAML:2.0:assertion"
                xmlns:ns3="http://www.w3.org/2000/09/xmldsig#"
                xmlns:ns4="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"
                xmlns:ns5="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd"
                xmlns:ns6="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"
                xmlns:ns7="http://www.sundhedsdatastyrelsen.dk/minlog/xml.schema/2017/03/01/minlog2-registration.xsd">
                    <FailedLogDataEntries>
                        <FaultCode>104</FaultCode>
                        <FaultText>Duplicate logentry</FaultText>
                        <SequenceNumber>1</SequenceNumber>
                    </FailedLogDataEntries>
                    <NumberAdded>0</NumberAdded>
                    <NumberFailed>1</NumberFailed>
                </ns7:RegistrationResponse>
            </soap:Body>
    </soap:Envelope>

    Lookup eksempel – udløbet IDCard

    ...