The most important development area is the preparation for changes in the management of data sharing in accordance with the Client Data Act, which is dealt with in further detail on the page Management of data sharing.
Other development areas are
- purchased service solution 2.0
- changes in authors
- service events.
Purchased service solution 2.0
Development proposals stemming from the clients’ needs have been implemented in the purchased service solution 2.0.
Improved support for service voucher operations: open authorisation for purchased services
A service voucher is often granted to a person so that they can choose at a later date which service provider they would like to use.
As a result of the purchased service solution 2.0, authorisation for purchased services can be created as a so-called open authorisation, i.e. without provider details. The service provider can update the provider details for the open authorisation for purchased services at the person’s request. This will reduce the workload of the service organiser as it will no longer be necessary for the service organiser to manage the updating of the authorisation for purchased services in order to add the provider details.
Information about the service for the service provider
The organiser can enter additional information for the provider concerning the authorisation for purchased services for the purpose of providing the service, for example:
- the service voucher identifier
- the classification data of the service contents
- reference to a document in the Patient Data Repository
- additional information for the purpose of providing the service.
It is possible for the service provider to retrieve all of its own open authorisations for purchased services in one go without specifying the patient. The provider will receive information about its forthcoming tasks on the basis of this retrieval option and the service data entered for the authorisation for the purchased service.
It is now possible to use the service provider’s service unit data as a new search term.
Improved monitoring of purchased service and service voucher production
In a purchased service situation, the identifier/s for the authorisation of the purchased service is entered for the service event. This information makes it possible to monitor work that is carried out as a purchased service.
Deployment schedules for purchased service solutions
- The functional definitions for the Patient Data Repository (in Finnish) were published on 1 June 2020.
- The development work aims for client testing preparedness for the developers of patient data systems Q4/2020.
- Clients’ deployments can start after joint testing has been completed in 2021.
Changes in authors
Support for three new author types is being introduced for the Patient Data Repository:
- KOR: Correction, or the KOR role, is utilised when the original entry includes data that has been entered or produced incorrectly. In addition to the author data entered with the KOR role, the entry shows the author data of the original entry (for example, the original author is shown in My Kanta Pages).
- The OHJ author role and the related instructions are needed because different types of software robots, medical devices, etc. generate an increasing amount of material for the Patient Data Repository. With medical devices complying with the EU Medical Device Regulation (2017/745), identification takes place with the UDI (Unique Device Identifier).
- KAN: In the appointment document, KAN is permitted as the author’s role if the patient is the last person producing data for the document.
Schedules for the deployment of the purchased service solution and changes in authors
- THL has prepared the functional definitions related to the development of the purchased service solution and changes in authors. The functional definitions for the Patient Data Repository (in Finnish) were published on 1 June 2020.
- The development work aims for client testing preparedness for information system developers Q4/2020.
- Clients’ deployments can start after joint testing has been completed.
New service requests in the Patient Data Repository
New service requests are the recommended way for patient data systems to retrieve and archive data in the Patient Data Repository.
The simpler method of retrieval supports retrievals from the organisation’s own register and those made in a purchased service situation. A significant number of old service requests are replaced this way.
In the archiving stage, the data is inspected to a higher degree, which ensures a higher quality of archived data.
When the volume of archived material increases, the service requests in retrieval make it easier to retrieve data. The pagination of search results enables data retrieval in smaller sections.
Schedule for new service requests
- New service requests are available to the patient data systems in the client test environment for independent testing, joint testing preparedness 09/2020. Clients’ deployments can start after joint testing has been completed.
Development of the service event
The service event connects the same service provider to the same context, for example, patient care documents and process events related to an appointment or patient care episode, such as laboratory test results.
The service event is used in the Patient Data Repository
- to establish the patient care context
- to allocate refusals to share information at the service event level
- refusal data concerning parents or guardians acting on behalf of a minor.
For the time being, a service event has been a technical data structure and it has not served healthcare professionals.
Objectives of developing the service event
- The use of service events should be clear and consistent between different service providers and in different patient data systems in order to ensure problem-free sharing of information.
- There is a need to add descriptive data to the service event so that it would be easy for a social welfare or healthcare professional to choose the correct service event, for example, information about the reason for patient care and the classification data for the service event.
- In addition, the possibility of moving from a single-level structure (service event) to a dual-level (current service event and patient care events for individual visits or the episode/service entity and the current service event) will also be examined.
- Clearer rules are needed for creating events at both levels.
- Secondary use and statistical compiling of data also give rise to the development of service events with the objective of transferring, e.g. data gathering for statistical purposes to take place on the basis of data in the Patient Data Repository (for example, monitoring of access to services).
Schedule for developing the service event
- The objective is to review the development needs and possibilities together with the social welfare and healthcare service providers in autumn 2020.
- Healthcare service providers will be able to join in the development of service event processing. We will organise reviews of the development possibilities in early autumn 2020. Register for the reviews (lyyti.fi, in Finnish).