WPAC The Role of the Patient

Patient Privacy Policies

In order to lawfully collect, store, process, and communicate medical information about a patient, a concrete and prior authorisation for those operations is required. This authorisation is also referred to as the patient consent. This consent is the result of a patient's independent and informed decision and is specifically defining:

• What of his medical data may be shared
• to what extent (partly, context-dependent, all)
• with whom (identities or organisations)
• for how long?

Finding a suitable technical representation of the patient's consent is considered to be quite challenging due to the potentially high complexity of an adequate reflection of the concrete patient's wishes. Furthermore, it must be adequately addressed, that the patient holds the right to withdraw his consent at any time, even during the treatment. One very potential solution to express the patient's consent - while fully respecting the variables such as immediate withdrawal, particular concerns, and automatic checks whether the consent is currently valid - may be policies. Policies in that matter are a structured collection of rules and regulations, which governs accesses to the patient's medical data and the related/dependent objects (applications, systems). Policies also facilitate certain clinical requirements, such as the application of one or more policies to one resource (policy stacks), the possibility of a conditional emergency override, and a situation-dependent choice of the concrete position of the policy enforcement point (as required in a federated health-care environment and for pre-fetching of medical data-sets). The specific rules and regulations, which are encoded in the policy, directly reflect all explicit and implicit authorisations that may result from the patient's decisions:

Example: "All internists of the department 123c of the hospital XY may access all relevant parts of my electronic case record xyz for either, the duration of the treatment or two years."

The policy traditionally originates in the patient domain, since a valid and active patient's consent is generally required in order to initiate the collection of his medical data.

DAC-style vs. RBAC-style PPPs

The PPP is usually implemented and operated as a RBAC-style policy by the access and identity management. This enables a flat, flexible, and rather universal definition of functional or administrative roles, which may be applied to every typical hospital to cover the majority of the clinical use cases. Therefore, RBAC-style is perfectly capable of covering the generic, daily operations at a health care provider in an effective and efficient way. However, some rather extraordinary use-cases may require an access management, which features the selective authorisation of specific health care professionals. While it is still possible to implement this functionality into RBAC-style policies, it may result in disproportional efforts and in a definitive loss of efficiency and maintainability. A better suited approach to overcome those limitations of the RBAC-style policies is a combination and subsequent composition of heterogeneous policies, which implement both, RBAC-style as well as DAC-style. In this case, the RBAC-style fraction is still featuring the role- and function-based means, while the DAC-style part authorises individual health care professionals with their specific and separate permissions.

Patient-bound Tokens (e. g. EHCs) as Access Control Measures

• Patient bound token are used to fulfill multiple tasks:
  • they provide information about the patient that can be used as patient attributes when defining policies or rendering policies into policy decisions, e.g. demographic data, participation in DMPs, ...
  • they are a common mean to complement traditional access control measures to empower the patient in a way that he has the final decision who is allowed to access his data, e.g. by containing consent information, representing a consent or by containing cryptographic keys that are used to protect medical data

• Example:
  • Electronic health cards (EHC), e.g. in Germany, containing the patients demographic data, consent information and cryptographic keys
  • Electronic cards, proving the participation in a certain DMP
  • ...

• Problem: As those token are patient bound they can not be accessed when the patient is absent. Access to applications or resources that depend on data that is only stored on these token is therefore not possible.