1. Indhold

2. Indledning

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

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

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


-

-



 




2.3. Dokumenthistorik

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



2.4. Definitioner og forkortelser

Definition

Beskrivelse

NSP

Den nationale service platform (inden for sundheds-IT)


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

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.

3.1. Adresse

Servicene er kan findes på:
https://<host>:<port>/minlog2-lookup/LookupService

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

https://<host>:<port>/minlog1-lookup/LookupService

og wsdl'en på:
https://<host>:<port>/minlog2-lookup/LookupService?wsdl

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

https://<host>:<port>/minlog1-lookup/LookupService?wsdl

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

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

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


MinLog1

Beskrivelser til MinLog1 - findes her https://svn.nspop.dk/public/components/minlog-ws/latest/doc/ 


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

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


3.2.2. 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/ PersonIdentifier

∩

∩

0-1

LogDataGroup/Destination/ PersonIdentifiersource attribut

∩

∩

1

LogDataGroup/Destination/ PersonName

∩

∩

0-1

LogDataGroup/Destination/ CorrelationId

∩

∩

0-1

LogDataGroup/Destination/ UserPersonIdentifier

∩

∩

0-1

LogDataGroup/Destination/ UserPersonIdentifier source attribut

∩

∩

1

LogDataGroup/Destination/ UserPersonName

∩

∩

0-1

LogDataGroupDestination/ UserRole

∩

∩

0-1

LogDataGroup/Destination/ OnBehalfOfPersonIdentifier

∩

∩

0-1

LogDataGroup/Destination/ OnBehalfOfPersonIdentifier source attribut

∩

∩

1

LogDataGroup/Destination/ OnBehalfOfPersonName

∩

∩

0-1

LogDataGroup/Destination/ OnBehalfOfUserRole

∩

∩

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 200

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

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

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/ UserPersonIdentifier

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

Streng af længde 50

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

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/ OnBehalfOfPersonIdentifier

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

Streng med max længde 50

0-1

LogDataGroup/ LogDataEntry/Destination/ OnBehalfOfPersonIdentifier attribut source

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

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

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

3.3. Operationer (MinLog2)

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

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

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


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

…….
…….


4. 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";

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

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


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


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

5. User stories

Testcases borgeropslag (IDWS snitfladen)
OPSLAG_PAA_EGNE_DATA_ALLE

Precondition:

  1. Der er registreret 3 min log registreringer på borger

Action: Borgeren laver opslag på minlog2 uden begrænsning på tid. 

Postcondition:

  1. Brugeren får 4 min log registreringer returneret. 
  2. Fire af registreringerne svarer til dem der er blevet registreret. 
  3. 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:

  1. Der er registreret 3 min log registreringer på borger inden for de sidste 5 minutter. 
  2. Der er registreret 1 min log registrering ældre end 5 minutter. 

Action: Borgeren laver opslag på minlog2 begrænset til seneste 5 minutter.  

Postcondition:

  1. Brugeren får 4 min log registreringer returneret. 
  2. Tre af registreringerne svarer til dem der er blevet registreret. 
  3. Den sidste registrering svarer til den registrering der er lavet med at borgeren har set på egne data. 
OPSLAG_PAA_EGNE_DATA_PAGINERING

Precondition:

  1. Der er registreret 3 min log registreringer på borger inden for de sidste 5 minutter. 
  2. 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:

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

Precondition:

  1. Der er registreret 3 min log registreringer på barn.

Action 1: Borgeren laver opslag på barns data.

Postcondition:

  1. Brugeren får 5 min log registreringer returneret.  
    1. 3 registreringer
    2. 1 borger har lavet opslag på barns data.
OPSLAG_PAA_EGNE_HISTORISK

Precondition:

  1. Der er registreret 3 min log registreringer på borger inden for de sidste 5 minutter. 
  2. 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:

  1. Brugeren får 1 min log registrering returneret.  
OPSLAG_PAA_BARN_PARENT_FILTER

Precondition:

  1. Der er registreret 2 min log registreringer på barn.
  2. 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:

  1. Brugeren får 2 min log registreringer returneret.  
OPSLAG_VAERGE

Precondition:

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

  1. Værge får returneret 3 registreringer. 
  2. Person A får returneret 4 min log registreringer. 
    1. 2 normale registreringer
    2. 1 registrering hvor værge har set data
    3. 1 registrering hvor personen selv har set data. 


OPSLAG_VOKSEN_BARN

Precondition:

  1. Der er registreret 3 min log registreringer på barn over 15 år.

Action 1: Borgeren laver opslag på barns data.

Postcondition:

  1. Borgeren har ikke adgang til at se MinLog da barn er over 15 år.
OPSLAG_BARN_IKKE_FOAELDRE

Precondition:

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

  1. Borgeren har ikke adgang til at se MinLog da borger ikke har forældremyndighed.
OPSLAG_PRIVATMARKERET

Precondition:

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

  1. Brugeren får 2 min log registreringer returneret. Den privatmarkerede fremgår også. 




Testcases medhjælp opslag
OPSLAG_PAA_VEGNE_AF

Precondition:

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

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

Precondition:

  1. Medhjælp A har lavet 3 MinLog på vegne af Læge B inden for de sidste 5 minutter. 
  2. 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:

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

Precondition:

  1. Medhjælp A har lavet 3 MinLog på vegne af Læge B inden for de sidste 5 minutter. 
  2. 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.
  3. 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:

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

Precondition:

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

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




  • No labels