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 quite common use-cases may require an access management methodology, 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.

Through the combination of the particular advantages of both access control styles, the hybrid policy may address all of the diverse requirements in the clinical environment.

client-side vs. resource-side enforcement

A patient privacy policy is bound to a (medical) resource expressing what should be protected. The policy might be enforced either client-side or resource-side. Both the client-side policy enforcement and resource-side policy enforcement support various caching opportunities.

By implementing client-side enforcement, policy requests into the service domains become needless since the policy resides locally. This supports cases of emergency in order to immediately gain access to resources. Nevertheless, the patient data must be prefetched before.

Whether client-side or resource-side enforcement should be applied depends on the trustworthiness of the parameters sent from the client to the resource provider. The client application might send prefetched patient data or the policy decision outcome to the service provider. The resource-side access control system has to evaluate the trustworthiness of the rendered decision. It has no knowledge about the input data that led to the decision. Hence, a trusted party stating the correctness is necessary.

Since the policy is usually implemented as a RBAC-style policy, a subject attribute assignment is a necessary step before the policy decision is enforced. This implies the authentication as a previous step. The role assignment is typically encoded within an assertion being validated by the relying party (service provider). Client-side enforcement becomes useless, since the service provider could not process the assertion anymore. So resource-side enforcement should be preferred.

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.