Use cases
Some use cases for this API:
- 1 Retrieve alert info for a patient
- 2 Upload alert information for a patient
- 3 Change or update the alert information for a patient
- 4 Delete alert information for a patient
- 5 Access when the SCR is blocked for some health personnel
- 6 Access a locked Summary Care Record
- 7 Access locked Alert Information
See Flow for EHR to retrieve alert information for a patent from kjernejournal for the full flowchart with required ticket and HelseID tokens.
Retrieve alert info for a patient
Retrieve alert info for a patient
Healthcare professional should read the national alert information for a patient before treatment can begin
Upload alert information for a patient
Upload alert information for a patient
If a patient has critical alert information, this should be recorded in kjernejournal as the national master* database.
Change or update the alert information for a patient
Change or update the alert information for a patient
If the alert information for a patient has changed or is not longer valid, the record in kjernejournal as the national master* database should be updated.
Delete alert information for a patient
Delete alert information for a patient
Delete shall only be used when a registration is “entered in error”, e.g. wrong patient. Records will not be physically deleted, but will have “clinical status” set to “entered-in-error”.
If the information is no longer valid, update the registration and set the verification status to “refuted”.
Access when the SCR is blocked for some health personnel
A patient can block some health personnel from his/her summary care record as well as alert information. All CRUD(CreateReadUpdateDelete) APIs will return an error (i.e. KJF-000180), if they receive requests originating from any health personnel against that patient. See https://kjernejournal.atlassian.net/wiki/spaces/KJERNEJOURDOK1/pages/664634635 for information regarding errors.
It is not possible to block that specific health personnel using APIs. This is why APIs return error for all requests against that patient. However, it is possible for other health personnel to use summary care record portal to look into(and or update) alert information of that patient.
Remember that alert information can be stored inside electronic health record. And any blockage from summary care record does not apply to infomation registered inside electronic health record of that patient.
Access a locked Summary Care Record
A Person may choose to lock his/her Summary Care Record. All CRUD(CreateReadUpdateDelete) APIs will return an error(i.e. KJF-000179), if they receive requests for that patient. See https://kjernejournal.atlassian.net/wiki/spaces/KJERNEJOURDOK1/pages/664634635 for information regarding errors.
However, alert information for these patients can be fetched either by getting patient's consent or in acute cases.
Remember that alert information can be stored inside electronic health record. And any blockage from summary care record does not apply to infomation registered inside electronic health record of that patient.
Access locked Alert Information
A Person may choose to lock his/her alert information. All CRUD(CreateReadUpdateDelete) APIs will return an error(i.e. KJF-000179), if they receive requests for that patient. See https://kjernejournal.atlassian.net/wiki/spaces/KJERNEJOURDOK1/pages/664634635 for information regarding errors.
However, alert information for these patients can be fetched either by getting patient's consent or in acute cases.
Remember that alert information can be stored inside electronic health record. And any blockage from summary care record does not apply to infomation registered inside electronic health record of that patient.
*master: Alert information serves as central national repository, which is connected to multiple EHR systems. Health personnel work within their local EHR systems. However, every EHR system must update central national repository using APIs, which are covered in this guideline.
© Norsk helsenett - kjernejournal