Methods used to design a reference architecture

The development of an ontology to underpin contract offers within data spaces stems from the critical need to establish a common language and clear understanding of terminologies employed in complex data sharing agreements. Data spaces often involve diverse stakeholders, each with their own domain-specific jargon and interpretations of terms. This can lead to misunderstandings, disputes, and inefficiencies in collaborative efforts. Therefore, the motivation behind creating this ontology is to harmonize the language used in contract offers, transcending industry-specific vernaculars and ensuring that all participants speak a unified semantic language. This not only enhances comprehension but also streamlines negotiations and fosters a collaborative atmosphere conducive to productive data sharing.

The proposed ontology’s acts as a foundational reference point, providing a structured and shared vocabulary that all parties involved can rely on to interpret terms consistently. It clarifies the meanings and context of critical elements within the contract, including data usage rights, access privileges, and data governance responsibilities. Furthermore, the ontology supports automation and integration, as it facilitates the development of tools and systems that can process and enforce the terms of the contract effectively. Ultimately, this ontology serves as a pivotal instrument in enabling data space stakeholders to draft, negotiate, and execute contract offers with precision, reducing the risk of miscommunication, disputes, and fostering a seamless environment fordata sharing and collaboration.

The process of building an ontology is called ontology engineering and is necessarily an iterative process. There is no singular or definitive approach to modeling a domain; instead, there exist multiple valid alternatives. To engineer out ontology, we use the seven-stepped methodology in. This methodology We will discuss the seven steps in details:

• Determine the domain and scope of the ontology.
• Consider reusing existing ontologies.
• Enumerate important terms in the ontology
• Define the classes and the class hierarchy
• Define the properties of the classes
• Define the facets of the slots
• Create instances 

First, a privacy impact assessment of the IDS reference architecture will be constructed in order to find threats and solutions to privacy and security of data and people using the data spaces that are based on the IDS reference architecture. Based on this assessment, an extension to the architecture will be developed with a focus on medical data and how to guarantee private exchange of data. The risk assessment will have a focus on situations where one data provider offers up data from many data owners. This may be the case when hospitals or doctors offer up the data of many patients who each have an individual right to be informed and have control over their data. 

To perform such an assessment, initially a set of privacy goals have to identified. According to the General Data Protection Regulation, following privacy goals are identified:

• Safeguard of quality of personal data
• Safeguard of quality of personal data and compliance with data retention requirements.
• Legitimacy of processing personal data.
• Legitimacy of processing sensitive personal data.
• Compliance with the data subject’s right to be informed.
• Compliance with the data subject’s right to access, correct and erase data.
• Compliance with the data subject’s right to object
• Safeguard of confidentiality and security of processing.
• Compliance with notification requirements

After performing the assessment, several privacy threats are identified concerning the current reference architecture model. Some of the threats include:

• Information about the process, data flow and storage are hard to understand for laymen who are not well informed about medicine, law and data. engineering.
• No privacy statement is available.
• The purpose of the third party using the data is not stated to patients upon the ability for a data transfer.
• The identity of the third party is not stated to the patients.
• Data that is not required is collected.
• No measures for data minimizations exist.
• No regular checks on the accuracy of the data is being done.
• Personal data is not being anonymized or deleted after the data purpose no longer exists.
• The relevant information is hard to access.

A data space must ensure that no natural person or data subject can be linked to a datapoint that is part of the data space. To achieve that, data must be transformed. The subgoals that need to be achieved are the 8 design privacy design strategies (introduced first by Japan-Henk Hoepman):

• Minimize: Sensitive data that is not needed should be deleted to avoid it being leaked or linked.
• Abstract: Sensitive data that needs to be used should be only used in the highest granularity at which it is useful.
• Hide: The access to sensitive data should only be granted to users with the right clearance.
• Separate: The processing or storing of sensitive data should occur on different locations to make it harder to build full profiles off of the data from location.
• Inform: The person to whom the data belongs, for our case the data subject, is informed about the processing and sharing of data.
• Control: The person to whom the data belongs has the ability to update or delete their data if needed.
• Enforce: All parties should enforce the keeping of the rules in their entire structure.
• Demonstrate: All parties should verify and publish the rules that they are keeping and how they do it.