1 Beskrivelse
2 Sikkerhet
- 2.1 Ved mottak av tokenet må blandt annet følgende valideres:
3 Ressurser
4 Eksempler

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 ¹	Integer	Nei
pagesize ¹	Integer	Nei

¹ 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 ²	String	Ja ²

² 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 ²	String	Ja ²

² 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 ²	String	Ja ²

² 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 ²	String	Ja ²

² 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