INDHOLD

Beskrivelse

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.

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. 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. logges 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: KIT
NSP: MinLog2 - Leverancebeskrivelse

Forretningsanvendelse

^^Tilbage til toppen^^



Relaterede registre og services

Applikationsbeskrivelse

^^Tilbage til toppen^^

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, hvor den ene er til borgerloggen og den anden til 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

WSDL:
- Registration: https://wsdl.nspop.dk/minlog2-registration/RegisterService?wsdl
- Lookup (DGWS): https://wsdl.nspop.dk/minlog2-lookup/LookupService?wsdl
- Lookup (IDWS): https://wsdl.nspop.dk/minlog2-lookupid/LookupidService?wsdl

Minlog2 registration service
------------------------------
Denne service anvendes til registrering af log hændelser.
Der er kun een tilgængelige operation. Denne operation anvendes også til at sende flere logentries i samme request:
++ AddRegistrations - Denne operation anvendes når der skal foretages en log registrering. Headerdelen håndterer IDCard og Medcom - se evt. nsop.dk

Minlog2 registration servicen 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 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).
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.

Datastruktur, Sundhedsdataregister: Minlog2

^^Tilbage til toppen^^

Register properties:

Minlog2 registrerings servicen håndterer logning af tilgang eller forsøg på tilgang af borgers data.

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

Log-data anvendes i forskellige sammenhænge:
• Borgerrettet i ”MinLog”, til 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.
• Og i medhjælpsloggen til at autoriserede sundhedspersoner kan se hvad deres evt. medhjælpere slår op på deres vegne.

Entitetsbeskrivelser

LogEntry

^^Tilbage til toppen^^

Logentry for hændelsen med angivelse af borger, bruger og evt. ansvarlig, organisation og system samt anvender session og tidspunkt.
For at forhindre at der kan forekomme dublikater ved insert, laves der en SHA256 hash over en række værdier, af databasen.

Objektet indeholder følgende information:
---------------------------------------------
EntryId -- unique id
PersonIdentifier -- CPR-nummer eller evt. erstatnings-CPR-nummer på borgeren.
PersonIdentifierType -- Kilde til ID for borgerens CPR-nummer eller erstatnings-CPR-nummer. F.eks. "CPR" for almindelige CPR-numre i CPR-registret. (CPR, E-CPR, ... og en Streng med max længde 200)
PersonName -- Borgerens navn. Optionelt men krævet af anvendersystemet hvor source ikke er CPR.

OnBehalfOfPersonIdentifier -- CPR-nummer eller evt. erstatnings-CPR-nummer på brugeren handlingen er udført på vegne af.
OnBehalfOfPersonIdentifierType -- Kilde til OnBehalfOfPersonIdentifier. F.eks. "CPR" for almindelige CPR-numre i CPR-registret. (CPR, Initialer, Autorisation eller en Streng med max længde 200)
OnBehalfOfPersonName -- Navn svarende til "på vegne af". Optionelt men krævet af anvendersystemet hvor source ikke er CPR, Autorisation m.v.
OnBehalfOfUserRole -- På vegne af brugerens rolle.

FilterBorger -- true = filtreres fra for borgeren
FilterParents -- true = filtreres fra for forældre

UserPersonIdentifier -- CPR-nummer eller evt. erstatnings-CPR-nummer på brugeren der har udført handlingen. En forekomst af CPR-nummer eller erstatnings-CPR-nummer er som udgangspunkt obligatorisk og valideres af registreringsservicen.
UserPersonIdentifierType -- Kilde til UserPersonIndentifier. F.eks. "CPR" for almindelige CPR-numre i CPR-registret. (CPR, Initialer, Autorisation eller en Streng med max længde 200)
UserPersonName -- Brugerens navn. Optionelt men krævet af anvendersystemet hvor source ikke er CPR, Autorisation m.v.

OrganisationId -- ID for brugerens organisation. Elementet skal forekomme for alt andet end private borgeres opslag.
OrganisationName -- Navn på brugens organisation , Elementet skal forekomme for alt andet end private borgeres opslag.
OrganisationType -- 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)

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

Source

^^Tilbage til toppen^^

Indeholder organisations navnet som brugeren tilhører

Objektet indeholder følgende information:
---------------------------------------------
SourceId -- unique id
EntryId -- foreign key til Logentry (EntryId)
SystemName -- Navn, evt. forkortet, for det anvendte kilde-system
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). Systemet skal være unikt for det anvendte system.
Level -- kald rækkefølg. Dette anvendes såfremt kildesystemet igen er kaldt af et andet system

Tabelbeskrivelser

Tabel: logentry

^^Tilbage til toppen^^

USE minlog2;

CREATE TABLE logentry
(
EntryId BIGINT NOT NULL AUTO_INCREMENT,
PersonIdentifier VARCHAR(50) NOT NULL,
PersonIdentifierType VARCHAR(50) NOT NULL DEFAULT 'CPR',
PersonName VARCHAR(50),

OnBehalfOfPersonIdentifier VARCHAR(50),
OnBehalfOfPersonIdentifierType VARCHAR(50),
OnBehalfOfPersonName VARCHAR(50),
OnBehalfOfUserRole VARCHAR(200),

FilterBorger BOOLEAN DEFAULT FALSE,
FilterParents BOOLEAN DEFAULT FALSE,

UserPersonIdentifier VARCHAR(50) NOT NULL,
UserPersonIdentifierType VARCHAR(50) NOT NULL DEFAULT 'CPR',
UserPersonName VARCHAR(50),

OrganisationId VARCHAR(200),
OrganisationName VARCHAR(200),
OrganisationType VARCHAR(200),

CorrelationId VARCHAR(46),
SequenceNumber VARCHAR(36),
SystemName VARCHAR(25) NOT NULL,
Activity VARCHAR(75) NOT NULL,
Addition VARCHAR(50),
Criticality VARCHAR(50) NOT NULL DEFAULT 'Normal',
UserRole VARCHAR(200),
Reason VARCHAR(50),

-- yyyy-mm-dd hh:mm:ss.fffffffff
EventDateTime DATETIME NOT NULL
COMMENT 'Start tid',
EventEndDateTime DATETIME NOT NULL
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,

PRIMARY KEY (EntryId)
) CHARACTER SET 'utf8'
COLLATE 'utf8_danish_ci';


CREATE INDEX logentrypi_idx
ON logentry (PersonIdentifier);

CREATE INDEX logentryuserpi_idx
ON logentry (OnBehalfOfPersonIdentifier);

CREATE INDEX logentrydt_idx
ON logentry (EventDateTime);

Tabel: source

^^Tilbage til toppen^^


CREATE TABLE source
(
SourceId BIGINT NOT NULL AUTO_INCREMENT,
EntryId BIGINT NOT NULL,
SystemName VARCHAR(25) NOT NULL,
CorrelationId VARCHAR(46),
Level INT,
PRIMARY KEY (SourceId),
FOREIGN KEY (EntryId) REFERENCES logentry (EntryId) ON DELETE CASCADE
) CHARACTER SET 'utf8'
COLLATE 'utf8_danish_ci';

Teknologibeskrivelse

^^Tilbage til toppen^^

Refereres fra

^^Tilbage til toppen^^





  • No labels