Wednesday, August 10, 2011

IHE - Privacy and Security Profiles - Access Controls leveraging the Security/Privacy Profiles

Access Controls utilize Interoperability profiles but are implemented functionally. This is why one does not find an Access Control profile from IHE. It is not because it is not important, but rather the solution is functional code that leverages the security and privacy context information provided to it by existing Interoperabilty Profiles. IHE does provide a very comprehensive white paper on the topic of Access Controls and how they can be implemented.

Access Controls in environments like XDS and XCA would be federated, that is there would be multiple places where access is controlled that are distributed throughout the environment, and each leverages information from others and from trusted third parties. Access Controls use information from the 'security context', that is the context of the transaction. This context is also federated, not necessarily always centralized. Things in the security context are the user identity, their roles, the patient identity, the consents on file, metadata about the resource that is being accessed, and the reason for the access.
This diagram shows this security context broken down into three possible domains and maps how to get these security context values using IHE profiles. There is a circle of trust, federation, between these different domains of context.
  • Context Domain - information about the requesting environment 
  • Subject Domain - the user identity, roles, and purpose of the request 
  • Resource Domain - the 'thing' that is being requested and which patient it is about 
An important part of Access Control is to determine who has access to what kind of resources. This is often shown in a 'truth table'. There can be multiple of these tables, where the table that is used could be controlled by the consent that is acknowledged.

This table shows a Role-Based-Access-Control map that might represent what is allowed if the patient has chosen an OPT-IN Patient Privacy Policy. The Rows are made up of example “Functional Roles”, these are roles that any user could be assigned to based on their job classification. The Columns are examples of “Sensitivity” classifications, and the HL7 confidentialityCode is shown that might be used for each. In the table an X indicates that the specific Role would have access to the kind of data classified with that Sensitivity or confidentialityCode.

This is the same table as before, except this one shows what the table might look like if the Patient has chosen an OPT-OUT. In this case the table has an additional Permission that if a user holds this permission they are allowed to “break-glass” and if they do that then access would be allowed. This allowance for break-glass is common where patient safety is a concern (e.g Life and Limb is at risk).
Note that there are far fewer X marks, indicating that only the Direct Care Provider is allowed access.

This slide shows that IHE has not constrained where Access Controls are enforced, and have enabled that Access Controls can be enforced in many places.

A) This is the classic Access Control where the Requesting System (e.g. the system implementing the XDS Document Consumer) enforces all Access Controls. In this example the XDS Registry is only assuring that it is communicating with a system that it explicitly trusts (using ATNA Secure Communications). This assure that the XDS Registry is not accessed by rogue systems, but is only system level Authentication. This model is the most simple to build, especially if it is leveraging the Access Controls that might already be available in the Requesting System (e.g. EHR).

B) In this figure the Responding System (e.g XDS Registry) is enforcing the Access Controls. This is enabled by including the XUA identity assertion. This model can gain through having the Access Controls implemented in one place, thus saving on complexity and assuring consistency. This model however suffers in that it is much harder to handle use-cases where the context at the client is complex. Such as when there is a case that would normally be denied, but under emergency-mode would be authorized (i.e., Break-Glass).
C) The third figure is a more balanced environment. Where gross access controls are enforced at the Responding System (e.g. XDS Registry), and more fine-grained controls are enforced at the Requesting system (e.g. XDS Document Consumer)

It is often not recognized that in Healthcare, especially in cross-organizational transactions that the data communicated will be copied for future use. Thus what ever data is returned to the Requesting system (e.g. XDS Document Consumer) will likely be copied and thus future access control decisions to that copy are in the control of the Requesting system. Thus there is really an important consideration that the Requesting System have robust access controls.

Access Controls can actually take place in a trusted intermediary that is not a component of the Requesting or Responding system. This is a much more difficult system to deploy.

Additional Comments

Back links
This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:

No comments:

Post a Comment