...
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 | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Main functional steps
The health professional logs into the EHR system.
The user opens the patient in the EHR system.
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.
The user chooses to open kjernejournal by clicking on the KJ icon.
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.
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 | Error (the icon should not be clickable, as it is not possible to open kjernejournal on a patient with this status) | |
1 | 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 | The patient is registered in kjernejournal | |
3 | The patient has filled in health information (illness history, communication issues) in kjernejournal | |
4 | 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 | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
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:
|
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:
Is to be used to determine what icon should be shown to the user |
sistEndretKritiskInfoDato
Body
. |
returTekst | Body | Description of the response status. Is to be used in the tooltip of the icon. |
ticket | Body | An opaque string which represents:
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:
|
|
Successful response example:
|
|
|
|
|
|
|
|
|
|
|
Failed response example:
|
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.
...
Ask specifically for the scope
nhn:kjernejournal/api
(OBS: scope will be changed due to new standard)api
Use a signed JWT as client assertion (
urn:ietf:params:oauth:client-assertion-type:jwt-bearer
), signed with either an enterprise certificate or RSA key
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. |
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:
|
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 |
...
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
|
|
Response example
|
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 |
/ | ||
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):
...