BPPC with context-side/resource-side PEP
The generic authorization model with the characterized domains in chapter 3 can be used to map the BPPC's access control mechanism. The BPPC profile ensures that XDS document consumer actors can only access documents within the XDS registry that fulfill the requirements of the privacy consent appropriate to the use. Since all documents are marked in the XDS metadata according to their confidentiality code (OID of an affinity domain policy respectively a patient privacy consent), the acceptable use can be verified in two domains - either in the context domain or the resource domain. Mostly, the document consumer actors represent the obligated party to verify the eligible access. For instance, a cardiology system in a hospital shares medical information via federated healthcare networks. To put this into action, a context-side system must manage registered users of that organization. It makes no sense to federate all users with regard to the enormously effort of identity provisioning, thus a preliminary stage must be established to grant the access to systems of trusted organisations. This assorts well with the XSPA profile where the access control system of a health information system evaluate client-side attributes (purpose of use, actions, resouces and so forth) in conjunction with institution privacy policies.
When considering access control decisions in cross enterprise implementations, local access control systems interact with remote ones. This is where resource-side PEP comes into play. From a security point of view, the policy enforcement point should be close to the resource, and therefore the resource-side PEP embodies a more trustworthy access protection. However, it must be analyzed whether the provisioning of context information attributes or local access control decisions into the resource domain is the most suitable way to gain access to remote resources.
In order to activate a security access policy, a set of preliminaries must be executed. To this belong the assignment of functional roles, and the activation of the subject policy and patient policy. As described before, this can be done on the client side or context domain, but can be allocated to participating domains, too. An initial deployment, as shown in the following illustration, the access control system in the context domain activates all participating policies as the BPPC profile does.
Firstly, the activation of the patient policy could happen in a patient domain outside the context node as the following illustration depicts. The BPPC profile indeed captures the patient's acknowledgement within an CDA document using a HL7 consent structure, but the cross enterprise institution could be aware of committed privacy policy consents in any type that are located in their repositories. Furthermore, if no consent is available, a default policy as defined with the affinity domain policy is applied and thus reduces error handling in the context domain.
Secondly, the activation of the access policy could happen in a resource domain outside the context node. While this scenario provides more security because of the closest activation, the XDS document registry must be able to handle a lot of security stuff (e. g. required communication with the patient domain). This is contrary to the paradigm for separation of duties and leads to another deployment option.
Thirdly, the activation of the patient policy and access policy is encapsulated in an access control system located at the resource node. This option delegates the activation and policy provisioning into a trustworthy authority. The relying party get's rid of complex security processing. The XDS registry must only implement an access control interceptor with a policy decision and policy enforcement point.
A use case that reflects the last paragraph might be the access of medical records between two hospitals. Each hospital defines own EHR privacy consent policies for administrative data access, general medical data access, and sensitive medical data access. A patient has some diagnostics done in hospital A and consented the reports being stored in a medical record. The patient authorized only medical specialists of hospital A to it. Later, the patient goes to hospital B in order to make the same diagnostics to obtain a second opinion. Since hospital B has a healthcare enterprise contract with hospital A, a physician in hospital B queries adequate medical information from consolidated hospitals. The request to the healthcare domain in hospital A leads to a successful patient identity feed and reveals the existence of medical records. However, the access control system detects consented privacy policy and thus returns no access to the reports. As a result, the query does not return any medical data.