Tilgangslogg - Implementasjonsguide

Beskrivelse

Denne dokumentasjonen inneholder implementasjonsguide for innsyn i tilgangslogg for Pasientjournal. Beskrivelsene i dette dokumentet baserer seg på Direktoratet for e-helses anbefalinger for REST-tjenester per juni 2018 og API dokumentasjon v2.2.3.0/1.8.3.0 for DIPS Service Broker Health Record Access Log. Dokumentasjonen tar høyde for at det er opprettet et endepunkt som igjen gjør spørringer mot en eller flere Dips-installasjoner.

Sikkerhet

Tjenestene sikres med TLS 1.2 og et JWT token. Det er også mulig å legge til rette for 2-veis TLS. Ettersom det er transportkryptering mellom klient og tjeneste bør det gjøres en sikkerhetsvurdering på endepunkter hvor spørringer og responser skal brukes til og fra en intern tjeneste. Alle spørringer som går fra klienten skal inkludere et JWT-token. Tokenet er "self-contained" og inneholder informasjon om innlogget- og evnt. representert innbygger samt en signatur som bekrefter om tokenet er gyldig.

Ved mottak av tokenet må blandt annet følgende valideres:

  • Token-signatur

  • Scope (scp)

    • Forventet verdi er “innsynpasientjournal“

  • Audience (aud)

    • Forventet verdi avhenger av mottaker. For eksempel kan Helse Vest validere at verdien “hv” er i listen

  • nationalId i request-parameter er lik subject (sub) verdien i tokenet.

Se også dokumentasjon for JWT for ytterligere informasjon om validering med mer: Innlogget Innbygger

Ressurser

Felles for alle Ressurser

HTTP Request Headers

Request headere vil være de samme for alle ressurser

Navn

Verdi

Navn

Verdi

Accept

application/xml

Content-Type

application/json

HTTP Response Status codes

Statuskoder som gjelder for alle HTTP responser. Disse statuskodene er de eneste som er forventet men Helsenorge har støtte for mottak av alle standard HTTP statuskoder.

Navn

Kode

Beskrivelse

OK

200

Spørringen ble forstått og gjennomført.

Internal Server Error

500

En feil oppstod ved behandling av spørringen

Unauthorized

401

Tokenvalidering feilet

Respons formatering

Helsenorge sender application/xml i accept-headeren og forventer derfor XML i responsen. DIPS returnerer i utgangspunktet JSON i sine responser, men av historiske årsaker har vi videreført XML. DIPS har støtte for å returnere XML også, men da må accept-headeren mot DIPS også være application/xml. Formateringen av XMLen Helsenorge forventer er den samme som DIPS returnerer ved kall til sine tjenester.

HealthRecordAccessLog

HTTP Request

Spørringen er et POST-kall med parametere i bodyen i JSON-format. Dette gjør at Content-Type i headeren alltid er satt til application/json. I responsen vil alltid være XML, derfor vil Accept i headeren ha verdien application/xml.

Parametere

Navn

Type

Påkrevd

nationalId

String

Ja

from

Dato

Nei

to

Dato

Nei

pageno 1

Integer

Nei

pagesize 1

Integer

Nei


1 Ved spørringer mot et endepunkt som har flere datakilder vil parameterne pageno og pagesize kunne gi inkonsekvente data i brukergrensesnittet. Hvis datakilde 1 har data fra 2012 og datakilde 2 har data fra 2018 på side 1 så vil sorteringen på dato bli helt feil om det samme er tilfellet når side 2 hentes. Disse vil dermed alltid ha en fast verdi på henholdsvis 1 og 10000.

HTTP Respons

Responsen er XML og er basert på Dips' egen respons, men med noen mulige tilpasninger for å kunne tilfredsstille de behovene som kommer om det er flere interne kilder på endepunktet HealthRecordAccessLog-spørringen går mot. Disse endringene skal ikke være nødvendig om det er en intern datakilde.

Tilpasninger ved feilsituasjoner og flere interne datakilder

Det er gjort en enkel utvidelse av responsen til HealthRecordAccessLog for å kunne tilrettelegge for at RHFet skal kunne gi Helsenorge en feilkode ved spesifikke feilsituasjoner. Om RHFet ikke har tilrettelagt for innsyn på vegne av barn 12-16 år kan RHFet returnere en respons med HTTP Status Code 200 (OK) og feilkoden RepresentationBelowMinimumAgeError. På denne måten kan Helsenorge informere innbyggerne om hvorfor de ikke kan se innsyn gjort mot et spesifikt RHF.

For å legge til denne utvidelsen må det legges til et XML-namespace i HealthRecordAccessLog og en ErrorList-node under denne. ErrorList-noden kan inneholde en eller flere Error-noder med properties codeContext, errorCode og location.

Properties i Error-noden

Property

Verdi

Beskrivelse

Property

Verdi

Beskrivelse

codeContext

Det er ikke tilrettelagt for innsyn for barn 12-16

Tekstlig beskrivelse av feilårsaken

errorCode

RepresentationBelowMinimumAgeError

Feilkode - Se eksempler under

location

2.16.578.1.12.4.3.1.4.20.1

OID som representerer RHFet, HFet/DIPS-installasjonen feilen stammer fra

Eksempel på utvildelse

<HealthRecordAccessLog xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://DIPS.no/ServiceBroker/HealthRecordAccessLog" xmlns:hralext="urn:no:ehelse:tilgangslogg:ext"> <TotalItemCount>0</TotalItemCount> <hralext:ErrorList> <hralext:Error codeContext="An error occurred while sending the request." errorCode="UnavailableCommunity" location="2.16.578.1.12.4.3.1.4.20.1"/> </hralext:ErrorList> <LogItems/> </HealthRecordAccessLog>

Feilkoder

Følgende feilkoder kan returneres av endepunktene for å kunne gi en forbedret feilmelding til innbyggeren. Se eksempelrespons for HealthRecordAccessLog for hvordan feilkodene kan brukes i en respons.

ErrorCode

Location

Beskrivelse

UnavailableCommunity

OID som representerer HR

Brukes i de tilfeller hvor RHFet har flere enn ett endepunkt, slik at det er mulig å identifisere hvilket HF som ikke returnerer data

RepresentationBelowMinimumAgeError

OID som representerer RHF

Brukes i de tilfeller hvor RHF ikke tillater innsyn ved representasjon av en barns aldergsgruppe

RateLimitExceeded

OID som representerer RHF eller HF

Brukes i de tilfeller hvor RHF eller HF må stoppe trafikk på grunn av stor pågang.

DocumentAccessLog

HTTP Request

Spørringen er et POST-kall med parametere i bodyen i JSON-format. Dette gjør at Content-Type i headeren alltid er satt til application/json. Responsen er XML-formatert og Accept i headeren vil verdien application/xml.

Parametere

Navn

Type

Påkrevd

nationalId

String

Ja

staffid

String

Ja

staffIdType

string

Ja

from

Dato

Nei

to

Dato

Nei

pageno

Integer

Nei

pagesize

Integer

Nei

simplify

Boolean

Nei

showFirstAccessTime

Boolean

Nei

repositoryId 2

String

Ja 2


2 repositoryId er kun påkrevd og en nødvendig tilpasning når endepunktet inneholder flere interne DIPS-instanser

Tilpasninger ved flere interne datakilder

Det er lagt til en repositoryId-parameter på spørringen. Verdien for denne parameteren kommer fra RepositoryUniqueId i ListItem fra HealthRecordAccessLog-responsen og er kun påkrevd om endepunktet har flere interne datakilder/DIPS-installasjoner og har behov for å kunne identifisere hvilken datakilde DocumentAccessLog-spørringen skal gå mot. Om endepunktet kun har en datakilde har feltet verdien null eller så er ikke feltet med i spørringen.

HTTP Respons

Det har ikke vært nødvendig med tilpasninger på tjenestens respons og er dermed i henhold til Dips' egne spesifikasjoner. Om det er flere interne datakilder som skal svare på denne spørringen er det mulig å utvide responsen med en liste med feil. Se “Tilpasninger ved feilsituasjoner og flere interne datakilder“ under HealthRecordAccessLog.

DocumentAccessLog/accessReasonId

HTTP Request

Spørringen er et POST-kall med parametere i bodyen i JSON-format. Dette gjør at Content-Type i headeren alltid er satt til application/json. Responsen er XML-formatert og Accept i headeren vil verdien application/xml.

Parametere

Navn

Type

Påkrevd

nationalId

String

Ja

accessReasonId

Guid

Ja

hfInternalId

integer

Ja

from

Dato

Nei

to

Dato

Nei

pageno

Integer

Nei

pagesize

Integer

Nei

simplify

Boolean

Nei

showFirstAccessTime

Boolean

Nei

repositoryId 2

String

Ja 2


2 repositoryId er kun påkrevd og en nødvendig tilpasning når endepunktet inneholder flere interne DIPS-instanser

Tilpasninger ved flere interne datakilder

Det er lagt til en repositoryId-parameter på spørringen. Verdien for denne parameteren kommer fra RepositoryUniqueId i ListItem fra HealthRecordAccessLog-responsen og er kun påkrevd om endepunktet har flere interne datakilder/DIPS-installasjoner og har behov for å kunne identifisere hvilken datakilde DocumentAccessLog-spørringen skal gå mot. Om endepunktet kun har en datakilde har feltet verdien null eller så er ikke feltet med i spørringen.

HTTP Respons

Det har ikke vært nødvendig med tilpasninger på tjenestens respons og er dermed i henhold til Dips' egne spesifikasjoner. Om det er flere interne datakilder som skal svare på denne spørringen er det mulig å utvide responsen med en liste med feil. Se “Tilpasninger ved feilsituasjoner og flere interne datakilder“ under HealthRecordAccessLog.

DocumentAccessLog/SubjectIdentifier

HTTP Request

Spørringen er et POST-kall med parametere i bodyen i JSON-format. Dette gjør at Content-Type i headeren alltid er satt til application/json. Responsen er XML-formatert og Accept i headeren vil verdien application/xml.

Parametere

Navn

Type

Påkrevd

nationalId

String

Ja

subjectIdentifierId

String

Ja

subjectIdentifierSystem

String

Ja

subjectIdentifierAssigner

String

Ja

from

Dato

Nei

to

Dato

Nei

pageno

Integer

Nei

pagesize

Integer

Nei

simplify

Boolean

Nei

showFirstAccessTime

Boolean

Nei

repositoryId 2

String

Ja 2


2 repositoryId er kun påkrevd og en nødvendig tilpasning når endepunktet inneholder flere interne DIPS-instanser

Tilpasninger ved flere interne datakilder

Det er lagt til en repositoryId-parameter på spørringen. Verdien for denne parameteren kommer fra RepositoryUniqueId i ListItem fra HealthRecordAccessLog-responsen og er kun påkrevd om endepunktet har flere interne datakilder/DIPS-installasjoner og har behov for å kunne identifisere hvilken datakilde DocumentAccessLog-spørringen skal gå mot. Om endepunktet kun har en datakilde har feltet verdien null eller så er ikke feltet med i spørringen.

HTTP Respons

Det har ikke vært nødvendig med tilpasninger på tjenestens respons og er dermed i henhold til Dips' egne spesifikasjoner. Om det er flere interne datakilder som skal svare på denne spørringen er det mulig å utvide responsen med en liste med feil. Se “Tilpasninger ved feilsituasjoner og flere interne datakilder“ under HealthRecordAccessLog.

DocumentAccessLog/SubjectQualificationIdentifier

HTTP Request

Spørringen er et POST-kall med parametere i bodyen i JSON-format. Dette gjør at Content-Type i headeren alltid er satt til application/json. Responsen er XML-formatert og Accept i headeren vil verdien application/xml.

Parametere

Navn

Type

Påkrevd

Navn

Type

Påkrevd

nationalId

String

Ja

subctQualifIdentifierId

String

Ja

subctQualifIdentifierIdSystem

String

Ja

subctQualifIdentifierIdAssigner

String

Ja

from

Dato

Nei

to

Dato

Nei

pageno

Integer

Nei

pagesize

Integer

Nei

simplify

Boolean

Nei

showFirstAccessTime

Boolean

Nei

repositoryId 2

String

Ja 2


2 repositoryId er kun påkrevd og en nødvendig tilpasning når endepunktet inneholder flere interne DIPS-instanser

Simplify-parameter

Fra DIPS Service Broker Health Record Access Log dokumentasjon v4.0

By default, each operation a "healthcareparty" does on a document becomes one row in the documentaccesslog. "Simplify" merges all rows with same "healthcareparty" and document to one row. Following rules applies to values that are merged.

Value

Merge rule

AccessType

Allways set to value 2, enum value "Innsyn"

TimeOfAccess

Last time accessing the document

Notes

Last notes recorded with value

Tilpasninger ved flere interne datakilder

Det er lagt til en repositoryId-parameter på spørringen. Verdien for denne parameteren kommer fra RepositoryUniqueId i ListItem fra HealthRecordAccessLog-responsen og er kun påkrevd om endepunktet har flere interne datakilder/DIPS-installasjoner og har behov for å kunne identifisere hvilken datakilde DocumentAccessLog-spørringen skal gå mot. Om endepunktet kun har en datakilde har feltet verdien null eller så er ikke feltet med i spørringen.

HTTP Respons

Det har ikke vært nødvendig med tilpasninger på tjenestens respons og er dermed i henhold til Dips' egne spesifikasjoner. Om det er flere interne datakilder som skal svare på denne spørringen er det mulig å utvide responsen med en liste med feil. Se “Tilpasninger ved feilsituasjoner og flere interne datakilder“ under HealthRecordAccessLog.

Eksempler

HealthRecordAccessLog

Spørring

{ "nationalId": "12345678900", "from": "2018-05-22T00:00:01", "to": "2018-05-22T23:59:59", "pageno": null, "pagesize": null }

Respons

<HealthRecordAccessLog xmlns:i="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://DIPS.no/ServiceBroker/HealthRecordAccessLog" xmlns:hralext="urn:no:ehelse:tilgangslogg:ext"> <TotalItemCount>2</TotalItemCount> <hralext:ErrorList> <hralext:Error codeContext="An error occurred while sending the request." errorCode="UnavailableCommunity" location="2.16.578.1.12.4.3.1.4.20.1"/> </hralext:ErrorList> <LogItems> <LogItem> <AccessReason> <Comment i:nil="true"/> <Type>DecisionBased</Type> <Value>Åpen konsultasjonsserie</Value> </AccessReason> <AccessingPerson> <Department> <Name>Sykehuspartner</Name> <ReshId i:nil="true"/> <ShortName>SP</ShortName> </Department> <FirstName>Elsa Louise</FirstName> <Identifier> <Type>InternalId</Type> <Value>60969496</Value> </Identifier> <LastName>Popov</LastName> <Position>IT DIPS Forvalter</Position> </AccessingPerson> <EndTime>2018-05-22T21:49:13</EndTime> <HFInternalId>1</HFInternalId> <HFname>Oslo universitetssykehus HF</HFname> <OrganisationNumber>993467049</OrganisationNumber> <Organization>Oslo universitetssykehus HF</Organization> <RegionalLogAccessItem> </RegionalLogAccessItem> <RepositoryUniqueId>2.16.578.1.12.4.3.1.1.20.22</RepositoryUniqueId> <StartTime>2018-05-22T15:49:13</StartTime> <hralext:RepositoryId>2.16.578.1.12.4.3.1.1.20.2</hralext:RepositoryId> </LogItem> <LogItem> <AccessReason> <Comment i:nil="true"/> <Type>None</Type> <Value>Clinical care provision to an individual subject of care</Value> </AccessReason> <AccessingPerson> <Department> <Name i:nil="true"/> <ReshId i:nil="true"/> <ShortName i:nil="true"/> </Department> <FirstName>LISBETH PSA</FirstName> <Identifier> <Type>InternalId</Type> <Value/> </Identifier> <LastName>HEGGEDAL</LastName> <Position>Sykepleier</Position> </AccessingPerson> <EndTime>2021-03-11T13:27:19</EndTime> <HFInternalId>1</HFInternalId> <HFname>Oslo universitetssykehus HF</HFname> <OrganisationNumber>993467049</OrganisationNumber> <Organization>Andeby sykehus</Organization> <RegionalLogAccessItem> <AccessReasonId>a15e9229-8d5b-4044-b25c-52ca8249edae</AccessReasonId> <Accesstype>h</Accesstype> <Purposeassigner>ISO 14265 Classification of Purposes for processing personal health information</Purposeassigner> <Purposedescription>Clinical care provision to an individual subject of care</Purposedescription> <Purposeid>1</Purposeid> <Purposesystem>1.0.14265.1</Purposesystem> <Subjectassigner>Skatteetaten</Subjectassigner> <Subjectchildorgassigner i:nil="true"/> <Subjectchildorgid i:nil="true"/> <Subjectchildorgname i:nil="true"/> <Subjectchildorgsystem i:nil="true"/> <Subjectid>10086400478</Subjectid> <Subjectname>LISBETH PSA HEGGEDAL</Subjectname> <Subjectorgassigner>Brønnøysundregistrene</Subjectorgassigner> <Subjectorgid>999977774</Subjectorgid> <Subjectorgname>Andeby sykehus</Subjectorgname> <Subjectorgsystem>2.16.578.1.12.4.1.4.101</Subjectorgsystem> <Subjectqualificationassigner>Helsedirektoratet</Subjectqualificationassigner> <Subjectqualificationid>222200052</Subjectqualificationid> <Subjectqualificationname i:nil="true"/> <Subjectqualificationsystem>2.16.578.1.12.4.1.4.4</Subjectqualificationsystem> <Subjectroleassigner>ISO</Subjectroleassigner> <Subjectroleid>SP</Subjectroleid> <Subjectrolename>Sykepleier</Subjectrolename> <Subjectrolesystem>2.16.578.1.12.4.1.1.9060</Subjectrolesystem> <Subjectsystem>2.16.578.1.12.4.1.4.1</Subjectsystem> </RegionalLogAccessItem> <RepositoryUniqueId>2.16.578.1.12.4.3.1.1.20.22</RepositoryUniqueId> <StartTime>2020-03-11T13:27:19</StartTime> </LogItem> </LogItems> </HealthRecordAccessLog>


Felter under namespace urn:no:ehelse:tilgangslogg:ext er kun nødvendig om det er flere interne DIPS-instanser som skal returnere data

DocumentAccessLog

Spørring

repositoryId verdi er kun nødvendig om det er flere interne DIPS-instanser som har returnert data

Respons

DocumentAccessLog/accessReasonId

Spørring


repositoryId er kun nødvendig om det er flere interne DIPS-instanser

Respons

Se respons for DocumentAccessLog

DocumentAccessLog/SubjectIdentifier

Spørring

repositoryId er kun nødvendig om det er flere interne DIPS-instanser som har returnert data.

Respons

Se respons for DocumentAccessLog

DocumentAccessLog/SubjectQualificationIdentifier

Spørring


repositoryId er kun nødvendig om det er flere interne DIPS-instanser som har returnert data.

Respons

Se respons for DocumentAccessLog