Page History

Versions Compared

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)	Nej service der er på vej -			-
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.8	10.02.2023	SDS	Tilføjet 2.2 hvornår minlog2 anvendes
1.7	10-06-2020	KvalitetsIT	Tilføjet information om udløb af idkort.
1.6	25-05-2020	KvalitetsIT	Tilføjet fejlkoder
1.5	26-04-2019	Openminds	Tilføjelse af MinLog1 lookup
1.4	07-09-2018	Openminds	Yderligere 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://<host>:<port>/minlog2-lookup/LookupService
https://<host>:<port>/minlog2-lookupid/LookupidService

og wsdl'erne

Lookup (V2)/Lookupid/Lookup (V1)

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

Lookup.V1 anvender MinLog1 formaterne og DGWS principperne til sikkerhed. Beskrivelser og anvendelse heraf ligger uden for nærværende dokuments område - men kan findes her https://svn.nspop.dk/public/components/minlog-ws/latest/doc/. Det skal dog understreges at operationen "listLogStatementsOnBehalfOf" ikke er implementeret.

Adresse

Servicene er kan findes på:

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

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

...

Autentifikation og autorisation

Autentifikation sikres på en af 2 måder

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.
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:

...

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

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.
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

http:// <host>:<port>/minlog1-lookup/LookupService?wsdl=Minlog.wsdl

...

icon	false
title	MinLog1

...

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

...

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 attributPersonIdentifierHash	∩	∩	0-1
LogDataGroup/Destination/ PersonNameCorrelationId	∩	∩	0-1
LogDataGroup/Destination/ CorrelationIdUserPersonName	∩	∩	0-1
LogDataGroup/Destination/ UserPersonIdentifierUserPersonIdentifierHash	∩	∩	0-1
LogDataGroup/Destination/ UserPersonIdentifier source attributLogDataGroupDestination/ UserRole	∩	∩	0-1
LogDataGroup/Destination/ UserPersonNameOnBehalfOfPersonName	∩	∩	0-1
LogDataGroupDestinationLogDataGroup/Destination/ UserRoleOnBehalfOfPersonIdentifierHash	∩	∩	0-1
LogDataGroup/Destination/ OnBehalfOfPersonIdentifierOnBehalfOfUserRole	∩	∩	0-1
LogDataGroup/Destination/ OnBehalfOfPersonIdentifier source attributOwnActivity	∩	∩	0-1
LogDataGroup/Destination/ OnBehalfOfPersonNameFilter	∩	∩	0-1

LogDataGroup/ Destination/ OnBehalfOfUserRole	∩	∩	0-1
LogDataGroup/Destination/Filter	∩	∩	0-1
LogDataEntry			0-	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">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: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 TesterPersonName>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)

...

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=214161460

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

...

Content

Space Tools

Versions Compared

Old Version 82

New Version Current

Key

Dokumenthistorik

Definitioner og forkortelser

Definitioner og forkortelser

Lookup (V2)/Lookupid

Autentifikation og autorisation

Versioner

Adresser, oprindelig version (2017)

Lookup (V2)/Lookupid/Lookup (V1)

Adresse

Adresser på udgaver med sikkerhedsheaders

Adresser, 2025-03-12-version

Autentifikation og autorisation

BeskedsID

Skemabeskrivelse

Adresser, 2025-10-06-version

Autentifikation og autorisation

BeskedsID

Skemabeskrivelse

Eksempel-request:

Eksempel-request:

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

Forældremyndighed - Subject Relations

Værgemyndighed - Subject Relations

Fuldmagt - Subject Relations

Fejl

Lookup eksempel – udløbet IDCard