8.5 Design Guidelines
8.5.4 Security Guidelines
Table 8-7
General Security Guidelines
Name
Description
Reqt Map
Comments
WAN_Security_Transport Continua WAN service and client components shall support the TLS protocol v1.0 (RFC 2246) from WS-I BSP v1.0 for secure communication WAN_Interface_ Arch_Confidentia lity, WAN_Interface_ Arch_Integrity This guideline is consistent with the IHE ATNA profile when encryption is enabled Continua guidelines depend on the guidance in TLS v1.0 (RFC2246) for mutual authentication WAN_Security_Transport_
Cipher Continua WAN service and client components shall support AES cipher as specified in RFC 3268 WAN_Interface_ Arch_Confidentia lity, WAN_Interface_ Arch_Integrity
IHE ATNA requires the optional use of the following cipher suit: TLS_RSA_WITH_AES_1 28_CBC_SHA
Continua HRN guidelines uses the following cipher suite for security:
TLS_RSA_WITH_AES_1 28_CBC_SHA
Other cipher suites are allowed but would need to be negotiated between sender and receiver
WAN_Secure_Auditing Continua WAN service and client components may implement and adhere to IHE ATNA Auditing related clauses (Section 3.20, ITI- TF-2a)
WAN_Interface_ Data_origin_auth entication
Profiles referenced by IHE ATNA for auditing: The BSD (Berkeley Software Distribution) Syslog Protocol (RFC 3164);
Reliable Delivery for Syslog (RFC 3195); Security Audit and Access Accountability Message XML Data Definitions for
Healthcare Applications (RFC 3881)
Version 2013 Design Guidelines
Name
Description
Reqt Map
Comments
WAN_Security_Assertion Continua WAN service and client components shall support transfer of entity assertion information via SAML 2.0 token through WS-Security Header according to the Web Services Security: SAML Token Profile 1.1 WAN_Interface_ Security_Configu ration_Authorizat ion_Information_ Exchange
IHE Cross Enterprise User Assertion (XUA) profile uses the same mechanisms for the cross enterprise authentication of users The profile does not prohibit the use of other types of tokens (certificates) for an entity, providing that interoperability is being assured through some policy negotiation in an online or out of band fashion
Table 8-8
Consent Management Security Guidelines for Consent Enabled WAN Observation
Sender
NOTE: Other guidelines that are applicable for the Consent Enabled WAN Observation Sender and Receiver are mentioned in Table 8-2.
Name
Description
Reqt Map
Comments
WAN_Observation_Sender_
Consent Consent Enabled WAN Observation Sender shall comply with HL7 CDA R2 Consent Directive to represent patient consent in a consent document e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy WAN_Observation_Sender_
Consent_Transport Consent Enabled WAN Observation Sender shall implement the Document Source actor of IHE XDR to send a consent document using the ITI 41 Provide and Register Document Set-b transaction
e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy
Design Guidelines Version 2013
153 Modified on: August 6, 2013
Copying or other form of reproduction or redistribution of these works to unauthorized entities is strictly prohibited.
Name
Description
Reqt Map
Comments
WAN_Observation_Sender_
Consent_Frequency Consent Enabled WAN Observation Sender shall send the consent document at least once to the WAN Observation Receiver
e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy
The consent document is e.g., first sent during registration with the service
It is recommended to send consent at least once during the lifetime of connection to WAN observation receiver. Also supports the use cases such as updating consent preferences The updated consent document is a replacement of the existing consent document at the Consent Enabled WAN Observation Receiver WAN_Observation_Measur
ement_Consent_Document _Association
The consent document transmitted by the Consent Enabled WAN Observation Sender shall contain the same Patient Identifier as the WAN Observation measurement message(s)
e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy
This is to associate the consent document to the WAN Observation measurement messages
WAN_Observation_Measur ement_Consent_Document _Association_Value
The “Patient ID” field in the consent document header shall be set to the PID-3 value.
Subfields CX-1 and CX-4 shall be present and subfield CX-5 shall not be present
e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy
Table 8-9
Consent Management Security Guidelines for Consent Enabled WAN Observation
Receiver
Name
Description
Reqt Map
Comments
WAN_Observation_Receive
r_Consent Consent Enabled WAN Observation Receiver shall be able to receive, HL7 CDA R2 Consent Directive consent document(s) e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy
Version 2013 Design Guidelines
Name
Description
Reqt Map
Comments
WAN_Observation_Receive
r_Consent_Transport Consent Enabled WAN Observation Receiver shall implement the Document Recipient actor of IHE XDR to receive a consent document using the ITI 41 Provide and Register Document Set-b transaction
e2e_sec_azn_co nsent_policies, WAN_Interfaces_ Consent_Policy
The WAN Observation Receiver replaces the existing consent document if a new version was received as indicated by XDS metadata of the consent document
Table 8-10 WAN ID Mapping Guidelines
Name
Description
Reqt Map
Comments
WAN_ID_Mapping The WAN Observation Sender shall associate outgoing observations with a user identity that is meaningful to the WAN service at the WAN Observation Receiver The WAN Observation Sender may use user identity from PAN and/or LAN devices (if present) combined with device identifiers, as defined by System-Id (EUI-64) and if present the IEEE 11073- 20601 Person-Id to establish a user identity at the WAN service at the Observation Receiver for inclusion in message exchanges at the WAN Interface
The WAN Observation Sender may support alternative mapping strategies based on an out of band out-of-band information E2E_Arch_Excha nge, e2e_sec_azn_aut hn_entity2_users +operators, SEC_User_Identi fication, SEC_User_ID_Cr oss_Referencing
Table 8-11 Consent Enforcement Guidelines for Consent Enabled WAN Observation Sender
Name
Description
Reqt Map
Comments
WAN_Sender_Content_Enc
ryption_Actor Consent Enabled WAN Observation Sender shall encrypt the payload (6.5.3 Data Guidelines) of the PCD-01 transaction in compliance with the encryption processing rules defined in the Section 4.1 of the XML Encryption Specification e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement
Design Guidelines Version 2013
155 Modified on: August 6, 2013
Copying or other form of reproduction or redistribution of these works to unauthorized entities is strictly prohibited.
Name
Description
Reqt Map
Comments
WAN_Sender_Content_Enc
ryption_MIMEtype Consent Enabled WAN Observation Sender shall set the MIME type to “application/hl7-v2+xml” e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement The purpose is to indicate the type of the payload that is
encrypted
WAN_Sender_Content_Enc
ryption_Algorithm Consent Enabled WAN Observation Sender shall use AES-128 CBC as payload encryption algorithm from the XML Encryption Specification. e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement The AES-128 CBC algorithm is identified through the use of the following URL:
http://www.w3.org/20 01/04/xmlenc#aes128- cbc
WAN_Sender_Encryption_R
ecipient_Binding_PKI For the content key transport, Consent Enabled WAN Observation Sender shall support RSA Version 1.5 from the XML Encryption Specification e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement
The key transport based on RSA v1.5 is identified through the use of the following URL:
http://www.w3.org/20 01/04/xmlenc#rsa-1_5
For detailed
information about RSA v1.5, consult RFC 2437
http://www.ietf.org/rfc /rfc2437.txt
RSA v1.5 based key transport is also used in CMS (cryptographic message syntax) standard used on the HRN-IF. To know further consult RFC 3370 (http://www.ietf.org/rf c/rfc3370.txt) and the consent enforcement guidelines for the HRN- IF
WAN_Sender_Encryption_R ecipient_Binding_Symmetri c
For the content key transport, Consent Enabled WAN Observation Sender may use AES-128 symmetric key wrap algorithm from the XML Encryption Specification. In case of password based encryption, Consent Enabled WAN Observation Sender may use PBKDF2 as the key derivation algorithm from the RFC 3211
The URL used for AES- 128 symmetric key wrap is
“http://www.w3.org/20 01/04/xmlenc#kw- aes128”. The key used in wrapping is referred as KEK, which may be derived from a password or a long term shared secret key
Version 2013 Design Guidelines
Name
Description
Reqt Map
Comments
WAN_Sender_Integrity_Pa
yload_PCD-01_Create Consent Enabled WAN Observation Sender shall compute the digest of the encrypted payload using SHA256 (Section 5.7.2) algorithm according to the XML Encryption Specification e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement
The SHA256 algorithm is identified through the use of the following URL:
http://www.w3.org/20 01/04/xmlenc#sha256
.
WAN_Encrypted_Payload_P
CD-01_transaction Consent Enabled WAN Observation Sender shall wrap the encrypted payload inside the element
<CommunicateEncPCDData xmlns= “urn:ihe:continua:enc:pcd:d ec:2012”> e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement
In case of the un- encrypted payload the content is wrapped inside the element < CommunicatePCDData xmlns=”
urn:ihe:pcd:dec:2010” >. See the example in Figure K-1, Figure K-2, and Figure K-3 WAN_Encrypted_Payload_P
CD-01_Transaction_Header In case of the encrypted payload, the SOAP header shall contain “urn:ihe:continua:enc:pcd:d ec:2012:CommunicateEncP CDData” instead of “urn:ihe: pcd:dec:2010: CommunicatePCDData” e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement The plain PCD-01 transaction contains “urn:ihe: pcd:dec:2010:Commun icatePCDData”. See the examples in Figure K-1, Figure K-2, and Figure K-3
Table 8-12 Consent Enforcement Guidelines for Consent Enabled WAN Observation Receiver
Name
Description
Reqt Map
Comments
WAN_Receiver_HTTP_Ack Consent Enabled WAN Observation Receiver shall send the SOAP HTTP response with the status code equal to 202 after the successful reception of the encrypted message Consent Enabled WAN Observation Receiver should not send the PCD- 01 application level acknowledgement
The reason is that the WAN observation receiver may not be in the possession of the decryption key as the content may be encrypted for a specific recipient on the WAN Receiver
WAN_Receiver_Payload_PC
D-01_Verify_Integrity Consent Enabled WAN Observation Receiver shall verify the message digest of the encrypted payload
e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement
Design Guidelines Version 2013
157 Modified on: August 6, 2013
Copying or other form of reproduction or redistribution of these works to unauthorized entities is strictly prohibited.
Name
Description
Reqt Map
Comments
WAN_Receiver_Payload_PC D-
01_Verify_Integrity_Algorit hm
Consent Enabled WAN Observation Receiver shall support SHA256 algorithm
e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement WAN_ Receiver
_Content_Decryption_Actor Consent Enabled WAN Observation Receiver shall comply with decryption rules specified in the Section 4.2 of the XML Encryption Specification e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement WAN_Receiver_Key_Transp
ort_RSA Consent Enabled WAN Observation Receiver shall support RSA Version 1.5 from the XML Encryption Specification e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement WAN_Receiver_Key_Transp
ort_Symmetric Consent Enabled WAN Observation Receiver shall support AES-128 symmetric key wrap algorithm from the XML Encryption Specification
Consent Enabled WAN Observation Receiver shall support PBKDF2 as the key derivation algorithm from the RFC 3211
The URL used for AES- 128 symmetric key wrap is
“http://www.w3.org/20 01/04/xmlenc#kw- aes128”. The key used in wrapping is referred as KEK, which may be derived from a password or a long term shared secret key WAN_ Receiver
_Content_Decryption_Algor ithm
Consent Enabled WAN Observation Receiver shall use AES-128 CBC
decryption algorithm from the XML Encryption Specification e2e_sec_azn_enf orcement, e2e_sec_azn_dat a_confidentiality, e2e_sec_account ability_policy_enf orcement The AES-128 CBC algorithm is identified through the use of the following URL:
http://www.w3.org/20 01/04/xmlenc#aes128- cbc
Design Guidelines Version 2013
159 Modified on: August 6, 2013
Copying or other form of reproduction or redistribution of these works to unauthorized entities is strictly prohibited.