WPAC The Role of the Patient

IHE White Paper on Access Control

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.

Opt-Out Considered Harmful

Note: This section was moved in here from one of the introductionary chapters. It has to be clearified and discussed in more detail

A use case that is often stated as an access control scenario is a patient consent where access to medical data is explicitly forbidden for a certain person (e. g. the patient's neighbor). A pointed out in the discussion on the needs-to-know principle this use case should not be handled by technical access prtection means but rather by organizational means (e. g. by not assigning this person the team that treats the patient). E. g. a situation where a patient requests cardiologic treatment by a hospital and the only cardiologist available is just the person the patient did not allow to access his data leads to a problem with the hospitals organization of labour that cannot be solved by technical means.

Client-side vs. Resource-side Enforcement

• client-side
  • when medical data is prefetched
  • when policies and the majority of relevant attributes reside locally
  • emergency overrides

• resource-side
  • when policies and the majority of relevant attributes reside in the resource or application domain
  • higher security level

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.