# The Need for Machine-Processable Agreements in Health Data Management +
## 5 A Policy Language for Multi-Privilege Consent
### Conflict Detection
In some cases, e.g., [PERSON] clearly wants to share her information with all of her siblings, while her identical twin wishes to exclude their brother [PERSON] in Example 1. Other, more subtle cases should be considered though, such as [PERSON] and her partner in Example 3. In this case, both [PERSON] and her partner agree that the children should be shared with; however, [PERSON]'s partner requests that they are shared with after they reach 15 years of age. In the case of conflict, we do not advocate a particular conflict resolution practice. The actual resolution chosen must reflect the norms and desires of the stakeholders and the culture in which they exist. For example, in the UK, the patient currently \"wins\" any conflict regarding sharing. However, because the clinician has a duty of care to individuals who are affected, we have prototyped a conflict resolution response within myKinMatters, as shown in Figure 4. Figure 4 shows how the clinician sets the sharing policy statements within myKinMatters based on an individual and their risk. Please note that the clinician is not writing Sharing policy statements, or using the language described in Section 4. Instead, she uses her medical knowledge of the genetic inheritance at play in a given disease, and identifies who must be informed. If the clinician's policy conflicts with a patient's stated sharing policy, an extra automated process is invoked that looks up the GP of all individuals \(\in\{consultants_{share}\cap patient_{nothshare}\}\) and letters are sent directly to the GP stating that the National Health Service believes this individual needs to be tested. This process is shown in Figure 5. \begin{table}
\begin{tabular}{c|c|c|c|c|c} \hline  & \begin{tabular}{c} **Sharing** \\ **Dependencies** \\ \end{tabular} & \begin{tabular}{c} **Instgations** \\ \end{tabular} & \begin{tabular}{c} **Complex Classes** \\ \end{tabular} & \
\begin{tabular}{c} **Multi-Ownership** \\ **Anonymization** \\ \end{tabular} &
\begin{tabular}{c} **Sharing vs.** \\ **Anonymization** \\ \end{tabular} \\ \hline XAC(M)L ([31; 32; 33; 34]) & ✓ & ✗ & ✓ & ✗ \\ \hline EPAL ([35]) & ✓ & ✗ & ✗ & ✗ \\ \hline Rei ([36]) & ✓ & ✓ & ✓ & ✗ & ✗ \\ \hline AIR ([37]) & ✗ & ✗ & ✓ & ✗ & ✗ \\ \hline Sticky Policies ([38]) & ✓ & ✓ & ✓ & ✗ & ✓ \\ \hline P3P, APPEL ([39; 40]) & ✗ & ✗ & ✗ & ✗ & ✗ \\ \hline XPref ([41]) & ✗ & ✗ & ✗ & ✗ & ✓ \\ \hline E-P3P ([43]) & ✓ & ✗ & ✓ & ✗ & ✓ \\ \hline APPEL ([44]) & ✓ & ✗ & ✓ & ✗ & ✗ \\ \hline P2P ([45]) & ✓ & ✗ & ✗ & ✗ & ✓ \\ \hline PPL ([46]) & ✓ & ✗ & ✗ & ✓ & ✓ \\ \hline A-PPL ([47]) & ✓ & ✓ & ✗ & ✓ & ✓ \\ \hline SecPAL, SecPAL4P ([48; 49]) & ✗ & ✗ & ✓ & ✗ & ✓ \\ \hline \end{tabular}
\end{table} 
Table 3: Privacy languages against health data sharing requirements. There are two possible extensions that can assist with conflict resolution: priorities and explanations. Allowing patients and clinicians to express priorities of sharing or not-sharing concerns may allow either fewer conflicts to develop, or to provide a way for individuals to negotiate. In addition to this, providing the ability for free-text explanations, that allow users to understand both why the information should be shared with certain groups, or the reasoning behind not sharing, may also help negotiation. In order to be tractable, approaches similar to purpose-based access control [50] could be useful. In purpose-based access control, an ontology expresses all of the purposes that data may be used for. The access request is accepted or rejected based in part on whether the purpose satisfies the release-intent. In a similar manner, an ontology may help organize reasons for people releasing or not data. No matter what, expression of these sharing concerns, priorities and explanations must not be burdensome to the users, and further work in this area must be explored.