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.
- 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
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).
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.
- confidentialityCode - this is NOT a profile, but is a security/privacy concept built into almost all of the healthcare standards.
- Statement of the data security/privacy classification
- Would be used by access control decisions
- See: Data Classification - a key vector enabling rich Security and Privacy controls.
- HIE Security and Privacy through IHE- Revised 2008-08-22
- Access Control - Published 2009-09-28
- IT security problems continue (Designing a Secure HIE) This is where I explain that point-to-point security doesn't scale and that a walled-garden approach using TLS may be a better starting point. (Yes, this is an old article that still is true today. We see in NHIN Direct something closer to the unconstrained point-to-point, or end-to-end. The solution being discussed is to restrict NHIN Direct endpoints to 'organizations', thus ending up with a smaller map but still quite the spider web)
- Healthcare Access Controls standards landscape
This is part of a blog presentation of the IHE Privacy and Security Profiles Overview:
- Introduction to IHE impact on Meaningful Use
- IHE - Privacy and Security Profiles - Introduction
- IHE - Privacy and Security Profiles - Consistent Time
- IHE - Privacy and Security Profiles - Audit Trail and Node Authentication
- IHE - Privacy and Security Profiles - Enterprise User Authentication
- IHE - Privacy and Security Profiles - Cross-Enterprise User Assertion
- IHE - Privacy and Security Profiles - Document Digital Signature
- IHE - Privacy and Security Profiles - Basic Patient Privacy Consents
- IHE - Privacy and Security Profiles - Document Encryption
- This Page
- IHE - Privacy and Security Profiles - Miscellaneous
- IHE - Privacy and Security Profiles - Conclusion