Zx.3.5 | BB: IHE ITI-40 | Provide X-User Assertion

Scope

This transaction is used to add user attributes in the SOAP TTA transactions. The attributes are placed in a SAML-token in the security header of a, for example, ITI-75 transaction.

Use Case Roles

Referenced Standards

OASIS http://www.oasis-open.org/committees/security/
SAMLCore SAML V2.0 Core standard
WSS10 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.0 (WS-Security 2004)", March 2004.
WSS11 OASIS Standard, "OASIS Web Services Security: SOAP Message Security 1.1 (WS-Security 2004)", February 2006.
WSS:SAMLTokenProfile1.0 OASIS Standard, “Web Services Security: SAML Token Profile”, December 2004
WSS:SAMLTokenProfile1.1 OASIS Standard, “Web Services Security: SAML Token Profile 1.1”, February 2006
XSPA-SAMLv1.0 OASIS Standard, “Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of the Security Assertion Markup Language (SAML) for Healthcare v1.0” , November 2009
SAML 2.0 Profile For XACML 2.0 OASIS Standard, February 2005

Informative -- assist with understanding or implementing this transaction

IHE Profiles
- Personnel White Pages Profile
- Enterprise User Authentication Profile
- Basic Patient Privacy Consents Profile
OASIS
- SAML V2.0 Standards http://www.oasis-open.org/committees/security/ .
- SAML V2.0 Technical Overview
- SAML Executive Overview
- SAML Tutorial presentation by Eve Maler of Sun Microsystems
- SAML Specifications
- WS-Trust - OASIS Web Services Secure Exchange (WS-SX) TC
- XSPA-XACMLv1.0 OASIS Standard, “Cross-Enterprise Security and Privacy Authorization (XSPA) Profile of XACML v2.0 for Healthcare v1.0” , November 2009

Messages
Provide X-User Assertion

For more technical specification, see the original document: https://profiles.ihe.net/ITI/TF/Volume2/ITI-40.html

Twiin implementation

The SAML token is only required in the transactions between GtK (external traffic).

The SAML token is only valid for 10 minutes. The SAML token has the following attributes (in addition to the required attributes from the SAML-standard)

Element	Opt.	DataType
urn:oasis:names:tc:xspa:1.0:subject:subject-id	O	String
urn:oasis:names:tc:xspa:1.0:subject:organization	C	String
urn:oasis:names:tc:xspa:1.0:subject:organization-id	C	anyURI
urn:ihe:iti:xca:2010:homeCommunityId	O	anyURI
urn:oasis:names:tc:xspa:1.0:subject:npi	C	String / mag ook: HL7 V3 CE
urn:ihe:iti:xua:2017:subject:provider-identifier	C	HL7 V3 II
urn:oasis:names:tc:xacml:2.0:subject:role	R	HL7 V3 CE
urn:ihe:iti:bppc:2007:docidorurn:ihe:iti:xua:2012:acp	O
urn:oasis:names:tc:xacml:2.0:resource:resource-id	C	HL7 V3 II
urn:oasis:names:tc:xspa:1.0:subject:purposeofuse	R	HL7 V3 CV

Naam Raadplegende gebruiker	SubjectID
Name space:	urn:oasis:names:tc:xspa:1.0:subject:subject-id
Type:	String
Description:	The value on the Subject ID attribute shall be a plain text description of the user's name (not user ID). This SubjectID may be used for audit logging by the responding gateway
Example
Opt.:	Optional

Nationale Identifier Gebruiker	National ProviderIdentifier
Name space:	urn:oasis:names:tc:xspa:1.0:subject:npi
Type:	urn:hl7-org:v3:II
Description:	A National Provider Identifier (NPI) is a unique identifier issued to health care providers by their national authority: UZI-number
Example:	`extension="123456782" root="2.16.528.1.1007.3.1" assigningAuthorityName="CIBG"`
Opt.:	Optional

Identifier Gebruiker (Alternatief)	Other ProviderIdentifier Attribute
Name space:	urn:ihe:iti:xua:2017:subject:provider-identifier
Type:	urn:hl7-org:v3:II
Description:	A unique identifier issued to health care providers by a named authority. This attribute may be repeated.
Example:
Opt.:	Optional

Rol gebruiker

Subject-Role

Name space:

urn:oasis:names:tc:xacml:2.0:subject:role

Type:

urn:hl7-org:v3:CE

Description:

The role attribute shall contain one or more role codes from the identified Value-Set that represents the role that the XUA user is playing when making the request.

For a user one or more roles can be provided in the subject role attribute. As described in Vol. 2b - Section 3.40.4.2 - Additional section to add to all ATNA audit messages when the transaction includes XUA Assertion. The iDP is responsible for Subject-Role claim.

The HIE system shall be able to interpret or translate the roles coming from the Initiating Gateway. If no national standards are defined or implemented regarding the Subject-Role claim, a variation of roles can be expected.

To support the use case of exchanging medical information between one or more home communities, we define that the initiating HIE system shall be able to translate the Subject-Role claim to at least one of the roles as described in the table below.

Code	System	Description
01.000	RoleCodeNLUZIRoleCodePersonen	NL: Arts, US: Medical Doctor
56542007	Snomed CT	NL: Beheerder van medische dossiers, US: Medical record administrator

If a use case requires additional Subject-Role claims, the use and interpretation of these claims lie outside of the scope of this technical agreement.

Example:

Opt.:

Required

Naam Raadplegende organisatie	SubjectOrganizationName
Name space:	urn:oasis:names:tc:xspa:1.0:subject:organization
Type:	String
Description:	The value on Subject Organization attribute shall be a plain text description of the organization. This Subject Organization Name may be used for audit logging by the responding gateway. If no Subject Organization name is available, a Subject Organization ID shall be provided.
Opt.:	Conditional, required if urn:oasis:names:tc:xspa:1.0:subject:organization-id is empty

ID Raadplegende organisatie	SubjectOrganizationID
Name space:	urn:oasis:names:tc:xspa:1.0:subject:organization-id
Type:	AnyURI
Description:	A unique identifier for the organization that the user is representing in performing this Transaction. If no Subject Organization ID is available, a Subject Organization Name shall be provided. This field can be populated with more than one ID. The receiving party will process the values as intended. The Subject Organization ID attribute shall be the OID as listed in the HL7 Nederland OID register (https://hl7.nl/actuele-hl7-nl-oid-register.html). Otherwise, a Subject Organization ID shall be used that is traceable and verifiable in a publicly available register such as the AGB register. The Subject Organization ID attribute will eventually need to be populated with the URA number. This is also necessary to enable a transition to MITZ for consent management. Current implementations may continue to use the HL7 OID; however, a future patch of this Twiin Technical Agreement will mandate the use of the URA. The timeline and practical adjustments related to this patch will be coordinated with vendors before enforcement. Enforcement of this requirement will be necessary from the moment the first party intends to connect to MITZ. Transition period Until the national deployment of MITZ for both consent and localisation is operational, the following temporary agreement applies: The HL7 OID may be used as the primary value for the SubjectOrganizationID. Once the migration to MITZ is formally established and operational, the URA number will become the required identifier in a future version of this TTA. Twiin will provide and maintain an overview of participant identifiers (including HL7 OID and URA) to support correct identification during the transition period. Vendors are responsible for implementing and maintaining the mapping between HL7 OID and URA within their own systems. Supplying multiple identifiers (e.g. HL7 OID and URA) within the SubjectOrganizationID remains permitted during the transition period.
Example:	`<saml:Attribute Name="urn:oasis:names:tc:xspa:1.0:subject:organization-id"> <saml:AttributeValue>http://familymedicalclinic.org</saml:AttributeValue> </saml:Attribute>`
Opt.:	Conditional, required if urn:oasis:names:tc:xspa:1.0:subject:organization is empty

Home Community ID	Home CommunityID
Name space:	urn:ihe:iti:xca:2010:homeCommunityId
Type:	oid
Description:	The value shall be the Home Community ID (an Object Identifier) assigned to the Community that is initiating the request. The Home Community ID attribute shall be the OID of the home community as provided in the connection statement.
Example:
Opt.:	Optional

Consent	Authz-Consent
Name space:	urn:ihe:iti:bppc:2007:docidorurn:ihe:iti:xua:2012:acp
Type:
Description:	Conveys either the BPPC document relevant for this transaction context or it references the related Privacy Policy ID agreed upon between communities
Example:
Opt.:	Optional

Patiënt ID	Patient Identifier
Name space:	urn:oasis:names:tc:xacml:2.0:resource:resource-id
Type:
Description:	Shall be the patient’s BSN for which the transaction is executed. In cases where a BSN is provided it shall be provided as a HL7 CX Data Type (as defined in Vol. 2b - Section 3.40.4.1.2.2.1 Patient Identifier Attribute) with at a minimum the follow components specified: ID Number Assigning Authority
Example:	`l123456789^^^&2.16.840.1.113883.2.4.6.3&ISO`
Opt.:	Conditional; andatory if the transaction also contains a BSN number. In an ITI-39 or RAD-75, this is optional.

Reden

Purpose of use

Name space:

urn:oasis:names:tc:xspa:1.0:subject:purposeofuse

Type:

urn:hl7-org:v3#CV

Description:

The purpose of use claim is option but if used it shall indicate the intended purposed of the entity that initiated a request, using one of the following codes

The PurposeOfUse element shall contain the coded representation of the Purpose for Use that is in effect for the request. The X-ServiceProvider may use the PurposeOfUse value in Access Control decisions. In case no PurposeOfUse element is present inthe transactions; the custodian of the medical record can apply its local policies.

Code	System	Description
1	ISO 14265	Clinical care provision to an individual subject of care
2	ISO 14265	Emergency care provision to an individual subject of care

It is the responsibility of the initiating and responding XCA gateways to map these purpose of use codes to purpose of use codes used within their community and apply, if required, the necessary access control policies.

If a use case requires additional purpose of use codes, the use and interpretation of these codes lie outside of the scope of this technical agreement.

Example:

Opt.:

Optional

Signing

The SAMLtoken must be signed with the private key of the Identity Provider (service) of the initiating organization. The corresponding public keys must be exchanged in advance between the communicating organizations so that, upon receipt of the SAML token, the receiving organization can verify the signature. This is a mandatory requirement under the NEN7512.

In the near future the cryptographic key shall be issued by a qualified trust service provider and shall meet the requirements of the eIDAS assurance level High, in accordance with the NEN7518. Identities of healthcare workers should be issued by the DEZI-register at the latest the 1^st of November 2028.

The use of eIDAS assurance level High–compliant identification means is already a statutory requirement arising from the Besluit elektronische gegevensverwerking door zorgaanbieders, which mandates compliance with NEN 7512.

Re-signing of the XUA token (preferred)

HIE vendors of the systems that act as the initiating gateway actor may modify a SAML token, and shall re-sign this token if modified.

Re-signing a XUA token may be done to achieve operational efficiencies and network scalability. In case this is done, the Initiating Gateway actor is responsible for re-signing the XUA token that was created by any of the trusted identity providers within the home community. The consequence of re-signing the XUA token is that the Responding Gateways trusts all identities of the initiating community based on the re-signing authority.

In this case:

HIE vendors of the systems that acts as the initiating gateway actor shall provide one identity provider certificate and URI and provide the required details in their connection document

HIE vendors of the system that acts as the responding gateway actor shall configure the responding gateway to trust this identity provider

Forwarding the claim of the original identity provider

An HIE vendor can choose to forward a claim from the initiating gateway without modifications or re-signing of the claim. This however creates the need for the responding gateway to trust all identity providers that reside within the home communities the initiating gateway represents. In this case it is agreed that:

HIE vendors of the system that acts as the initiating gateway actor shall provide all identity provider certificates and URI details in their connection document
HIE vendors of the initiating gateway shall not change any of the claims made by the original identity provider
HIE vendors of the system that acts as the responding gateway actor shall configure the responding gateway to trust all provided identity providers