Versions Compared

Key

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

...

If the user chooses to open kjernejournal, by clicking on the kjernejournal icon, the EHR system opens the kjernejournal portal in an embedded browser, showing the patient in kjernejournal.

Workflow

Gliffy
imageAttachmentIdatt615743527
macroId2f82152e-781e-47e0-ae10-9cf2bedd9a18
baseUrlhttps://kjernejournal.atlassian.net/wiki
displayNameOpening kjernejournal portal
nameOpening kjernejournal portaltled
diagramAttachmentIdatt615743522
containerId595820666
timestamp1622106234564

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

...

When the user uses the kjernejournal portal, they must be authenticated on a personal level. This can either be done by kjernejournal when the user opens a patient, or it can be SSO with the EHR system, if the user is already authenticated on the required security level. In the SSO scenario, HelseID is used for federation.

Gliffy
imageAttachmentIdatt614891575
macroId20899cd2-22a6-4497-aff4-28f8ddce7d68
baseUrlhttps://kjernejournal.atlassian.net/wiki
nameKJ-portal with HelseID client auth
diagramAttachmentIdatt614629495
containerId595820666
timestamp1620282899027

User authentication

Using kjernejournal

...

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

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

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:

Info

The response will contain several other fields - only the fields relevant for portal integration are described here.

Field

Location

Description

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

.

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.

X-EVENT-ID

Header

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

Output in case of failed request:

Field

Location

Description

status

Body

The HTTP status of the response.

utviklermelding

Body

A developer friendly description of the error.

brukermelding

Body

A user friendly description of the error. Is to be used in the tooltip of the error icon.

feilkode

Body

An error code which is associated with the error condition. See list at the bottom.

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.

...

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:

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

{"fnr":"18048201209"}

Successful response example:

Code Block
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

{
  "
returTekst
sistEndretKritiskInfoDato": "
OBS: Kritisk informasjon i kjernejournal", "sistEndretKritiskInfoDato
2022-05-18T11:01:55.000Z",
  "ticket": "w/OS6pXpOyLvR1Cftz6sYFM1P8n7ur3upMvSPJoICpPlpmbw1C05wzboY+7n+2ie",
  "sistEndretKritiskInfo": [
    {
      "kategori": "OVER_REAK",
      "sistEndret": "
2017
2022-
11
05-
29T16
18T11:
35
01:
19.003Z"
55.000Z"
    }
  ],
  "sperringDetaljer": [],
  "status": 4,
  "returTekst"
ticket
: "OBS: Kritisk informasjon i kjernejournal"
ca2gveFcW%2BdZqO2Fx7EG773Lh0TUvO2gtz45gQCbbUrKpXBJf8yS3ROacFn%2Bq
"
}

Failed response example:

Code Block
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 https://utviklerportal.nhn.no/informasjonstjenester/helseid/ for more information about integrating with HelseID.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:

Parameter

Location

Required

Description

ticket

URL

yes

URL encoded ticket from the health indicator service.

idprov

URL

no

The preferred ID provider.

ticket

URL

yes

URL encoded ticket from the health indicator service.

idprov

URL

no

The preferred ID provider.

fane

URL

no

The tab in the kjernejournal portal that should be chosen when the patient is opened.

Can be one of the following values:

  • omPasienten (the default)

  • legemidler

  • vaksiner

  • kritiskInfo

  • besokshistorikk

  • journaldokumenter

  • provesvar

X-EPJ-System

HTTP Header or URL

yes

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

Info

As web based EHR systems isn’t aren’t able to add HTTP headers to the portal requests, they MAY send the X-EPJ-System parameter in the URL instead

...

Kjernejournal also exposes a simple ping service, which can be used to test system authentication without opening a patient. It is not required to make use of this service, but it can be useful to use it as a method to verify connectivity and that the organization has been granted access to kjernejournal. This is usually implemented as a “test connection” button in the settings, and the error message here should be as detailed as possible (including stack trace or similar), as it is used by technical personnel.

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

Portal

Test

https://st2.kjernejournal-test.no

:8000

/

API

Test

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

Portal

Prod

https://kjernejournal.no/

API

Prod

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

Related error codes

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

...