Versions Compared

Old Version 9

changes.mady.by.user Cato Gjørven

Saved on

compared with

New Version 10

changes.mady.by.user Vidar Methi

Saved on

Key

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

...

Workflow using HelseID and API's from kjernejournal

Main functional steps

  1. The client requests and receives a system token from HelseID, which includes the organization number.

  2. The client then sends the signed system token and a patient nin to kjernejournal, which authorizes the organization and creates a ticket that represents both the organization number and the patient.

  3. The client then requests and receives a user token from HelseID. Typically they are authenticated using Buypass or Commfides.

  4. The client then sends both the ticket from kjernejournal, as well as the signed user token to the actual API, which then authorizes the user and responds

  5. The client receives the data from kjernejournal

Note that this is not a required order. The client is free to do step 3 before step 2, or to do step 3 as the user logs onto the client and just store the user token until it is needed.

...

The token must be attached as a Bearer token i requests to Kjernejournal API's. Typically EHR will use an Authorization code grant with HelseId to get a token. This flow is not described in detail here as it is a Oauth2/OIDC standard. More information can be found at  
See  helseid.no and https://utviklerportal.nhn.no/informasjonstjenester/helseid/ for more information about integrating with HelseID. NB! KJ APIs require access tokens with the API Resource as the only audience, see doc at https://helseid.readthedocs.io/no/latest/atlassian.net/wiki/spaces/HELSEID/pages/481755152/Requesting+multiple+access+tokens+with+single+audiences

Integration description

All requests to kjernejournals API's are done in two steps.

...

It’s a POST to /v1/helseindikator, with a JSON body (Content-type: application/json) with the following input:

Input:

Field

Location

Required

Description

fnr

Body

Yes

Patient identifier (Norwegian national identity number).

legemiddelFraDato

Body

No

Optional parameter for information about prescriptions.

Example: 2021-06-11

samtykke

Body

No

Consent for opening the patient’s kjernejournal (used if the ticket from the response is later used to access the patient’s kjernejournal).

Can be one of the following values:

  • HPMOTTATTSAMTYKKE

  • HPAKUTT

  • HPUNNTAK

This parameter should be sent for API integrations.

Authorization

HTTP Header

Yes

A token from HelseID sent as a bearer token.

X-EPJ-System

HTTP Header

Yes

Which EHR system, and which version, the request originated from.

 

Output in case of successful request:

Field

Location

Description

eksistererBlokkertHelsepersonell

Body

Boolean. Because Kjernejournal does not control the information once it is shared, no clinical information will be shared if the patient has blocked at least one person. Only useful for API integration.

harLasteResepter

Body

Boolean. Indicates if the patient has locked prescriptions.

harLegemidler

Body

Boolean. Indicates if the patient has any prescriptions or multidose drug prescriptions.

status

Body

One of the following values:

  • 0: The patient identifier is not a valid Norwegian national identity number

  • 1: The patient do not have kjernejournal

  • 2: Kjernejournal is available

  • 3:  Patient has filled in health information (illness history, communication issues)

  • 4: Attention: The patient has critical information registered in kjernejournal

Is to be used to determine what icon should be shown to the user.

sistEndretKritiskInfo

Body

Shows a timestamp for last change for each category of critical information for patients with status 4. Only present if the status is 4.

sistEndretKritiskInfoDato

Body

Timestamp for last change in information for patients with status 4. Only present if the status is 4.

returTekst

Body

Description of the response status. Is to be used in the tooltip of the icon.

ticket

Body

An opaque string which represents:

  • the user's organization

  • the patient

  • the consent given for opening the patient's kjernejournal (if present in the request)

Is to be used in the subsequent opening of the portal. Only present if the status is 2 or higher.

eksistererBlokkertHelsepersonell

Body

Boolean. Because Kjernejournal does not control the information once it is shared, no clinical information will be shared if the patient has blocked at least one person. Only useful for API integration.

harLasteResepter

Body

Boolean. Indicates if the patient has locked prescriptions.

sperringDetaljer

Body

Indicates which modules of kjernejournal that the patient has locked.

X-EVENT-ID

Header

The ID of the request in kjernejournal. Can be used for debugging and correlation between the systems.

Info

All API responses from kjernejournal may have an arbitrary gibberish extra field. This is to ensure that consumers can handle new fields in the response.

...

It is a simple GET to /v1/ping. The authentication and error responses are identical to the health indicator service.

Input:

Field

Location

Required

Description

Authorization

HTTP Header

Yes

A token from HelseID sent as a bearer token.

X-EPJ-System

HTTP Header

Yes

Which EHR system, and which version, the request originated from.

 

Output in case of successful request:

Field

Location

Description

Pong

Body

Timestamp

X-EVENT-ID

Header

The ID of the request in kjernejournal. Can be used for debugging and correlation between the systems.

Request example

Code Block
GET /v1/ping/ HTTP/1.1
Host: api.kjernejournal.no:8000
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IkE4...u_UjgeTxzxI2g
X-EPJ-System: ACME EHR system versjon 42.01

Response example

Code Block
HTTP/1.1 200 OK
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
X-EVENT-ID: Id-93f2826025992c6dc91b8cfd
Content-Type: application/json

{
  "pong" : "2021-04-23T16:15:15.973Z",
  "imperdieteleifendcommodo" : "Ukjent felt skal støttes av konsument"
}
Info

All API responses from kjernejournal may have an arbitrary gibberish extra field. This is to ensure that consumers can handle new fields in the response.

...

The kjernejournal Integration must be placed behind a toggle function, so that it can be (de)activated on an installation basis. It should also be possible to choose which user group or users that have access to the kjernejournal integration.

Endpoints

Service

Environment

URL

API

Test

https://api.st2.kjernejournal-test.no:8000/

API

Prod

https://api.kjernejournal.no:8000/

Related error codes

See Error codes and messages

...