This document discusses the use of provenance and policies to govern data handling and sharing. It presents a policy language called PAPEL that uses provenance information to define conditions for permitting or denying actions. PAPEL policies can reference past events in a provenance log and extend policies into the future. The document demonstrates how PAPEL policies can be applied to a case study involving a patient's health record at a hospital to define obligations and restrictions around examination, sharing the record for research, and de-identification of sensitive information.
(How to Program) Paul Deitel, Harvey Deitel-Java How to Program, Early Object...
Take CARE: Provenance, Policies and Your Obligations in the Future
1. Web Science & Technologies
University of Koblenz ▪ Landau, Germany
Take CARE
Provenance, Policies and Your
Obligations in the Future
http://wegov-project.eu/index.php
Christoph Ringelstein & Steffen Staab
WeST Steffen Staab 1
staab@uni-koblenz.de
2. Do you remember?
That Italian tax office published all tax data about citizens
on its Web page…
That CIA published a list of his agents on the internet….
Even in a friendly environment
allowing/disallowing data handling is a big issue
WeST Steffen Staab 2
staab@uni-koblenz.de
4. Middle Rhine Hospital
share for
research
Health
Record
WeST Steffen Staab 4
staab@uni-koblenz.de
5. Middle Rhine Hospital
1 2 3 4 5 6 7
exami- asking exami- prepare share for
admission research
nation permit nation share research
You
Health
Record
1. I want to describe
Jane Doe
what may be done
with my record
2. I want to define what
must be done with my
record (obligation)
WeST Steffen Staab 5
staab@uni-koblenz.de
6. Integrating Policies with Provenance
Motivation
Provenance
very general mechanism to represent
• which past events may influence policy decisions
Provenance
natural mechanism to consider the past and
extend this consideration into the future
WeST Steffen Staab 6
staab@uni-koblenz.de
7. Policies build on the Past and Affect the Future
Provenance now Future Provenance
..
s2 s3 s4 s5 s6
examination asking examination discharge transfer .... .. s8.a
..
..
..
permit
s7.a s8.b s8.c
s10
prepare
share
No permission s11 ....
share
allowed s12 s13
analysis
WeST Steffen Staab 7
staab@uni-koblenz.de
8. WHAT MAY BE DONE?
PAPEL: A POLICY LANGUAGE
USING PROVENANCE
WeST Steffen Staab 8
staab@uni-koblenz.de
9. Middle Rhine Hospital
1 2 3 4 5 6 7
exami- asking exami- prepare share for
admission research
nation permit nation share research
You
Health
Record
Contextual Properties Provenance
Information of the Data Information
Actor, Time, .. Owner, Type, .. History, ..
WeST Steffen Staab 9
staab@uni-koblenz.de
10. Middle Rhine Hospital
1 2 3 4 5 6 7
exami- asking exami- prepare share for
admission research
nation permit nation share research
You
Health
Record
Contextual Properties Provenance
Information of the Data Information
Actor, Time, .. Owner, Type, .. History, ..
WeST Steffen Staab 10
staab@uni-koblenz.de
11. Middle Rhine Hospital
1 2 3 4 5 6 7
exami- asking exami- prepare share for
admission research
nation permit nation share research
Jane Doe
Health
Record 1. - 2. Provenance & Policies
3. Conditions based on Provenance
4. Hiding Information
5. Attributes
6. Interpreting
Conditions
WeST Steffen Staab 11
staab@uni-koblenz.de
12. Middle Rhine Hospital
1 2 3 4 5 6 7
exami- asking exami- prepare share for
admission research
nation permit nation share research
You
Health
Record
Policies
Prove-
nance
WeST Steffen Staab 12
staab@uni-koblenz.de
13. Middle Rhine Hospital
1
admission
Health
Record create
Policies create
Prove-
nance create
WeST Steffen Staab 13
staab@uni-koblenz.de
14. Middle Rhine Hospital
1
admission
Health
Record create
Policies create
Sticky
Log create OPM [1]
Syntax of Provenance in Sticky Logs:
step (Data, Actors, InvolvedAgents, Category, Purpose, ID, PIDs)
Sticky Log:
step (record, {mrh}, {}, create, patient_treatment, 1, {0})
WeST Steffen Staab 14
staab@uni-koblenz.de
15. Middle Rhine Hospital
1
admission
Health
Record create
Policies create
Sticky
Log create (P1): ukob is allowed to process health records for research purposes.
However, ukob is not allowed to transfer the health records of patients to
other organizations.
(P2): The mrh demands that the record is only accessed by ukob after
the sharing of the health records is approved by the patient and the
approval must have been confirmed by a doctor.
WeST Steffen Staab 15
staab@uni-koblenz.de
16. Middle Rhine Hospital
1
admission
Health
Record create
Policies create
Sticky (P1): ukob is allowed to process health records for research purposes.
create
Log However, ukob is not allowed to transfer the health records of patients to
other organizations.
WeST Steffen Staab 16
staab@uni-koblenz.de
17. Middle Rhine Hospital
1
admission
PAPEL Syntax for Policies:
Health permit (ID) IF Condition .
Record create deny (ID) IF Condition .
Policies create
XACML [2]
Sticky (P1): ukob is allowed to process health records for research purposes.
Log create
permit (ID) IF step (record, {ukob}, _, _, research, ID, _).
However, ukob is not allowed to transfer the health records of patients to
other organizations.
deny (ID) IF step (record, {ukob}, _, transfer, _, ID, _).
WeST Steffen Staab 17
staab@uni-koblenz.de
18. Middle Rhine Hospital
1
admission
Health
Record create
Policies create
Matches step(..) an
element of the history?
Sticky (P1): ukob is allowed to process health records for research purposes.
Log create
permit (ID) IF step (record, {ukob}, _, _, research, ID, _).
However, ukob is not allowed to transfer the health records of patients to
other organizations.
deny (ID) IF step (record, {ukob}, _, transfer, _, ID, _).
WeST Steffen Staab 18
staab@uni-koblenz.de
20. Middle Rhine Hospital
1 2
exami-
admission
nation
Health
Record create update
Policies create
Mapping the
Sticky
Log create update temporal structure
to a graph structure!
Sticky Log:
step (record, {mrh}, {}, create, patient_treatment, 1, {0})
step (record, {mrh}, {}, update, examination, 2, {1})
WeST Steffen Staab 21
staab@uni-koblenz.de
21. Middle Rhine Hospital
1
admission
Health
Record create
Policies create
Sticky
Log create
(P2): The mrh demands that the record is only accessed by ukob after
the sharing of the health records is approved by the patient and the
approval must have been confirmed by a doctor.
WeST Steffen Staab 22
staab@uni-koblenz.de
22. Middle Rhine Hospital
1
admission
Health
Record create
PAPEL Syntax for Policies:
condition AND condition
Policies create condition OR condition
condition XOR condition
NOT condition
step (A) AFTER step (B)
Sticky
Log create
(P2): The mrh demands that the record is only accessed by ukob after
the sharing of the health records is approved by the patient and the
approval must have been confirmed by a doctor.
permit (ID) IF (step (record, {ukob}, _, access, _, ID, _) AFTER
(step (record, {doctor}, _, _, confirmation, _, _) AND
step (record, {patient}, _, _, access_approval, _, _))).
WeST Steffen Staab 23
staab@uni-koblenz.de
23. Middle Rhine Hospital
1 2 3 4
exami- asking exami-
admission
nation permit nation
Health
Record create update update
Policies create update
You
Sticky
Log create update update Hiding
Sensitive
Information
WeST Steffen Staab 24
staab@uni-koblenz.de
24. Middle Rhine Hospital
1 2 3 4
exami- asking exami-
admission
nation permit nation
Health
Record create update update
Policies create update
Syntax for Sticky Logs:
step (Data, Actors, InvolvedAgents, Category, Purpose, ID, PIDs)
Jane Doe
Sticky
Log create update update
Syntax of Reduced Facts in Sticky Logs:
reduced (Data, Actors, InvolvedAgents, Category, Purpose,
ID, PIDs)
replace with hidden as required.
WeST Steffen Staab 25
staab@uni-koblenz.de
25. Middle Rhine Hospital
1 2 3 4
exami- asking exami-
admission
nation permit nation
Health
Record create update update
Policies create update
Jane Doe
Sticky
Log create update update
Syntax of Reduced Facts in Sticky Logs:
reduced (Data, Actors, InvolvedAgents, Category, Purpose,
ID, PIDs)
replace with hidden as required.
Sticky Log:
step (record, {mrh}, {}, create, patient_treatment, 1, {0})
step (record, {mrh}, {}, update, examination, 2, {1})
reduced (record, hidden, hidden, update, hidden, 4, {2})
WeST Steffen Staab 26
staab@uni-koblenz.de
26. Middle Rhine Hospital
1 2 3 4 5
exami- asking exami- prepare
admission
nation permit nation share
Health
Record create update update de-id.
Policies create update fulfill
You
Sticky
Log create update update update
encrypt Using
Attributes
WeST Steffen Staab 27
staab@uni-koblenz.de
34. Middle Rhine Hospital
1 2 3 4 5 6 7
exami- asking exami- prepare share for
admission research
nation permit nation share research
Health
Record create update update de-id. transfer read
Policies create update fulfill check check
transfer
You
Sticky
Log create update update update update update
encrypt transfer
Formal definition of semantics available.
WeST Steffen Staab 35
staab@uni-koblenz.de
35. WHAT MUST BE DONE?
OBLIGATIONS WITH CARE
WeST Steffen Staab 36
staab@uni-koblenz.de
36. Policies – Obligation
(P1): Staff members are permitted to transfer the record to Jane Doe
after her discharge.
(P2): Staff members and the archive are permitted to transfer the
record to staff members.
(O1): Jane Doe demands to receive her record after her discharge.
(O2): A nurse has to transfer the record to the archive if she received it
after the patient’s discharge.
(D1): Jane Doe is denied to transfer her record.
discharge transfer transfer
Jane Doe
Bob Alice
(physician) (nurse)
WeST Steffen Staab 37
staab@uni-koblenz.de
37. Policies – Obligation
(P1): Staff members are permitted to transfer the record to Jane Doe
after her discharge.
(P2): Staff members and the archive are permitted to transfer the
record to staff members.
(O1): Jane Doe demands to receive her record after her discharge.
(O2): A nurse has to transfer the record to the archive if she received it
after the patient’s discharge.
(D1): Jane Doe is denied to transfer her record.
Obligation 1
discharge transfer transfer
Jane Doe
Bob Alice
(physician) (nurse)
archive
WeST Steffen Staab 38
staab@uni-koblenz.de
38. (P1): Staff members are permitted to transfer the record to Jane Doe
after her discharge.
(P2): Staff members and the archive are permitted to transfer the
record to staff members.
(O1): Jane Doe demands to receive her record after her discharge.
(O2): A nurse has to transfer the record to the archive if she received it
after the patient’s discharge.
(D1): The archive is not allowed transfering records to non-staff.
Obligation 1 Obligation 2
transfer transfer transfer
Alice (nurse) archive Jane Doe
WeST Steffen Staab 39
staab@uni-koblenz.de
39. (P1): Staff members are permitted to transfer the record to Jane Doe
after her discharge.
(P2): Staff members and the archive are permitted to transfer the
record to staff members.
(O1): Jane Doe demands to receive her record after her discharge.
(O2): A nurse has to transfer the record to the archive if she received it
after the patient’s discharge.
(D1): The archive is not allowed transfering records to non-staff.
Obligation 1 Obligation 2
transfer transfer transfer
Alice (nurse) archive Jane Doe
WeST Steffen Staab 40
staab@uni-koblenz.de
40. (P1): Staff members are permitted to transfer the record to Jane Doe
after her discharge.
(P2): Staff members and the archive are permitted to transfer the
record to staff members.
(O1): Jane Doe demands to receive her record after her discharge.
(O2): A nurse has to transfer the record to the archive if she received it
after the patient’s discharge.
(D1): The archive is not allowed transfering records to non-staff.
Obligation 1 Obligation 2
transfer transfer transfer
Alice (nurse) archive Bob (physician) Jane Doe
WeST Steffen Staab 41
staab@uni-koblenz.de
45. Which next steps
have a destiny?
?
discharge transfer transfer
Alice (nurse) archive
Jane Doe
WeST Steffen Staab 46
staab@uni-koblenz.de
46. Policies
...
Input: step (record_jd, bob, null, discharge, 5, {4})
step (record_jd, bob, alice, transfer, 6, {5,13})
History +
Next Step + +
Policy Rules step (record_jd, alice, jane, transfer, 7, {6})
+
permit (ID) IF step (record_jd, S, jane_doe, transfer, ID, _) AFTER
step (record_jd, _, _, discharge, _, _) AND
instance_of (S, staff_member).
Translation:
Axioms specifying possible steps.
Axioms +
Translation
+
Translation to colored Petri nets.
Decision:
Reachability of a future state where all obligations are met.
WeST Steffen Staab 47
staab@uni-koblenz.de
47. Which next steps
have a destiny?
discharge transfer transfer
Alice (nurse) archive
Jane Doe
WeST Steffen Staab 48
staab@uni-koblenz.de
48. Conclusion
Policies with Obligations:
`Business rules‘ may decide about what may/may not and
must be done to your data
Provenance Graph is core to store what has and will be
done to data
Formal underpinning of our approach makes it
semantically sound and complete
WeST Steffen Staab 49
staab@uni-koblenz.de
49. Web Science & Technologies
University of Koblenz ▪ Landau, Germany
Thank You!
http://wegov-project.eu/index.php
Key Publications
Ringelstein, Christoph; Staab, Steffen (2010):
PAPEL: A Language and Model for Provenance-Aware Policy Definition and Execution.
In: BPM 2010 - International Conference on Business Process Management.
Ringelstein, Christoph (2011): Data Provenance and Destiny in Distributed Environments.
PhD-Thesis. Univ Koblenz, 2011.
http://kola.opus.hbz-nrw.de/volltexte/2012/733/pdf/Ringelstein_PhDThesis_2011.pdf
They also link to a few more….
WeST Steffen Staab 50
staab@uni-koblenz.de