VKP as Reverse Proxy

Submitting events

To ease the transition from VKP to JFT, it is possible to configure VKP as a "reverse proxy" when submitting events. This means that vendors using VKP for submitting events today, can continue as-is, without changing their implementation, and their events can still be handled by JFT.

The figure below shows the information flow when using VKP as a reverse proxy for JFT when submitting events.

1. Vendor acquires access token for VKP using its existing HelseID client
2. Vendor submits event to VKP, using the token from 1 for authentication
3. VKP performs a token exchange with HelseID using token from 1 to acquire an access token for JFT
4. VKP sends the event to JFT, using the token from 3 for authentication

Please note that VKP must be configured case-by-case, i.e. per municipality-vendor combination, for the reverse proxy operation to take place. In the Test environment the synthetic municipality organization number 312229544 is configured to support VKP Reverse Proxy.

Retrieving patient-related information

In VKP it is common for vendors to retrieve patient-related information as part of the event submission process. VKP's information retrieval features are planned to be handled by a new service ToBeDefined. In the meantime, VKP can be configured to forward information requests to the EHR of behalf of the vendor. This is somewhat similar to the Submitting events flow described above, but with some differences.

The figure below shows the information flow:

As the figure shows, JFT is not involved in this transaction:

1. Vendor acquires access token for VKP using its existing HelseID client
2. Vendor submits information request to VKP, using the token from 1 for authentication
3. VKP connects to the EHR in question and forwards the request as-is
4. EHR sends the response to VKP
5. VKP forwards the response as-is to the vendor

Again, please note that VKP must be configured case-by-case, i.e. per municipality-vendor combination, for this operation to take place.