Indhold

Indledning

Dette dokument indeholder beskrivelse af, hvordan løsningen anvendes.

Læsevejledning

Læseren forventes at have kendskab til National Sundheds-IT's platform NSP, samt generelt kendskab til webservices herunder xml. Dokumentation som falder udenfor dette dokuments område kan findes på:

https://www.nspop.dk/display/web/Dokumentation.

Man skal gennemlæse vejledningsdokumentet.

Hvornår minLog2 anvendes

Minlog2 modtager registreringer om opslag på borgeres data. For alle opslag der går gennem NSP-dokumentdeling med niveau 4 ID-kort, sørger NSP for minlogregistrering. Og for andre logregistreringer, hvor kildesystemer ønsker at anvende minlog2 til log-opsamling, skal kildesystemet anvende minlog-registreringssnitfladen (Sundhed.dk, EPJ, FMK, DDV, opslag via FUT)

Logvisning for borger skal ske ift. rette juridiske grundlag. Derfor MinLog2 skal anvendes, når der er et lovgrundlag der tilsiger det.

I nedenstående tabel fremgår en oversigt over hvilke services, der kalder og logger til MinLog 2 i dag med angivelse af efter hvilken bestemmelse, der logges.

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			-
SDS	Fravalg af Genoplivning Ved Hjertestop Register (FGVHR)	Nej service der er på vej		-	-
SDS	Høremappen	Nej service der er på vej		-	-

Definitioner og forkortelser

Definition	Beskrivelse
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

Begge de to lookup-services findes i to version:

Den aktuelle version fra 2017.
En ny version: 20240111 (som ikke længere sender CPR numre i retursvar)
En ny version: 20250312 (som bl.a. overgår til nye ENUMs for organisationstype og persontype)

I løbet af 2025 vil 2017-versionen blive udfaset.

Adresser, 2017-versionen

Servicerne er kan findes på:

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

og wsdl'en på:

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

Derudover udstilles WSDL'erne er også 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, 2024-versionen

Servicerne er kan findes på:

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

og wsdl'en på:

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

Adresser, 2025-versionen

Servicerne er kan findes på:

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

og wsdl'en på:

https://<host>:<port>/minlog2-lookup/20250312/LookupService?wsdl
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

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 -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	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
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, og en Streng med max længde 50 tegn	0-*
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 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

Response (MinLog2)

Følgende elementer returneres i svaret fra Lookup:

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/ PersonName	∩	∩	0-1
LogDataGroup/Destination/ PersonIdentifierHash	∩	∩	0-1
LogDataGroup/Destination/ CorrelationId	∩	∩	0-1
LogDataGroup/Destination/ UserPersonName	∩	∩	0-1
LogDataGroup/Destination/ UserPersonIdentifierHash	∩	∩	0-1
LogDataGroupDestination/ UserRole	∩	∩	0-1
LogDataGroup/Destination/ OnBehalfOfPersonName	∩	∩	0-1
LogDataGroup/Destination/ OnBehalfOfPersonIdentifierHash	∩	∩	0-1
LogDataGroup/Destination/ OnBehalfOfUserRole	∩	∩	0-1
LogDataGroup/Destination/ OwnActivity	∩	∩	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, YDER, CVR eller EuropeanHealthcareOrganisation	1
LogDataGroup/ LogDataEntry/Destination/ OrganisationName	Navn på brugens organisation	Streng med max længde 200	0-1
LogDataGroup/ LogDataEntry/Destination/ PersonName	Borgerens navn.	Streng med max længde 147 tegn	0-1
LogDataGroup/ LogDataEntry/Destination/ PersonIdentifierHash	Hash af personens identifier. Laves med et unikt salt for hvert response.	Streng med max længde 64 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/ UserPersonName	Navn på brugeren der har udført handlingen.	Streng med max længde 147 tegn	0-1
LogDataGroup/ LogDataEntry/Destination/ UserPersonIdentifierHash	Hash af personens identifier. Laves med et unikt salt for hvert response.	Streng med max længde 64 tegn	0-1
LogDataGroup/ LogDataEntry/Destination/ UserRole	Brugerens rolle.	Streng af længde 200 (svarende til FMK's RequestedRole)	0-1
LogDataGroup/ LogDataEntry/Destination/ OnBehalfOfPersonNavn	Navn på brugeren handlingen er udført på vegne af.	Streng med max længde 147 tegn	0-1
LogDataGroup/ LogDataEntry/Destination/ OnBehalfOfPersonIdentifierHash	Hash af personens identifier. Laves med et unikt salt for hvert response.	Streng med max længde 64 tegn	0-1
LogDataGroup/ LogDataEntry/Destination/ OwnActivity	Om det er personen, der laver opslagt, som der også bliver slået op på. Udfyldes kun ved IDWS.	True eller false	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-*

Paging kan håndteres på forskellig vis. Den simple udgave er at man kan angive et antal (pagesize) på requestet - hvis der returneres en tilsvarende antal - så bør man spørge efter næste side - indtil der returneres færre end angivet.

Operationer (MinLog2)

Nedenfor følger en oversigt over de tilgængelige operationer.

GetLogStatementsOnBehalfOf

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.

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

Eksempel-response:

…….
…….
<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:PersonName>Test Tester</ns6:PersonName>
<ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
<ns6:UserPersonName>Sygeplejerske Jensen</ns6:UserPersonName>
<ns6:UserRole>UserRole</ns6:UserRole>
<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:PersonName>Test Tester</ns6:PersonName>
<ns6:CorrelationId>40075148-7b1b-476c-b5c3-4181a39650c5</ns6:CorrelationId>
<ns6:UserPersonName>Sygeplejerske Jensen</ns6:UserPersonName>
<ns6:UserRole>UserRole</ns6:UserRole>
<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

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.

Fejlkoder

GENERAL_ERROR = "101";
VALIDATION_ERROR = "102";
UNKNOWN_IDENTIFIER_SRC = "103";
DUPLICATE = "104";
MAX_ALLOWED_SIZE_ERROR = "105";

Lookup eksempel – Duplicate logentry

<soap:Envelope xmlns: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:RegistrationResponse 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"
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

Nedenstående er eksempel på svar ved udløbet IDCard:

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<Header xmlns="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
<Linking>
<FlowID>flow_id</FlowID>
<MessageID>d8f950b4-d4f4-4fa6-9b4c-42c1e5183860</MessageID>
<InResponseToMessageID>ef539d3e-5c23-4b00-a88d-44f54ce52ad3</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-29T14:28:13Z</Created>
</Timestamp>
</ns4:Security>
</SOAP-ENV:Header>
<soap:Body>
<soap:Fault xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/">ns1:Server</faultcode>
<faultstring>IDCard expires after 9 hours</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>

Lookup eksempel – Forkert autentifikationsniveau

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
<Header xmlns="http://www.medcom.dk/dgws/2006/04/dgws-1.0.xsd">
<Linking>
<FlowID>flow_id</FlowID>
<MessageID>188963a9-6038-49a4-922f-5425d4be98a9</MessageID>
<InResponseToMessageID>AAABXO3Fbsg86L0drZOiylNPU0k=</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-28T08:15:58Z</Created>
</Timestamp>
</ns4:Security>
</SOAP-ENV:Header>
<soap:Body>
<soap:Fault xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<faultcode xmlns:ns1="http://schemas.xmlsoap.org/soap/envelope/">ns1:Server</faultcode>
<faultstring> Caller must be authenticated at level 4</faultstring>
</soap:Fault>
</soap:Body>
</soap:Envelope>

Lookupid eksempel – Forkert audience

<S11:Envelope xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" xmlns="http://docs.oasis-open.org/ws-sx/ws-trust/200512" xmlns:wsa="http://www.w3.org/2005/08/addressing"><S11:Header><wsa:MessageID>uuid:ae4c3981-0628-4dbd-9e26-b1647930ae1b</wsa:MessageID><wsa:RelatesTo>uuid:f77f0581-7768-4292-9eac-6717a7724374</wsa:RelatesTo></S11:Header><S11:Body><S11:Fault>
<faultcode>wst:InvalidRequest</faultcode>
<faultstring>The request was invalid or malformed</faultstring>
</S11:Fault>
</S11:Body></S11:Envelope>

User stories

Testcases borgeropslag (IDWS snitfladen)
OPSLAG_PAA_EGNE_DATA_ALLE	Precondition: Der er registreret 3 min log registreringer på borger Action: Borgeren laver opslag på minlog2 uden begrænsning på tid. Postcondition: Brugeren får 4 min log registreringer returneret. Fire af registreringerne svarer til dem der er blevet registreret. Den sidste registrering svarer til den registrering der er lavet med at borgeren har set på egne data.
OPSLAG_PAA_EGNE_DATA_SIDSTE_5_MINUTTER	Precondition: Der er registreret 3 min log registreringer på borger inden for de sidste 5 minutter. Der er registreret 1 min log registrering ældre end 5 minutter. Action: Borgeren laver opslag på minlog2 begrænset til seneste 5 minutter. Postcondition: Brugeren får 4 min log registreringer returneret. Tre af registreringerne svarer til dem der er blevet registreret. Den sidste registrering svarer til den registrering der er lavet med at borgeren har set på egne data.
OPSLAG_PAA_EGNE_DATA_PAGINERING	Precondition: Der er registreret 3 min log registreringer på borger inden for de sidste 5 minutter. Der er registreret 1 min log registrering ældre end 5 minutter. Action 1: Borgeren laver opslag med paginering på første side. Action 2: Borgeren laver opslag med paginering på anden side. Postcondition: Efter action 2 får brugeren de første 3 registreringer. Efter action 3 får brugeren de næste to registreringer.
OPSLAG_PAA_BARN	Precondition: Der er registreret 3 min log registreringer på barn. Action 1: Borgeren laver opslag på barns data. Postcondition: Brugeren får 5 min log registreringer returneret. 3 registreringer 1 borger har lavet opslag på barns data.
OPSLAG_PAA_EGNE_HISTORISK	Precondition: Der er registreret 3 min log registreringer på borger inden for de sidste 5 minutter. Der er registreret 1 min log registrering ældre end 5 minutter. Action: Borgeren laver opslag på minlog2 begrænset til data ældre end 5 minutter.. Postcondition: Brugeren får 1 min log registrering returneret.
OPSLAG_PAA_BARN_PARENT_FILTER	Precondition: Der er registreret 2 min log registreringer på barn. Der er registreret 1 min log registrering på barn på der ikke skal vises for forældre (f.eks. p-piller) Action 1: Borgeren laver opslag på barns data. Postcondition: Brugeren får 2 min log registreringer returneret.
OPSLAG_VAERGE	Precondition: Der er registreret 2 min log registreringer på person A. Action 1: Værge laver opslag på min log data. Action 2: Person a laver opslag på min log data. Postcondition: Værge får returneret 3 registreringer. Person A får returneret 4 min log registreringer. 2 normale registreringer 1 registrering hvor værge har set data 1 registrering hvor personen selv har set data.

OPSLAG_VOKSEN_BARN	Precondition: Der er registreret 3 min log registreringer på barn over 15 år. Action 1: Borgeren laver opslag på barns data. Postcondition: Borgeren har ikke adgang til at se MinLog da barn er over 15 år.
OPSLAG_BARN_IKKE_FOAELDRE	Precondition: Der er registreret 3 min log registreringer på barn. Action 1: Borgeren laver opslag på barns data. Borgeren har ikke forældremyndighed over barnet. Postcondition: Borgeren har ikke adgang til at se MinLog da borger ikke har forældremyndighed.
OPSLAG_PRIVATMARKERET	Precondition: Der er registreret 2 min log registreringer på borger. Den ene af disse er privatmarkeret. De er begge mellem 30 og 40 minutter gamle. Action: Borgeren laver opslag på minlog2 på data der er mellem 30 og 40 minutter gamle. Postcondition: Brugeren får 2 min log registreringer returneret. Den privatmarkerede fremgår også.

Testcases medhjælp opslag

OPSLAG_PAA_VEGNE_AF

Precondition:

Medhjælp A har lavet en registrering på vegne af Læge B.

Action: Læge B laver opslag for at se hvilke registreringer Medhjælp A har lavet.

Postcondition:

Der returneres 1 MinLog registrering lavet af Medhjælp A.

OPSLAG_PAA_VEGNE_AF_PAGINERING

Precondition:

Medhjælp A har lavet 3 MinLog på vegne af Læge B inden for de sidste 5 minutter.
Medhjælp A har lavet 1 MinLog på vegne af Læge B ældre end 5 minutter.

Action 1: Læge B laver opslag med paginering på første side.
Action 2: Læge B laver opslag med paginering på anden side.

Postcondition:

Efter action 1 får brugeren de første 3 registreringer.
Efter action 2 får brugeren de næste to registreringer.

OPSLAG_ANVENDT_VAERDISPRING

Precondition:

Medhjælp A har lavet 3 MinLog på vegne af Læge B inden for de sidste 5 minutter.
Medhjælp A har lavet 1 MinLog på vegne af Læge B inden for 10 minutter siden minutter. Der er angivet at der er anvendt værdispring.
Medhjælp A har lavet 1 MinLog på vegne af Læge B ældre end 5 minutter.

Action 1: Læge B laver opslag på registreringer der er ældre end 5 minutter.

Postcondition:

Der returneres 2 logninger for Medhjælp A hvor der ikke er angivet at der er anvendt værdispring.
Der returneres 1 logning for Medhjælp A hvor der er angivet at der anvendes værdispring.

Testcases eCPR registreting

REGISTRERING_ECPR

Precondition:

Medhjælp A har lavet en registrering på vegne af Læge B. Registreringen er på et eCPR nummer

Action: Læge B laver opslag for at se hvilke registreringer Medhjælp A har lavet.

Postcondition:

Der returneres 1 MinLog registrering lavet af Medhjælp A.