Data privacy is an essential human right to determine what, when, and how personal data is communicated to various recipients. In the healthcare domain, it is an important and challenging issue how to safeguard data privacy of patients. Healthcare providers have to process sensitive medical data compliantly with binding privacy regulations such as the European Union General Data Protection Regulation. Clinical work ows play an important role in healthcare domain by outlining the tasks must be done for the delivery of clinical services. However, in general, they do not support privacy constraints in an adequate way. In this paper, we propose an ontology-based privacy compliance check approach to detect the possible privacy violations in clinical work ows. In order to analyze the potential applicability of our methodology, we describe a Newborn Screening scenario where we show how to apply semantic reasoning to support building privacy-awareness.
The European Union General Data Protection Regulation (GDPR) has come
into force very recently to protect data privacy of all individuals within the
European Union [
In order to support PbD, the organizations can greatly bene t from the business process models via checking privacy compliance of their business process models during the design time. Business process modeling and management are mostly based on a control- ow-centric perspective which emphasizes on the sequencing of activities with ignoring the data aspects. However, we believe that business process models can also be considered as a means to capture how data is transmitted by whom and for what purpose at the conceptual level. Business process models are usually captured using the Business Process Model and Notation (BPMN), hence, we use BPMN to model clinical work ows.
We represent privacy-awareness for the clinical work ows not only in terms of the regulatory compliance with the GDPR and the privacy policies of healthcare providers, but also in terms of the compliance with the privacy preferences of patients when sharing and/or processing their personal data. We have used an ontology-based reasoner to verify privacy compliance. Ontology development contributes to our research signi cantly in terms of sharing a common understanding among di erent domains, namely business process modeling, privacy, and clinical domains.
In this paper, we present our Privacy-aware Clinical Work ow (PaCW) ontology and we give a running example which is related to the newborn screening procedure applied in Germany to show how our reasoning approach works. We selected the clinical work ows as a case study because privacy in the clinical domain is particularly signi cant due to the high sensitivity of \data concerning health". However, our proposed approach is domain-independent and can thus be applied to any other domain.
The rest of this paper is organized as follows: Section 2 explains our Privacyaware Clinical Work ow (PaCW) Ontology in detail. Section 3 presents our reasoning approach to check privacy compliance and discusses the implementation details. Section 4 gives a running example in the clinical domain in order to show the usability of our reasoning approach. Section 5 reviews related works. Finally, Section 6 concludes this paper and discusses our future work and perspectives. 2
Our research brings business process modeling, data privacy, and clinical domains together. We used ontologies to bridge the gap and share a common understanding of these domains. We developed the Privacy-aware Clinical Work ow (PaCW) Ontology which consists of three ontologies which are Privacy Ontology, BPMN Ontology, and Clinical Domain Ontology. In this section, we propose Privacy Ontology and BPMN Ontology, as well as the mappings between them. We explain Clinical Domain Ontology while presenting our running example. We have developed our ontologies through the Uni ed Modeling Language (UML). 2.1
Privacy compliance is mostly de ned as a stakeholder's accordance with established privacy policies and/or privacy regulations. We argue that privacy compliance has a broader de nition considering also the data owners' (data subjects') personal privacy preferences. In this regard, we de ne \privacy-awareness" for clinical work ows as the compliance both with the privacy principles based on the GDPR and the privacy policies provided by healthcare providers, as well as the compliance with the privacy preferences of patients on sharing or processing their personal medical data. In this section, we brie y introduce these three sources which contribute to our privacy-awareness de nition and then we present our Privacy Ontology.
Privacy Principles based on the GDPR We have introduced the founding privacy principles for clinical work ows on the ground of the GDPR. Even though we have focused on the GDPR, we believe these principles are also relevant and valuable for other regulations. 1- Purpose Speci cation: \Personal data shall be collected for speci ed, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes [...]" [Article 5, x1(b)] 2- Data Minimization: \Personal data shall be adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed." [Article 5, x1(c)] 3- Consent Check: \Processing shall be lawful if the data subject has given consent to the processing of his or her personal data for one or more speci c purposes." [Article 6, x1(a)] 4- Limited Retention Period: \Personal data shall be kept in a form which permits identi cation of data subjects for no longer than is necessary for the purposes for which the personal data are processed [...]" [Article 5, x1(e)]
In summary, for data operations to be GDPR compliant: 1. data must be processed for a speci ed purpose, 2. the data owner has consented -unless the speci c conditions such as \vital interest" or \public interest" are met for lawful processing-[Article 6], 3. be necessary to achieve the speci ed purpose, 4. and data must be erased when it is no longer necessary for the given purpose. Privacy Policies According to the GDPR, service providers have to inform the data subjects about how their personal data is being used by specifying privacy policies. A privacy policy document is a high-level natural language description of the privacy practices of a service provider. Privacy policies describe what data is used, for what purpose and by whom, as well as how long the data will be retained. They might also contain the modality of data processing, whether it requires explicit consent or not.
Privacy Preferences We have constructed our privacy preference formulation
based on Alan Westin's de nition of privacy. In his well-known book Privacy
and Freedom, he de nes privacy in terms of self-determination: \Privacy is right
on decision of every individual: when, how and how much information will be
available for storing and exchange between systems." [
Purpose +purposeName: String
ConsentPolicy +requiresConsent: bool DataMinimizationPolicy +userRole: String +data: List <Data> +condition: bool
User +userName: String +userRole: String Legend:
PrivacyRule +purpose: Purpose
PolicyRule RetentionPolicy +data: Data +retention: String
PreferenceRule +dataSubject: DataSubject +user: User +data: Data +duration: String +condition: bool +status: bool
Data +dataName: String +dataCategory: String
DataSubject +dataSubjectName: String +prefList: List <PreferenceRule> Directed Association
We built privacy ontology according to these three sources. Figure 1 illustrates the main components of the privacy ontology: Both privacy policy statements (PolicyRule) and privacy preferences (PreferenceRule) are dened as PrivacyRule. Privacy rules are all purpose-focused, hence they are associated with the Purpose ontology class which speci es the reason for which data is collected, used, or disclosed. PolicyRule class has three sub-classes: ConsentPolicy ontology class de nes which kind of Purpose instances require explicit consent. RetentionPolicy declares the retention period of data practices. DataMinimizationPolicy expresses the amount of personal data which should be revealed and processed by the users in di erent conditions. User is the set of individuals or organizations who accesses the personal data. Data is categorized to adopt the right privacy measures suitable for the type of data to be protected. We have used di erent data categories which are de ned in the GDPR (personal data, sensitive data, identi cation data, anonymous data, public data, etc.) DataSubject refers to any individual person who can be identi ed. prefList represents a list of PreferenceRule. 2.2
The Business Process Model and Notation (BPMN) is a widely used standard for business process modeling and also maintained by the Object Management Group (OMG). Therefore, we have selected BPMN 2.0 as the modeling notation for the clinical work ows.
Figure 2 shows the graphical representation of the core BPMN elements used
in our clinical work ows. We have adapted the BPMN 2.0 Ontology presented
in [
Start Event End Event Exclusive Gateway
Parallel Inclusive Gateway Gateway
Data Store l Poo ean
L
Data privacy in clinical work ows is a subject of how data is handled in BPMN. Therefore, we have worked on di erent ways of data handling supported in BPMN (shown in Table 1) and we created new ontology classes to support data privacy in clinical work ows accordingly.
Figure 3 illustrates the main components of our BPMN ontology. It presents the important attributes and operations of the ontology classes and \is-a" hierarchy (generalization) among them. We omitted the association relations for the sake of illustration (except the one between BPMNModel and BPMNElement).
InteractionNode
Node
Pool +userRole: String
Lane +userRole: String +belongsTo(): Pool
The ontology classes for the core BPMN elements are adapted from BPMN
2.0 Ontology [
Data Store Data Store Data Object Data Object
A e n a L B e n a L
Task Task Task
Task
Data Store Task A
Task B Data
Object Task A
Task B in clinical work ows are DataOperationTask, DataHandler, and DataAnnotation. DataOperationTask is a type of Task which has a data association. As it is illustrated in Table 1, data is generally handled either via DataAssociation or via MessageFlow. Alternatively, data may be directly associated with a sequence ow via Association. DataAnnotation is a type of TextAnnotation. We assume that for each data operation in a BPMN work ow, it is known which data is used for which purpose explicitly. For this we use DataAnnotation, where purpose referring to the purpose of accessing data and data referring to a set of data which is accessed. DataOperationTask has haveConsent() function which aims to nd out whether a data operation task has consented. The attributes written in red indicate that they are associated with the ontology classes from Privacy Ontology. The foundational components of Privacy Ontology, namely User, Data, and Purpose are represented in clinical work ows via a set of BPMN constructs. User is mapped onto the BPMN Pool and Lane elements. Data and Purpose are represented via the BPMN Data Annotation element.
Clinical Workflow (BPMN 2.0) (2) Transform into BPMNModel Java Instance
BPMNModel (Java Instance)
Privacy Ontology
PaCW: Ontology Stack
(UML) BPMN Ontology
Clinical Domain
Ontology (1) UML to Java Classes
Privacy Policy
Privacy
Preference PaCW Ontology (Java Classes)
Rule Base
(DRL) Reaso(nDerrofoolsr CRoumlepElinagnicnee)Check (4) Execute Reasoner result (compliant or not)
(2) Parse Clinical Work ow and Create a BPMNModel Instance accordingly: Our input clinical work ows are in BPMN 2.0 format. In order to parse these les, we used Camunda BPMN Model API2. We accessed the BPMN elements via this Java library and we created BPMNModel Java Class instance by using the constructor of BPMNModel ontology class. (3) Create Privacy Rule Instances: Our privacy rules are coming from either privacy policies or privacy preferences. We created PrivacyPolicy and PrivacyPreference Java Class instances by using the constructors of these ontology classes. For instance; below you can see a Java class instance for the ConsentPolicy ontology class. public class PrivacyRuleInstances{
ConsentPolicy p1 = new ConsentPolicy (new
Purpose("hearing-screening"), true); } (4) Execute Compliance Check Rules via Rule Engine: We implemented our rule engine by using Drools Business Rule Engine.3 Eclipse o ers a plugin for Drools which o ers a development environment for rules manipulation. Drools 1https://eclipse.org/umlgen/. 2https://docs.camunda.org/manual/7.7/user-guide/model-api/bpmn-model-api/. 3https://www.drools.org/. is a Java-based open source business rule management system with a forwardchaining and backward-chaining inference based rules engine. Drools has its own rule language called Drools Rule Language (DRL). In DRL syntax, every rule has a \when" section which de nes the conditions to be ful lled to trigger the rule and a \then" section which de nes the actions to be executed when the rule is triggered. DRL uses instances of Java classes, thus all concepts in the UML ontology are represented as plain Java classes. We created compliance rules regarding each privacy principles which we have proposed. Below, you can nd two examples of DRL rules as \Purpose-Speci cation-Check" and \ConsentCheck" DRL rules. \Purpose-Speci cation-Check" checks for each DataHandler whether there is a data annotation. It also nds out whether the data annotations have a purpose. If there is no data annotation or if there is no purpose for the data annotation, the rule gives a failure message. rule "Purpose-Specification-Check" when
BPMNModel.DataHandler(!hasDataAnnotation() ||
!dataAnnotation.hasPurpose()) then
System.out.println("Compliance Check fail: Purpose-Specification"); end \Consent-Check" DRL rule checks whether the data associations requiring consent according to privacy policy rules have consented in the BPMN model. For this purpose, we use haveConsent function. It searches whether the consent check pattern (illustrated in Figure 5) precedes the data associations. If haveConsent function does not encounter the consent check pattern preceding a data association, DRL rule returns a failure message.
check consent data d: consent p: purpose
yes <<Precedes>>
Data Operation Task requiring consent data d: data p: purpose rule "Consent-Check" when
ConsentPolicy(requiresConsent = true, $p: purpose) BPMNModel.DataInputAssociation ($d: dataAnnotation, $d.getPurpose() = $p, !source.haveConsent()) || then end
BPMNModel.DataOutputAssociation ($d: dataAnnotation, $d.getPurpose = $p, !target.haveConsent())
System.out.println("Compliance Check fail: Consent-Check");
Purpose Screening Hear
Screening
Data2 name=hear screening result
Clinical Ontology procedure. It also shows the mappings when we parse this model and create a BPMNModel instance accordingly. The mapping include some concepts from Clinical Ontology. For instance, according to the ontology pediatrician is a medical sta . When a privacy rule is regarding medical sta as user, it is also about its subclasses including pediatrician.
In order to check privacy compliance, the compliance rules given in DRL are executed. In this section, we look at the compliance with the \PurposeSpeci cation-Check" and \Consent-Check" DRL rules. In the running example, there are two data associations which are also DataHandler. \PurposeSpeci cation-Check" rule checks the failure cases. It checks both data associations whether they have DataAnnotation and whether their data annotations have a purpose. Since both of the conditions return false, \then" part is not executed. Hence, compliance check for the purpose principle succeeds. Both data associations require consent according to the consent policy which we have shown as privacy rule instance. \Consent-Check" DRL rule checks both data associations whether they have consented. haveConsent function searches whether the consent check pattern precedes data associations. Since the condition is satis ed, compliance rule for the consent check returns true and it gives a failure message. 5
Our research provides a holistic approach by combining privacy, business
processes, and ontologies. We grouped the related works into three research areas:
1. Privacy in Business Processes: [
In this paper, we introduced our Privacy-aware Clinical Work ow (PaCW) ontology and we provided our semantic reasoning approach for privacy compliance through a running example from the clinical domain. Our focus was detecting privacy violation via ontology-based reasoning. As a future work, we are also interested in providing corrective actions in terms of how to x the causes of violation and transform the non-privacy-aware work ow into a privacy-aware work ow accordingly.