Guidelines

The following guidelines are not strict requirements, but recommendations to make a better overall experience for the end-user.

The APIs should be easy to use

As end-users of the APIs have a busy workday it’s important to make the usage of the APIs as simple as possible for the end-user. Ideally, the end-user should not need to care about the underlying APIs in the sense that the flow of data is abstracted away from the end-user. Neither should usage of the APIs require the end-user to learn anything new nor need to click on several buttons in order to use the APIs.

Finally, the end-user should not need to consider whether a piece of information is considered as alert information. Synchronization of alert information takes place “behind the curtains”, and the end-user should not need to make an active decision whether to share the information or not.

Synchronizing alert information between EHR and kjernejournal

Why synchronize alert information?

What type of alert information shall be synchronized?

Only information that is critical to know before treatment can be given, shall be shared. The EHR may have registered e.g. an allergy to a food that gives a patient minor stomach ache, but this is not critical information that should be shared. The coding systems specified in the FHIR profiles will restrict what type of alert information can be registered.

Who is the master for alert information?

There is a need for sharing alert information between systems. If sharing is going to work, someone must have control of what is the latest version of a registration. Therefore kjernejournal as the national register for alert information must be the national master for alert information. At the same time, healthcare professionals are by law required to keep an updated medical record in their EHR for the patient and the EHR is the master for the local data.

How to handle simultaneous changes?

An alert information record in kjernejournal is identified by an unique id and a version number. Kjernejournal will reject changes to a record, which are not done using the latest version. This will ensure that all changes are done on the current version of an alert info registration.

Before treatment is given to a patient, the healthcare professionals look for an up-to-date health information for that patient. The EHR shall then make a request to kjernejournal to get any nationally registered alert information updates so that the healthcare professional can see the current version of data.

How to synchronize alert information?

Manually handling will probably be required when synchronizing data, but this depends on how structured the alert information is registered, and how the local EHR structure maps to the FHIR profiles.
The EHR will normally have a lot of alert information registered. In order to avoid a huge startup task of synchronizing alert information, a good approach may be that healthcare professionals try to synchronizing alert information when they are working with a patient.

Both when synchronizing alert information first time and later, there may be alert information that is:

• registered only in local EHR

• registered only in kjernejournal

• registered both in local EHR and kjernejournal - with the same information-id (Synchronised information)

• registered both in local EHR and kjernejournal - without the same information-id, (may be duplicates of the same information)

Downloading from kjernejournal can be done automatically, but manually handling by healthcare professionals is probably required when handling duplicates and sometimes when uploading new information.
The manually handling of duplicates requires that the healthcare professionals have knowledge and expertise on the alert information. If not, the uploading or handling of duplicates can be done by the next healthcare professional who is working with the patient.
The EHR must also control which healthcare professionals have access to change alert information.

Registration of a new record of critical information in the local EHR should be uploaded to kjernejournal automatically if the registered information is according to national standards for critical information.

How to handle synchronize errors?

In order to have a simple solution for the synchronizing of alert information and avoid issues addressed in Architectural considerations below, a “best-effort” approach is chosen. It is assumed that the connection between the EHR and kjernejournal is stable and that both systems as critical healthcare systems have high availability. Therefore few synchronize errors are expected because of technical issues. No records will be lost, the data will still be either in the EHR or in kjernejournal.

If the upload or download of a record fails, the users shall be presented with an error. The user may retry or the synchronizing can be done the next time when working with the patient.

Display error if download from kjernejournal fails

Display error if upload fails

Architectural considerations

The architecture of the solution should be tailored to fit the health trust’s need. One is free to choose the architecture, but in case there will be no direct integration between an EHR and the API endpoints one need to bear the following aspects in mind:

• In order to have the correct version number, a write call to the APIs must be made after a read call. Any updates obtained to the registration received from the read call should be notified to the person trying to update.

• There are several challenges to synchronize the alert information if the synchronization is asynchronous between an EHR and the kjernejournal API (for example if the registration goes through a queuing system)

  • The tokens and the security ticket may expire in the queue

  • There may be updates to a registration from other parties while an update to the registration is in queue

    • There is no known way to automatically resolve issues with version number clashes

  • Error messages intended for the end-user may be lost in the queue

• Due to legal reasons synchronization using the API is only possible when a health professional has a service need