Authorisation for the outsourcing service provider

Authorisation for the outsourcing service provider

The authorisation for the outsourcing service provider is a Patient Data Repository functionality which allows the service organiser to give the service provider the right to access the patient data stored in its register, and allows the service provider to store the patient data created in the course of the treatment in its own register.

If a healthcare service provider is unable to provide a service itself, it may acquire the service as an outsourcing service from another service provider. In such a case, the service provider commissioning the service is an outsourcing service organiser.

The healthcare service provider from whom the service has been purchased acts as the outsourcing service provider and supplies the service commissioned by the service organiser. However, patient documents such as medical records, test results and reports will remain in the outsourcing service organiser’s register.

In the outsourcing service, the service provider is granted access rights to the service organiser’s patient register in the Patient Data Repository to a degree that is determined in advance. The service provider will be able to browse the patient data recorded by the service organiser to the agreed extent. The service provider usually records the patient data it has produced as an outsourcing service directly in the Patient Data Repository in the outsourcing service organiser’s register.

The authorisation also covers the voucher-based provision of services.

The outsourcing service provider’s access and archiving rights to the patient register are determined with the authorisation of the outsourcing service.

Contents of the authorisation of outsourcing service

The authorisation of an outsourcing service is a document with a form structure. This document is produced by the outsourcing service organiser before the outsourcing service commences at the stage when the outsourcing service provider is known. The authorisation document is saved in the Patient Data Repository and the information on the document is obtained from the patient data system or a separate system (service voucher). 

The authorisation is always granted separately to a particular service provider. In addition to the service organiser and the service provider, the authorisation also determines, e.g. the validity, scope and type (patient-specific/population-level) of authorisation. 

A population-level outsourcing service concerns a large population group where individual patients are not specified in advance (e.g. screening studies).  A patient-specific outsourcing service is arranged for an individual patient (e.g. procedure, operation).

Preparations for deployment

The deployment of the functionality for the authorisation of an outsourcing service requires close cooperation and diligent preparation between the outsourcing service organiser, the outsourcing service provider, representatives of the information systems in use, the National Institute for Health and Welfare (THL), and Kela.

The deployment of the functionality progresses in stages:

  1. Familiarisation and preparation
  2. Kick-off meeting
  3. Status meetings
  4. Deployment test and reporting
  5. Start of production use

The outsourcing service organiser and provider agree with one another on the production and organisation of the service. The parties must also, e.g. familiarise themselves with the national operating models of the Patient Data Repository with respect to the outsourcing service and find out whether their own systems are ready for the deployment of the functionality. 

After the initial investigations, the outsourcing service organiser shall contact Kela (kanta@kanta.fi) to agree on the kick-off meeting between the organiser, THL and Kela. In the kick-off meeting, e.g. the preparatory tasks are dealt with, including the technical requirements for deployment (see the checklist below), and the schedules are agreed.

In addition to the kick-off meeting, joint status meetings are also held between the organiser, the service provider, THL, Kela and representatives of the system suppliers to ensure that everything is ready for the deployment.

Briefing material


Technical requirements for deployment for the organiser and service provider

The following technical issues must be ensured before deployment:

  • The outsourcing service organiser and provider must be users of the Patient Data Repository. 
  • The OID identifiers (OID identifiers of the organiser, service provider and the access point and their dependencies) related to the outsourcing service are known. 
  • The organiser and service provider have a certified information system in use.
    • The organiser’s patient data system / separate system must be able to produce the authorisation of the outsourcing service and the related functions.
    • The service provider’s patient data system must be able to produce, for example, search functions as well as the recording of patient data in the organiser’s register.
  • The technical Kanta connection through which the outsourcing service functionality is used is implemented and found to be operating well.

Establishing a new Kanta access point

The Kanta access point may be administered either by the social welfare and healthcare service provider or the Kanta provider registered in the THL – Kanta provider register (koodistopalvelu.kanta.fi, in Finnish). See THL’s instructions on joining the Kanta provider register (pdf, thl.fi, in Finnish) and the instructions on OID identifiers, node classes and the Kanta provider register (slideshare.net, in Finnish only).

The administering body establishing a new access point must take account of the following matters in the implementation of the access point:

  • The access points are subject to requirements in terms of, e.g. data communication links. These requirements are presented in the Technical connection models guide (pdf, in Finnish). The data addresses for Kanta Services required in the implementation of the access point are available by email from kanta@kanta.fi.  
  • An individual OID identifier is created for the access point. 
    • The OID identifier of the access point implemented by a provider registered in the THL – Kanta provider register (koodistopalvelu.kanta.fi, in Finnish) is created in node 13 under the OID identifier in accordance with the Kanta provider register of the provider organisation, in which case the OID of the access point is in the format 1.2.246.537.6.918.18.xxx.13 (where xxx is the organisation code according to the provider register and n is a number that identifies the access point, and which is selected by the provider). 
    • The OID identifier of the access point of a social welfare and healthcare unit is in the format 1.2.246.10.xxx.10.y.13.n (where xxx is the organisation identifier in accordance with the SOTE organisation register, y is the number that identifies the unit, and n is the number that identifies the access point, and which is selected by the organisation).
  • The SOTE server certificate is applied for the access point from the Finnish Population Register Centre. This takes place in the Population Register Centre’s web service. A correct type of identifier is selected from the drop-down menu under Service Certificate. In the certification application, please give the OID identifier for the access point, which is entered in the serialNumber field of the Subject section in the server certificate. The value entered in the commonName field of the Subject section is the data address of the primary data communication link for the access point. See further information on SOTE server certificates on the VRK website (vrk.fi).
  • The details of the new access point are reported to Kela’s Kanta Services on the form Notice of change of access point data (docx, in Finnish).

Deployment test and material

After the preparations have been made, the functioning of the connections has been verified and the parties are ready for production use, the technical functioning of the authorisation of the outsourcing service will still be ensured with a deployment test using a test case according to the instructions. 

The need for a deployment test is assessed separately in each case in connection with the kick-off meeting. The test is carried out at least when the organisation introduces the functionality for the first time with a certain system, and also at other times if there is something out of the ordinary in the data in question.

Two organisations will take part in the deployment test: the service organiser and the service provider, and their system suppliers. Both organisations will carry out their share of the test, and both will report to Kela once the test is successfully completed.

After a successful deployment test, the organisations can decide when to start production use.

Further information

Last updated 07.01.2020