...
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:
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 | 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:
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. |
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. |
...
See Health Indicator API for swagger documentation.
Request header:
Field | Description | Example |
---|---|---|
Authorization | Authorization | Bearer eyJhbGciOiJSUzI1NiIsImtpZCI6IkE4...u_UjgeTxzxI2g |
Content-Type | Content-Type | application/json;charset=UTF-8 |
X-EPJ-System | Which EHR the request originated and which version of the system was used | ACME EHR system version 42.01 |
Table excerpt | ||
---|---|---|
| ||
Note. The request should include the HTTP header "X-EPJ-System" that describes which EHR the request originated from and which version of the system was used. |
...
Information about the flow can be found here Welcome to HelseID’s technical documentation! — HelseID documentation.
When the EHR system requests an access token from HelseID, it must:
...
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 |
---|---|---|
API | Test | |
API | Prod |
Related error codes
...