datE: 14-08-2024 Status: FOR REVIEW

 

1. Primary and secondary use of healthcare data and other health data

Leading parties in healthcare, among which VWS, ZN, VZVZ, Nictiz, IHE, NFU/ AcZie, Twiin and Health-RI strive for a single national health data ecosystem for use in both healthcare itself and beyond

• Real World Care Data from healthcare (primary) for care (primary)

• Real World Care Data from healthcare (primary) for other types of use such as research (secondary)

• Other health data, such as research data (secondary) for other types of use such as research (secondary)

• Other health data, such as research data (secondary) for care (primary)

Open

Datastreams Joint health data architecture model

2. Three modules

The joint health data architecture model consists of 3 parts

1. Module Multiple use : Part in which data is made suitable for multiple use

2. Module Applications: Part with the different application areas

3. Module Generic Features: Part with Generic features in the field of trust, findability and management

3. Module Multiple use: Part in which data is made suitable for multiple use 

This concerns both Real World Healthcare Data sources (4), such as Electronic Health Records (EPDs = EHRs), and other health data sources, such as research data sources, or Electronic Data Capturing tools (EDCs) (5). We want to approach this data centrically, separating the data from the functionality in a persistent data platform (7). Hereby:

• Life cycle of the citizen can be supported

• Data can be encoded, modeled and made FAIR in an environment that is intended to reuse data

• Dependence of the roadmap on the various software suppliers can be reduced

• Integral picture of the patient/citizen can be created (network care)

3.1 Data Release Communities

Through partnerships, preferably including the software supplier itself, interfaces with the different systems (6) are developed to get data changes in the original data sources, synchronized in the persistent data platform (7). Erasmus MC, LUMC and UMCU are an example of such a partnership (CumuluZ), where the HIX EPD is accessed – near real time – in a persistent data platform. By stimulating these kinds of solutions and partnerships, we prevent the wheel from being invented in various places and we can accelerate the process.

At first this will result mainly in knowledge sharing but a common roadmap and reuse when possible is also intended.

3.2 Standardized storage and interfaces

The data in the persistent data platform (7) will be coded and modelled using Unit of language (RIVM Report 2018-0081). The Unity of language does not prescribe that every target group should use the same way of coding and modeling. Loss of quality while mapping the various encodings and modelling used, should be avoided as far as possible by harmonizing or, if necessary, standardizing the different encodings and modelling methods. The persistent data platform (7) must have version control (10), in order to be able to reproduce the situation, such as an investigation, or care view activity in the future. Data can be prepared for multiple purposes of use, by making it FAIR (8).

The standardized API (9) determines which questions may be asked about the data and how they are presented (according to Unity of language).

3.3 Service providers Multiple use: (regional) nodes

Not every healthcare institution is able to unlock data sources (4) and (5) (6) and code, model and create FAIR (8) in a persistent data platform (7), and then present them to various applications using a standard API (9). A bigger (regional) hub can act as a shared service center from a sufficient economy or scale, which provides these services for (smaller) healthcare institutions (in the region). A persistent data platform in which the various healthcare institutions have their own piece of data, which is processed for them by data stewards from the shared service center into reusable data.

4. Module Applications: Part with the different application areas 

Various application areas, such as healthcare applications (11), registry applications (12) and research applications (13) can identify / authenticate themselves to the API (possibly in combination with a Data Access Committee) in order to view data. The authorization metadata (8) indicates who can do what with the data under what circumstances. For example, a doctor who can authenticate that there is a treatment relationship with the person, can view un pseudonymized data by the API; a researcher who can authenticate that an analysis, approved by the relevant review committees of the UMC hospital, will be processed on behalf of a UMC hospital in a safe analysis environment, can view data pseudonymized and process it in a suitable analysis environment.

As much as possible, the data will only be shown and will not be duplicated (11 to 13). Exceptions could include (14):

• Referral action between different healthcare providers; whereby the healthcare provider will maintain his own file for which the basic data can be taken duplicated.

• Central analysis method, where data is duplicated during the research into a secure processing environment; After the examination, the data will be deleted.

5. Module Generic features: Part with the Generic features 

Generic functions must be generic, both for use in healthcare (primary) and outside (secondary).

15. Authentication, Identification and Authorization; In a trust model, it must be possible to record that a person functions with a certain role; authorizations can be assigned to that role. This role-based Authentication and identification must be standardized across domains, so that different authorizations can be assigned to the different Healthcare Professional roles, as policy makers roles, as citizens roles, as researchers’ roles.

16. Metadata template repository: Disease-specific domain expertise of data stewards in (quality) registries are valuable in initial coding, modeling, and FAIRification of disease-specific domain data. The national implementation process is accelerated with a generic function, which makes these code and modeling books with FAIRification available as reusable templates.

17. Mapping: Both data holders and data users use the data according to coding and modeling methods described in the Unit of language. If data holders and data users each use a different way of coding and modelling supported by the Unit of language, a generic function ensures the correct mapping.

18. (De)Pseudonymization; Pseudonymization keys must be able to be used across organizations to de-pseudonymize and to be able to link data from the same person (for example with research, using multiple data sources).

19. Localization; currently mainly for use in healthcare; This makes it possible to request certain data from different sources from one person ; the question is to what extent this differs, or can if it can use the same techniques as the search and request catalog function (23), where certain data from different sources is requested for a group of persons.

20. Terms of use; also called permission; The aim is to give people a single transparent place, both for primary and secondary use, where they can

• Specify who has access to the data

• Gain insight into who has had access to the data

21. Addressing; be able to correctly address data sources for both primary and secondary use

6. Total picture of the joint health data architecture model

When the structure of the 3 different modules is combined, the following overall picture is created: