Name: Cross-Enterprise User Assertion (IHE XUA)
Identifier: IHE XUA
Issuing Organisation: Integrating the Healthcare Enterprise (IHE)
Organization website (opens in new window): https://www.ihe.net/
Link to standard (opens in new window): https://wiki.ihe.net/index.php/Cross-Enterprise_User_Assertion
Availability: Free to Access
Type: IHE Profile
Issue Year: unknown
Forward Review Date: Not known
Intended Audiences: Private Sector Bodies, Professional and Trade Bodies, and Governmental and Public Sector Bodies
Cross-Enterprise User Assertion Profile (XUA) – provides a means to communicate claims about the identity of an authenticated principal (user, application, system…) in transactions that cross enterprise boundaries. To provide accountability in these cross-enterprise transactions there is a need to identify the requesting principal in a way that enables the receiver to make access decisions and generate the proper audit entries. The XUA Profile supports enterprises that have chosen to have their own user directory with their own unique method of authenticating the users, as well as others that may have chosen to use a third party to perform the authentication. The XUA profile carries a readable and verifiable claim of the user identity, authentication method, and as needed their roles, purpose of use, and consent.
Benefits: Assistance to sites in implementing security and confidentiality policies There are transactions defined by IHE that cross enterprise boundaries and are web-services based on ITI TF-2:Appendix V. The existing IHE profiles for an authenticated user identity (IHE Enterprise User Authentication Profile [EUA]) are not intended to function in cross-enterprise transactions. In a cross-enterprise environment it is more likely that the transactions will be going between two enterprises that maintain their own independent user directories (IHE Personnel White Pages [PWP]). This type of requirement is the focus of the Identity Federation standards. Identity Federation has received much attention by the security and the platforms industry. Identity Federation is agnostic to the type of user directory; it allows for a centralized user directory, but also supports the more powerful federation of user directories.
Details: The vast majority of the use-cases rely on claims about an authenticated identity, which a SAML 2.0 Identity Assertion can provide. This is a mature standard produced by OASIS. XUA Profile is focused on Web-Services transactions that follow ITI TF-2:Appendix V. XUA specifies that when a Cross-Enterprise User Assertion is needed, these Web-Services transactions will additionally use the Web-Services Security header with a SAML 2.0 Token containing the identity Assertion. As with any IHE profile, the applications are not forbidden to use other methods of providing the principal (user) identity, providing that interoperability has been assured through some policy.
A very clear need on all the use-cases is the recording of the user identity in any security audit logs. The XUA profile does not define these auditable events. The need to record a security audit event is driven by the grouped transactions (e.g., XDS.b Registry Stored Query, and XDS.b Retrieve Document Set). XUA does specify how to reference the Identity Assertion in an ATNA Audit Message.
The method of authenticating the principal (user) and the method that the X-Service User Actor (e.g. XDS.b Document Consumer) uses to get the Identity Assertion are outside the scope of this profile. There are principal (user) attributes that appear to be needed in the use-cases: Doctor, Patient, Guardian, Emergency-Access. The Identity Assertion can contain attributes about the principal (user). At this time it is not clear what standards to use to identify these attributes and their values, so this is left to specific implementations that have defined a local vocabulary or vocabulary translation.
The method used by the X-Service User (e.g. XDS.b Document Consumer) Actor to determine the contents of the Identity Assertion is outside the scope of this profile. This might be accomplished using the SAML Metadata and WS-Policy. It is expected that extending this solution to HL7 and DICOM will be supported in the future.
Relevance to Active and Healthy Ageing: Medium
Older Person Specific: No
Usage / Adoption status: IHE Profile endorsed by European Commission for Public Procurement
This IHE Profile is an essential building block in establishing interoperable digital tools in support of healthcare, thereby supporting seamless integrated healthcare for all generations incl. the elderly. This IHE Profile is mentioned in COMMISSION DECISION (EU) 2015/1302 of 28 July 2015 on the identification of ‘Integrating the Healthcare Enterprise’ profiles for referencing in public procurement (see Official Journal of the European Union, L199/43): (7) On 2 October 2014, the European multi-stakeholder platform on ICT standardisation evaluated 27 ‘Integrating the Healthcare Enterprise’ (IHE) profiles against the requirements set out in Annex II to Regulation (EU) No 1025/2012 and gave a positive advice to their identification for referencing in public procurement. The evaluation of the 27 IHE profiles was subsequently submitted to consultation of the eHealth network established by Article 14 of Directive 2011/24/EU of the European Parliament and of the Council (2) that confirmed the positive advice to their identification. (8) IHE develops ICT technical specifications in the field of healthcare information technology. The 27 IHE profiles are detailed specifications developed over a period of 15 years within the committees of IHE that optimise the selection of well-established standards describing the different layers of interoperability (i.e. protocol communication, technical, syntactical, semantic and application levels) with a view to find interoperability solutions for exchanging or sharing medical data. (9) The 27 IHE profiles have the potential to increase interoperability of eHealth services and applications to the benefit of patients and medical community. The 27 IHE profiles should therefore be identified as ICT technical specifications eligible for referencing in public procurement.
We are sorry that this content was not useful for you!
Let us improve this content!
Tell us how we can improve this content?