Page Comparison

...

Main functional steps

1. The health professional logs into the EHR system.

2. The user opens the patient in the EHR system.

3. The EHR system calls the kjernejournal Health indicator service with the patients national identity.  The response has the patients critical info status and a ticket.

4. The user chooses to open kjernejournal by clicking on the KJ icon.

5. The EHR system opens the kjernejournal portal in an integrated browser window. The URL used to open kjernejournal contains the ticket that identifies the patient.

6. The patient’s kjernejournal is shown in the integrated browser.

Kjernejournal icon

The kjernejournal icon should be placed on a logical, and visible, place on the patient page in the EHR system. There are five variants that corresponds to the different statuses returned from the health indicator API.

Status value	Icon	Description
0	Image Modified	Error (the icon should not be clickable, as it is not possible to open kjernejournal on a patient with this status)
1	Image Modified	The patient is not registered in kjernejournal (the icon should not be clickable, as it is not possible to open kjernejournal on a patient with this status)
2	Image Modified	The patient is registered in kjernejournal
3	Image Modified	The patient has filled in health information (illness history, communication issues) in kjernejournal
4	Image Modified	Attention: The patient has critical information in kjernejournal

(The icons are available in SVG format. See attachements.)

...

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

Input:

Output in case of successful request:

Output in case of failed request:

...

The API lookup MUST NOT block the opening of the patient in the EHR. In the case of a timeout or slow response from KJ, the user MUST be able to use the EHR system normally.

Request example:

POST /v1/helseindikator/ HTTP/1.1
Host: api.kjernejournal.no:8000
Content-Type: application/json
Authorization: Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IkE4...u_UjgeTxzxI2g
X-EPJ-System: ACME EHR system versjon 42.01

{"fnr":"18048201209"}

Successful response example:

HTTP/1.1 200 OK
Cache-Control: no-cache, must-revalidate, private, s-maxage=0
Pragma: no-cache
X-EVENT-ID: Id-513f826053dfa2c6dc91b8dsa
Content-Type: application/json

{
  "

sistEndretKritiskInfoDato": "

2022-05-18T11:01:55.000Z",
  "ticket": "w/OS6pXpOyLvR1Cftz6sYFM1P8n7ur3upMvSPJoICpPlpmbw1C05wzboY+7n+2ie",
  "sistEndretKritiskInfo": [
    {
      "kategori": "OVER_REAK",
      "

sistEndret": "

2022-

05-

18T11:

01:

55.000Z"
    }
  ],
  "sperringDetaljer": [],
  "status": 4,
  "returTekst"

: "OBS: Kritisk informasjon i kjernejournal"

"
}

Failed response example:

HTTP/1.1 403 FORBIDDEN
Cache-Control: no-cache, must-revalidate, private, s-maxage=0
Pragma: no-cache
X-EVENT-ID: Id-543f826025992c6dc91b8dsa
Content-Type: application/json

{
    "status" : 403,
    "utviklermelding" : "Organisasjonsnummeret finnes ikke i kjernejournal",
    "brukermelding" : "Virksomheten har ikke tilgang til kjernejournal (KJF-000226)",
    "feilkode" : "KJF-000226"
}

Security

The Health indicator service requires a bearer token, which must be a client access token from HelseID (that authenticates the organization, not the user), so the EHR must retrieve a token from HelseID before calling kjernejournal.

...

As the volume of requests against the health indicator service quickly becomes quite high, the EHR system SHOULD re-use a token throughout its validity period, to reduce the amount of requests against HelseID. But it is vital that the token always represents the correct organization of the user, so if the EHR system supports multiple organizations, the token MUST NOT be shared between users of different organizations.

See helseid.no and dokumentasjon.helseid.no for more information about integrating with HelseID. 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.atlassian.net/wiki/spaces/HELSEID/pages/481755152/Requesting+multiple+access+tokens+with+single+audiences

The portal

Get patient

If the Health indicator service returns a status with value 2 or higher, the user can open kjernejournal for the patient by clicking on the kjernejournal icon. This is done by the EHR system opening the “get patient url” in the embedded browser.

...

The service is available at /hpp-webapp/hentpasient and it takes the following parameters:

...

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

Input:

Output in case of successful request:

Request example

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

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"
}

...

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

Related error codes

Errors that can be returned from the API (not all are applicable for the health indicator API):

...