Versions Compared

Key

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

...

Table of Contents

Beskrivelse

Multiexcerpt
MultiExcerptNameFormål

MinLog2 har til formål at registrere, opbevare og udstille registreringer af sundhedspersoners adgang til personfølsomme data. MinLog2 udstilles til borgere for at kunne give dem et indblik i, hvornår deres sundhedsdata tilgås af personale fra sundhedssektoren. Ligeledes er det muligt for en læge,

...

tandlæge m.v, der får hjælp af en medhjælper, at se hvilke handlinger, medhjælpen har udført som lægens

...

delegerede.

Multiexcerpt
MultiExcerptNameBeskriv databehandlingen

En autoriseret sundhedsperson er f.eks. en læge, sygeplejerske, tandlæge m.v. Autoriserede sundhedspersoner har i visse situationer adgang til at anvende medhjælpere, men har også en forpligtigelse til at sikre at medhjælpere kun udfører handlinger i overensstemmelse med de anvisninger medhjælpen har fået. En autoriseret sundhedsperson skal have følgende muligheder for opslag:
- Opslag i medhjælpsloggen, hvor en autoriseret sundhedsperson kan se, hvad hver enkelt medhjælp har udført af handlinger på vegne af den autoriserede sundhedsperson.

Borgeren (eller patienten) optræder i MinLog 2-sammenhæng hovedsageligt som personen, hvis data der slås op på.
• Borgeren skal have mulighed for at slå op i MinLog for at se, hvilke aktører der har set, oprettet eller opdateret borgerens sundhedsdata.
• Borgeren kan desuden optræde som forældremyndighedsindehaver, værge eller fuldmagtshaver, og skal

...

, ud over at kunne slå op i MinLog for at se sundhedspersoners m.v. opslag på personen han/hun er værge for, også have mulighed for at slå op på hvilke opslag borgeren evt. selv har foretaget som forældremyndighedsindehaver, værge eller fuldmagtshaver.

Forældremyndighedsindehaver er en borger, og kan slå op på MinLog for en anden borger (barn), såfremt der findes stamdata i CPR-registret, der viser en forældremyndighedsrelation.
Stamdata i CPR-registret indeholder forældremyndighedsrelationer for børn født maj 2004 og senere. Børn født tidligere findes der kun undtagelsesvist en registreret en forældremyndighedsrelation for i CPR-registret. De gældende regler for aldersgrænser for hvornår forældremyndighedsindehaver må se deres barns sundhedsdata, er fra barnets fødsel, hvor barnets CPR-nummer også oprettes, til barnet fylder 15 år. Fra den unge er mellem 15 år og 18 år, er det muligt at få udstede et særligt ”ung under 18”-NemID som kan benyttes til login. Forældremyndighedsindehaver kan ikke se den unges sundhedsdata efter de er fyldt 15 år.
Forældremyndighedsindehavere (samt værger) må ikke se deres børns præventionsmidler, informationer relateret til aborter, evt. blodtransfusioner m.v, heller ikke selv om barnet er under 15 år. Logdata der omhandler præventionsmidler m.v. skal filtreres fra i data returneret når forældremyndighedsindehaver slår op på Min Log 2. Hertil anvendes en filter flag markeringlogges derfor med et flag, som angiver at logning ikke skal vises til forældremyndighedsindehaver. Når der slås op som forældremyndighedsindehaver filtrerer MinLog så disse logninger fra ved anvendelse af nævnte flag.

En borger kan være værge for personer, der har fået frataget retlig handleevne. Der findes andre typer af værgemål, I MinLog 2-sammenhæng er det udelukkende værger for personer der har fået frataget retlig handleevne der er relevant. I dette dokument vil det alle steder være denne type værge der menes, når værge omtales. I MinLog 2 kan værger for personer, der har fået frataget retlig handleevne slå op i MinLog 2 for denne personen som denne er værge for. Oplysninger om relationen findes i CPR-registret, som er tilgængeligt via stamdata på NSP. Der gælder samme forhold omkring børns præventionsmidler m.v. for værge som beskrevet under Forældremyndighedsindehaver

Minlog registrerings servicen er tilgængelig på alle NSP’er (cNSP+dNSP) samt på backend og kaldes fra NSP services samt externt fra Lægepraksis systemer.
Minlog lookup servicen er tilgængelig på alle NSP'er (cNSP +dNSP, via DCC).

Support ansvarlig: ArosiiKIT
NSP: MinLog2 - Leverancebeskrivelse

Forretningsanvendelse

^^Tilbage til toppen^^Image Removed


Multiexcerpt
MultiExcerptNameArkitekturtegning

Image Added


Relaterede registre og services

Multiexcerpt
MultiExcerptNameUnderstøttede komponenter

Applikationsbeskrivelse

^^Tilbage til toppen^^

Image RemovedImage Added

Hverken registrerings- eller udtræk servicen benytter whitelist.

Der findes en service til registrering af log hændelser samt to services til opslag på log hændelser. Forskellen ligger kun den anvendte sikkerhedsmodel. Den ene service anvender DGWS principperne , hvor den ene er til borgerloggen og den anden service OIOIDWStil medhjælpsloggen.

Adresser
- Registration Servicen (DGWS) kan findes på: https://<host>:<port>/minlog2-registration/RegisterService
- Lookup Servicen (DGWS) kan findes på: https://<host>:<port>/minlog2-lookup/LookupService
- Lookup Servicen (IDWS) kan findes på: https://<host>:<port>/minlog2-lookupid/LookupidService

...

Minlog2 registration servicen melder sig agerer mod KAFKA som "producer" fra cNSP/dNSP via MinLog2 producer og som "consumer" på backend, hvorved alle registreringer persisteres i databasen på backend.

Minlog2 lookup service
-----producer
--------------------
Dette er et java bibliotek der indeholder nødvendig logik for at kunne tage imod en MinLog2 registrering og levere denne til Kafka.

Biblioteket udstiller een metode til anvendere. Denne anvendes til at registere en eller flere MinLog2 registreringer.
++ AddRegistrations - Denne metode anvendes når der skal foretages en log registrering. Dette Java API er tilgængelig for de services der findes på NSP'en. Bemærk: Kan KUN anvendes af servides på NSP'en.

Minlog2 producer servicen melder sig mod KAFKA som "producer".

Minlog2 lookup service
-------------------------
Der findes 2 services til opslag på log hændelser, hvor den ene er til borgerloggen og den anden til medhjælpsloggen. Derudover er der også forskellige sikkerhedsmodeller (DGWS/OIOIDWS)Der findes 2 services til opslag på log hændelser. Forskellen ligger kun den anvendte sikkerhedsmodel. Den ene service anvender DGWS principperne og den anden service OIOIDWS.
Opslagsservicen skal understøtte at den direkte bruges af et klient-system til at vise logninger. Der udstilles en samlet opslagsservice, der afhængigt af hvilke parametre den kaldes med kan returnere:
• Borgerrettet log-data, dvs. til ”MinLog”, således at borgeren kan se hvilke opslag der er foretaget på borgerens sundhedsdata, evt. også såfremt borgeren optræder som forældremyndighedsindehaver, fuldmagtshaver eller værge.
• Log-data til medhjælpsloggen, til at autoriserede sundhedspersoner kan se hvad deres evt. medhjælpere slår op på deres vegne.
Berigelse med stamdata:
Ved opslag suppleres der med stamdata for person og organisation ud fra id’er, såfremt dette er muligt. I registreringsservicen er der ingen validering ud over en eventuel validering af formater, så det er ikke givet at en berigelse med stamdata er mulig. Der beriges med organisationsdata og persondata.
Berigelse med organisationsdata. Ud fra OrganisationId forsøges der at slå organisationsdata op i det register der svarer til hvad der er angivet i source-attributten:
- yderregisteret hvis source er ”yder”
- SKS (institution/organisation) eller SOR (Apotek) hvis "SKS"
- SOR (Apotek) hvis EAN-lokationsummer
Berigelse med persondata. Udfra PersonIdentifier slås persondata udfra source-attributen:
- CPR (person) hvis "CPR"
- Autorisationsregistret hvis "Autorisation"
Tilgængelige operationer:
++ GetLogStatementsForCPRPerson - Denne operation anvendes når der skal foretages et person opslag efter log registreringer
++ 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.

...

Minlog2 registrerings servicen håndterer logning af tilgang eller forsøg på tilgang af borgers data.
Udstilles på sundhed.dk gennem minlog2 web servicen.

Log events består af to dele. En source og en destination. Destination indeholder alt information om logningen (Logentry), mens source er kaldekæden gennem systemerne

...

CorrelationId -- Et teknisk id, medsendt fra kildessytemetet. 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.
SequenceNumber -- Et teknisk sekvens-nummer, angivet af afsender, der anvendes i forbindelse med fejlhåndtering. F.eks. et fortløbende nummer eller et uuid. Værdien skal være unikt i kaldet.
SystemName VARCHAR(25) NOT NULL,-- Navn på det kaldende system (i source) eller det kaldte system (i destination).
Activity -- Tekst der beskriver den handling, som brugeren har udført eller forsøgt udført på kildesystemet. Eksempelvis "hent medicinkort" på FMK. Datasættet fastlægges endeligt i forbindelse med udarbejdelse af vejledninger og retningslinjer.
Addition -- Angivelse af type af opslag som tilføjelse til kritikalitet, aktuelt "Samtykke" eller "Værdispring"
Criticality -- Niveau for kritikalitet, aktuelt kun "Privatmarkeret", defineret som en union af en enumeration af niveau for kritikalitet, og en Streng med max længde 50 tegn DEFAULT 'Normal'
UserRole -- Brugerens rolle. Der vil være en sammenhæng til et evt. angivet autorisationsnummer, det er op til systemet der kalder registreringsservicen at sikre sammenhængen er korrekt.
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.

-- yyyy-mm-dd hh:mm:ss.fffffffff
EventDateTime --DateTime-elementet indeholder en tidsangivelse for opslag på eller forsøg på handling på borgerens data. 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. COMMENT 'Start tid',
EventEndDateTime --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 der angives det interval hvor hændelserne er sket. COMMENT 'Slut tid - Skal være samme som start tid hvis der ikke er forskel',.

RowHash VARCHAR(224) AS (SHA2(
concat_ws(' ', PersonIdentifier, OnBehalfOfPersonIdentifier, UserPersonIdentifier, OrganisationId, SystemName, Activity, EventDateTime, EventEndDateTime, CorrelationId), 224)) PERSISTENT UNIQUE,

...