Synchronous Transport Client module

Transcription

1 HIS Interoperability Framework Transport Layer Synchronous Transport Client module Document Identification Reference HIS-IF-Transport_Layer-Synchronous_Client_Module_v1.0.2 Date Created 06/03/2009 Date Modified 05/11/2010 Author ASIP Santé-PRAS Version V Page count 42 Reference Documents [1] IHE International : IT Infrastructure Technical Framework, volumes 1 et 2 [2] IHE International : Cross-Enterprise User Assertion Profile Attribute Extension (XUA++) [3] IHE France : Constraints on HL7 v2.5 data types that apply to the IHE IT Infrastructure Technical Framework within the scope of IHE France v1.2 of October [4] ASIP Santé : HIS Interoperability Framework Cross-functional appendix of data sources for professionals and organizations Classification : public 1 / 41

2 Document Change History Version Date Change /06/2009 Initial publication for public review /09/ /09/2009 Inclusion of comments received on 31/08/2009. Published at the beginning of the industry stakeholders session on September 14th and 15th for validation Updated post expert session on September 14 and Addition of a VIHF token example, and SAML attribute supplements /10/2009 Publication post approval by industry stakeholders /02/2010 Published without changes as part of version of the HIS-IF /09/ /09/ /11/2010 Identification and Authentication content update to take into account the lessons learned from the DMP project. Additional changes based on July 2010 version of IHE XUA++ Specification of authentication modes Addition of the "AuthnInstant" attribute Use of Coordinated Universal Time (UTC) to express date and time. Addition of references to cross-functional appendix specifying data sources for professionals and organizations /11/2010 Published without changes as part of version of the HIS-IF 23/11/ /12/ /03/ /03/2011 4/05/11 Erratum 1 23/11/10: Document updated to conform with RFC 2253 Erratum 2 14/12/10: Correction to the OID de for the G15 nomenclature in two examples from page 31 and on page page 26 Correction of the attribute name in the updated Correction of the & character string to the & symbol in INS example when it does not appear as part of an XML message example. Correction of the sample RPPS independent practice identifier to be 15 characters in Classification : Public 2/41

3 Table of Contents 1 Positioning within the Interoperability Framework Pre-requisites Specification References SOAP Messages Structure of a SOAP message with WS-Addressing SOAP Style and Message Encoding SOAP Message Exchange Types Transport or protocol binding (HTTP 1.1 over TLS) Document Transport using MTOM and XOP Description of a Web Service (WSDL) Security Features Confidentiality Integrity Identification and Authentication VIHF Technical Requirements for Initiating Systems Access Control Elements of the VIHF specific to the Target System Appendix 1 : Future Iterations Classification : Public 3/41

4 1 Positioning within the Interoperability Framework This module specifies the Transport layer for: A target system that exposes a service that can be connected to synchronously; An initiating system that has client software that integrates the interfaces from this module, and that connects to the service synchronously. In other words, this module specifies a software client rather than a thin client or a browser based client. Figure 1 : System Roles This module is used by the document sharing module. Please Note: The specifics of how to implement the standards presented in this module will be validated and delved into in the HIS implementation projects such as the DMP V1. The solutions that remain to be validated will be the focus of test implementations. This is particularly sensitive for the Independent Healthcare Professional configuration. The technical limitations of the CPS smartcard implementation require certain decisions to be made in order to balance security and performance. 2 Pre-requisites In order to conform with this module, initiating and target systems will need to be able to use the root certificates from the CPS-Public Key Infrastructure (PKI), regardless of whether the CPS-PKI is associated with a person (E.g.: Individual and Identifying CPS smartcard) or a legal entity (E.g.: server certificate). Classification : Public 4/41

5 3 Specification 3.1 References The protocol selections for this module are outlined below. They are based on appendix V of the IHE ITI Technical Framework Volume 2, and the XUA Integration profile: The exchanges are performed using the http 1.1 protocol, encapsulated over a secured TLS connection. SOAP 1.2 is used in order to specify the format of a message, the information in the message that allows it to be delivered across the internet, as well as the expected treatment of the message. The document transport flows use the additional encoding and SOAP transmission optimizations defined in MTOM and XOP. The services exposed by the health information systems must be described in a language that can be understood by any other system, I.e.: the WSDL 1.1 standard. Finally, the flows must contain a SAML 2.0 assertion to integrate the authenticating information for the user defined in the X509 certificate that is used by the system. The use of the SAML assertion must respect the WS-I Basic Security Profile 1.1 standard, specifically the WS-Security SAML Token Profile 1.1 recommendations that relate to the content of the assertion and the way it is used in conjunction with WS-Security. http 1.1 : TLS 1.0 : SOAP 1.2 :] MTOM : XOP : Classification : Public 5/41

6 WSDL 1.1 : SAML 2.0 : Certificate X509 : WS-I Basic Security Profile 1.1 : WS-Security SAML Token Profile 1.1 : SOAP Messages Structure of a SOAP message with WS-Addressing The SOAP protocol defines an XML syntax for describing the format and structure of the message that is exchanged. The following paragraph specifies the principal elements of a SOAP message. The SOAP message must be composed of an Envelope which will contain both a Header and Body element. Example of the structure of a SOAP envelope: <env:envelope xmlns:env=" > <env:header>.. </env:header> -<env:body>. - </env:body > <env:envelope> The key word Envelope must be followed by a namespace which indicates the SOAP protocol version in use, and also an encodingstyle attribute which specifies the message encoding rules. In SOAP version 1.2, the xmlns:env attribute represents the namespaces keyword that is associated with the "env" prefix that defines the envelope. The " string designates the SOAP protocol version that is used, i.e.: SOAP1.2. The Header element of the message is optional, and contains the technical elements of the message which are called entries. The entries are intended to be processed by both the intermediary and final nodes. Classification : Public 6/41

7 The header extends the SOAP message specifications to other specifications that manage technical functionality such as address management, security management, whether the receiving node must process the message, etc. The header therefore contains one or more elements, each of which is composed of a namespace and two attributes reserved for the SOAP1.2 specification: The role attribute which designates the destination of the header element. If the role attribute is left out, the destination corresponds to the final node, i.e.: the web-service endpoint of the target system. The mustunderstand attribute indicates whether the header element must be processed by the destination. This processing is mandatory if mustunderstand = "true". For the French Health Information Systems: The Header element is required for the SOAP message; Since there are no intermediary nodes planned between the initiating and target systems, the role attribute is not used in the SOAP message; The mustunderstand attribute is set to "true" which means that the message is addressed to the final node, and must be processed by that node. The final node's services are defined in the HIS-IF's service layer. It is possible to extend the SOAP protocol by adding technical elements to the message header. Most notably, it is possible to add a WS-Addressing entry which indicates the message destination by using the <To> element, the message identifier element <MessageID>, the action to be carried out <Action> and the address to which the responding message must be sent <ReplyTo>. Classification : Public 7/41

8 Sample SOAP Header with a WS-Addressing entry for a Document Sharing service transaction. <env:envelope xmlns:env=" xmlns:a=" - <env:header> <a:action env:mustunderstand="true">urn:ihe:iti:2007:provideandregisterdocumentset-b</a:action> <a:messageid>urn:uuid:6d296e90-e5dc-43d0-b455-7c1f3eb35d83</a:messageid> - <a:replyto env :mustunderstand="true"> <a:address> </a:replyto> <a:to> </env:header> -<env:body>. - </env:body> <env:envelope> For the French Health Information Systems, the SOAP1.2 protocol is extended by the WS-Addressing specification. The message must have the following characteristics: The <Action>, <To>, <MessageID> and <ReplyTo> elements must be present; The <Action> element must contain the attribute mustunderstand set to "true"; For the initiating message, the <ReplyTo> element must contain the mustunderstand attribute set to "true". The Body element is required and comes immediately after the Header element. It is produced by the sender and must be consumed by the final destination. The Body element contains a group of elements, each of which is composed of a namespace and attributes which contain application specific data. The body of the message may also contain a Fault element, which allows any processing errors to be sent back to the sending system, by the destination system. Figure 2 shows a SOAP message for the French HIS Interoperability Framework. The optional elements are indicated by the dotted lines. The SOAP specification allows the use of multiple XML vocabularies, i.e.: namespaces. It defines a namespace for encoding SOAP1.2 message elements and attributes and allows the use of application specific namespaces. All namespaces must be declared in the SOAP envelope. Classification : Public 8/41

9 Figure 2 : SOAP message structure for the French HIS Interoperability Framework The following table lists the namespaces that must be used for the French Health Information System. soap12 Wsaw Xsd Xsi Ihe Rs Lcm Query HL7 V urn:ihe:iti:xds-b:2007 urn:oasis:names:tc:ebxml-regrep:xds:rs:3.0 urn:oasis:names:tc:ebxml-regrep:xds:lcm:3.0 urn:oasis:names:tc:ebxml-regrep:xds:query:3.0 urn:hl7-org:v SOAP Style and Message Encoding SOAP defines the encoding of the data elements manipulated by the messages and encoding/decoding rules, or serialization/de-serialization, of the data elements by the sending/receiving applications. This encoding and the associated encoding/decoding rules are called the encoding style. The encoding style is carried by the encodingstyle attribute that may appear: Classification : Public 9/41

10 In the header of the message; In a child element of the message. The scope of the encoding style is limited to the element itself or its child elements. Aside from the encoding of the data that makes up the SOAP message, the encoding of the documents transported by the message must also be considered. SOAP suggests two encoding styles: Literal Encoding: With literal encoding, there is no specific encoding applied to the message. The content of the message that is transported is an XML document. The document is manipulated as is by the applications that exchange the SOAP messages. This encoding style is also referred to as "document/literal" encoding. SOAP Encoding: With SOAP encoding, the encoding style is explicitly called out by the encodingstyle element and defines the relationship between the representation of the data handled by the application, and the data handled by the SOAP message. This is called RPC encoding, which is short for Remote Procedure Call encoding. In the case where the content was encoded as per the SOAP encoding rules, the encodingstyle attribute will be " If the value for the encodingstyle element is absent, this indicates that there is no SOAP encoding. For the French Health Information Systems, literal encoding must be used. The encodingstyle element is left out of the SOAP message SOAP Message Exchange Types SOAP defines two types of exchange between a SOAP sender and a SOAP receiver: Unidirectional message transmission, Request/Response type message transmission. In unidirectional message transmission, the SOAP message is transmitted from the sender to the receiver, and the sender does not wait for a response from the receiver. In Request/Response type message transmission, the query message is followed by a responding retrieve message. This type of exchange applies to both messages using the explicit encoding style as well as messages using implicit encoding. For the French Health Information Systems, the exchange request/response must be used Transport or protocol binding (HTTP 1.1 over TLS) SOAP messages can be exchanged over different protocols. The way that a message is transferred from one node to another using a specific protocol is called "protocol binding". For the French Health Information Systems, the HTTP1.1 protocol encapsulated over secure TLS must be used. Classification : Public 10/41

11 An HTTP message is either a client request or a server response. The HTTP 1.1 request message is composed of: A request row that contains the method used (POST) as well as the destination URL; An optional header field of the type <<header:value>>; An empty Row An optional MIME message body, depending on the type of encoding described in the Content- Type and Content-Encoding fields. Example of an HTTP request/response for a Document Sharing Service transaction POST <! Intentionally not specified--> HTTP/1.1 Content-Type: multipart/related; boundary=mimeboundaryurn_uuid_806d8fd2d542edcc2c ; type="application/xop+xml"; start="0.urn:uuid:806d8fd2d542edcc2c @example.org"; start-info="application/soap+xml"; action="urn:ihe:iti:2007:provideandregisterdocumentset-b" User-Agent: <! Intentionally not specified--> Host: localhost: MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C Content-Type: application/xop+xml; charset=utf-8; type="application/soap+xml" Content-Transfer-Encoding: binary Content-ID: <0.urn:uuid:806D8FD2D542EDCC2C @example.org> <?xml version='1.0' encoding='utf-8'?> <env:envelope xmlns:env= xmlns:wsa=" <env:header> </env:header> <env:body> </env:body> </env:envelope> --MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C Content-Type: text/plain Content-Transfer-Encoding: binary Content-ID: <1.urn:uuid:806D8FD2D542EDCC2C @example.org> <! Binary encoded document goes here -->.. --MIMEBoundaryurn_uuid_806D8FD2D542EDCC2C Classification : Public 11/41

12 The HTTP 1.1 response message is composed of: A status line that contains the HTTP version in use, a digital response code, and a text description of the status; Optional header fields of type <<field:value>>; An empty row; An optional MIME message body, depending on the type of encoding described in the Content- Type and Content-Encoding fields. Example of an HTTP Response Message for a Document Sharing Service transaction HTTP/ OK Server: <! Intentionally not specified-->/1.1 Content-Type: application/soap+xml; action="urn:ihe:iti:2007:provideandregisterdocumentsetbresponse";charset=utf-8 Date: Thu, 03 Jan :01:37 GMT <?xml version='1.0' encoding='utf-8'?> <env:envelope xmlns:env= xmlns:wsa=" <env:header>.. </env:header> <env:body> <rs:registryresponse xmlns:rs="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" status="urn:oasis:names:tc:ebxml-regrep:responsestatustype:success"/> </env:body> </env:envelope> For the French Health Information Systems, document transport must use the HTTP1.1 POST method Document Transport using MTOM and XOP The MTOM specification, which stands for SOAP Message Transmission Optimization Mechanism describes an abstract optimization mechanism for encoding and transmitting SOAP messages. MTOM enables optimized encoding of base64 SOAP messages. The XOP protocol, which stands for XML-binary Optimized Packaging, is a concrete implementation of MTOM to encode the SOAP envelope in an optimized way, using the XOP format and MIME Multipart/Related packaging. The base64 elements are extracted from the XML infoset, re-encoded in binary, and packaged in MIME Multipart/Related packaging. Classification : Public 12/41

13 The following example describes the SOAP envelope without encoding or document transport optimization. Example of MTOM use in a Document Sharing Service transaction MIME-Version: 1.0 Content-Type: type=text/xml Content-Description: XDS.b example using MTOM <?xml version='1.0'?> <env:envelope xmlns:env=" <env:body> <! Description of metadata-->... <ExtrinsicObject id="mydocument" />... <Document id="mydocument">base64 encoded document content </Document>... </env:body> </env:envelope> The SOAP envelope contains a <Document> element that contains the document encoded in base64. This mode of encoding is adapted to smaller documents. Classification : Public 13/41

14 The following example describes the structure of a serialized SOAP envelope using an XOP package. Example MTOM/XOP use for a Document Sharing Service transaction MIME-Version: 1.0 Content-Type: Multipart/Related; boundary=mime_boundary; type="application/xop+xml"; start="<mymessage.xml@example.org>" start-info="application/soap+xml;action="urn:ihe:iti:2007:provideand RegisterDocumentSet-b" Content-Description: example MTOM/XOP --MIME_boundary Content-Type: application/xop+xml; charset=utf-8; type="application/soap+xml;action="urn:ihe:iti:2007:provideandregisterdocumentset-b" Content-Transfer-Encoding: 8bit Content-ID: mymessage.xml@example.org <?xml version='1.0'?> <env:envelope xmlns:env=" xmlns :xmlmime=" <env:body> <! Description of metadata -->... <ExtrinsicObject id="mydocument" />... <Document xmlmime:content"type=text/xml" id="mydocument"> <xop:include xmlns:xop= href="cid:1.urn:uuid:bc47538ed684e0a2d @example.org"/> </Document>... </env:body> </env:envelope> --MIME_boundary Content-Type: text/xml Content-Transfer-Encoding: binary Content-ID: cid:1.urn:uuid:bc47538ed684e0a2d @example.org // Binary encoded document goes here --MIME_boundary Classification : Public 14/41

15 The <ExtrinsicObject> and <Document> elements in the metadata both have the same attribute id value. The <Document> element has a child element <Include> that references the identifier for the MIME section that contains the binary encoded document. This encoding mode is adapted to large documents. For the French Health Information Systems, the encoding and document transfer must be optimized using the MTOM/XOP protocol. The business transaction, which consists of the document and its attributes defined according to the service in use, is implemented at the application level. The transaction is transmitted to the message infrastructure layer which assembles the SOAP message according to the rules defined by the web service description. For more details on how a web service is described, see the Web Service Description, or WSDL section below Description of a Web Service (WSDL) WSDL1.1 is a specification which uses an XML file to describe the interfaces and methods of interaction with a web service. WSDL specifies not just the abstract interface, but also the types of data used, the message format, the encoding conventions and the transport protocols used. The WSDL specification describes a service as a collection of ports that exchange messages. Classification : Public 15/41

16 Figure 3 : Structure of a WSDL file A WSDL document can be represented as a schema as follows: 1. The first block defines the data types that will be used in the messages. The XML schema specification is usually used to define the data types. 2. The second block defines the abstract method for exchanging messages between nodes. A message is an instance of communication between the client and the service provider in the case of a request, or the service provider and the client in the case of a response. These messages are associated with their logical components that correspond to the information carried over the message. These logical components are described in the <part> tags of the XML message. 3. The third block defines the types of port and operations associated with that port. A port type is a collection of abstract operations. For each abstract operation, the messages used in the operation are specified. The messages usually consist of a request and response message which are eventually associated with several error messages. 4. The fourth block defines the links between the operations defined in a port type and the transport protocols and message formats that will manage the exchanges. 5. The final block defines the service. A service contains one or more ports. A port is an endpoint that is uniquely identified by the combination of a URI and a link. Each port associates a service endpoint with a binding. Classification : Public 16/41

17 A WSDL document can therefore be separated into three parts: A definition of the data types used in the first block; An abstract definition of the operations that make up the second <message> </message> block and third <porttype> </porttype> block; A description of the concrete service implementation that make up the fourth <binding>...</binding> block, and the fifth <service>...</service> block. The two first parts comprise the abstract interface. An abstract interface defines the group of operations and messages that can be sent to and from a given web service. The abstract interface defines these operations and messages abstractly and independent of language without any reference to the technology used to enable a Web service to transmit messages by separating this information, the integrity of the service description can be preserved regardless of what changes might occur to the underlying platform. The third part defines the concrete implementation of messages. This separation allows an abstract definition to be used for several concrete implementations. Each service interface is associated with an abstract WSDL port type: A porttype regroups a collection of abstract operations: Example of a document sharing service transaction <porttype name="documentrepository_porttype"> <operation name="documentrepository_provideandregisterdocumentset-b">. </operation> <operation name="documentrepository_retrievedocumentset">. </operation> </porttype> For each operation, the request and response messages are defined at the beginning and end of the operation: Example of a document sharing service transaction <porttype name="documentrepository_porttype"> <operation name="documentrepository_provideandregisterdocumentset-b"> <input message="ihe:provideandregisterdocumentset-b_message" wsaw:action="urn:ihe:iti:2007:provideandregisterdocumentset-b"/> <output message="ihe:provideandregisterdocumentset-bresponse_message" wsaw:action="urn:ihe:iti:2007:provideandregisterdocumentset-bresponse"/> </operation> </porttype> Classification : Public 17/41

18 For each message used in an operation, a <message> element is defined. This element references a request or response protocol that conforms to the XML interface schema used by the target system: Example of a document sharing service transaction <message name="provideandregisterdocumentset-b_message"> <documentation>provide and Register Document Set</documentation> <part name="body" element="ihe:provideandregisterdocumentsetrequest"/> </message> <message name="provideandregisterdocumentset-bresponse_message"> <documentation>provide And Register Document Set Response</documentation> <part name="body" element="rs:registryresponse"/> </message> Each PortType is the object of a concrete implementation using a message and a transport protocol; The literal encoding style is required for the entry and exit parameters of each operation; For document transport, the document encoding style identifies that the SOAP request/response messages are treated as an XML document and not as an RPC Call: Example of a document sharing service transaction <binding name="documentrepository_binding_soap12" type="ihe:documentrepository_porttype"> <soap12:binding style="document" transport=" <operation name="documentrepository_provideandregisterdocumentset-b"> <soap12:operation soapaction="urn:ihe:iti:2007:provideandregisterdocumentset-b"/> <input> <soap12:body use="literal"/> </input> <output> <soap12:body use="literal"/> </output> </operation> </binding> Definition of a service and its access points: Example of a document sharing service transaction <service name="documentrepository_service"> <port name="documentrepository_port_soap11" binding="ihe:documentrepository_binding_soap11"> <soap:address location=" </port> <port name="documentrepository_port_soap12" binding="ihe:documentrepository_binding_soap12"> <soap12:address location=" </port> </service> Classification : Public 18/41

19 For the French Health Information Systems, each target system that exposes services must publish the WSDL for the exposed service as per the WSDL 1.1 standard. 4 Security Features 4.1 Confidentiality The confidentiality of exchanges at the transport level is achieved by encapsulating data flow over a secure TLS connection. 4.2 Integrity The integrity of exchanges at the transport level is achieved by encapsulating data flow over a secure TLS connection. 4.3 Identification and Authentication Data is exchanged between: - The initiating system which provides the user identification and authentication information required for access control; - The target system which implements the access controls, such as determining the access permissions locally assigned to a user, based on the information provided by the initiating system. Identification and authentication information is transmitted by the formal VIHF 1 below. assertion described VIHF The Vecteur d Identification et d Habilitation Formelles (VIHF) is a French SAML template used to convey identity that will eventually also convey accreditation and authorization. Vecteur d Identification et d Habilitation Formelles translates to Formal Authorization Identification Vector. VIHF provides an organizational and technical model used to define the standards, formats and protocols that apply to the security of the data exchanged by Health Information Systems. This document introduces the first version of VIHF: VIHF 1.0. The purpose of the VIHF 1.0 is to introduce a technical standard for data access, which takes into account the diverse security policies and technical environments of users. 1 Vecteur d Identification et d Habilitation Formelles - a French SAML template used to convey identity that will eventually also convey accreditation and authorization Classification : Public 19/41

20 In the VIHF 1.0 model, the target system implements the access controls according to the locally defined rules and permissions. Future versions of the VIHF will fulfill other requirements such as the centralization of Health Information Sharing System user permissions Possible Configurations for Initiating Systems using the VIHF There are two possible authentication configurations for the initiating system: Indirect Authentication: The initiating system is housed by a healthcare organization and authenticates itself to the target system. The end user authenticates himself locally within the organization, and the organization is accountable for the exchanges with the target system. Direct Authentication: The CPS smart card is used to authenticate the healthcare professional directly to the target system, regardless of the location of the healthcare professional. Notes: This is about configuration and not specific context of practice, where the healthcare professional can practice from within the context of a healthcare organization such as a hospital, or can maintain an independent practice. In fact, the configurations depend on the authentication mechanisms and technology used, and not context of practice the specifics of the healthcare professional's scope of practice. As such, a user working within a healthcare organization can be authenticated using direct authentication if he has a CPS smart card to connect to a Health Information System or indirect authentication if he authenticates himself locally first and the connection with the target system is established based on the organizations server certificate General Functionality of Exchanges with VIHF The principle of functionality is as follows: - The connections between the initiating and target systems are secured by a TLS connection to assure the confidentiality of the SOAP exchanges; - Each SOAP request emitted by the initiating system is accompanied by a VIHF token communicated as a SAML assertion; the assertion contains the identity of the user and the necessary elements for the target system to determine the user's authorization for each application request; - Authentication mechanisms are differentiated according to the following configurations: o o With Indirect Authentication configuration, authentication is done by the target system based on the server certificates linked to the organization in which the user practices; With Direct Authentication configuration, authentication is done by the target system based on the certificates contained in the CPS healthcare professional smartcard. Classification : Public 20/41

21 Indirect Authentication functionality In this configuration, the end user is authenticated by the Health Information System in which he practices. The exchanges with the target system are executed by applications hosted by the organization to which the end user has delegated the responsibility for data exchange. This responsibility is carried out by using server certificates assigned to the organization, to provide assurance for the authentication and security of the exchanges. The security of the exchanges with the target system can be implemented using either one of the levels described below. The choice of which security mechanisms to implement and which configuration level to use is the responsibility of the target system, as a result of a risk analysis, ensuing security policy, and indirect authentication features. 1) Connection between the Organization and the Target System level Connections are established between the organization and the target service over TLS. The target system defines the TLS version that must be used as a result of a risk analysis, ensuing security policies and confidentiality and non-repudiation requirements and indirect authentication features. 2) Application exchange level Exchanges between the initiating and target systems are performed over SOAP. All the exchanges identify an end user, whose identity is included in a VIHF token that contains his local or national identifier, profession, specialty, scope of practice, as well as the organization's identifier. The profession, specialty and scope of practice documented in the VIHF token are expected to represent the user's details within the submitting organization. Based on its needs, the target system can implement access control in part or in full over: Some or all the information contained in the VIHF token, The service invoked and the associated access policy. As a result of a risk analysis, ensuing security policy, and indirect authentication characteristics, the target system can identify appropriate security mechanisms to implement such as the WS-Security profile with or without a digital signature. Figure 4 summarizes the workflow in question. Classification : Public 21/41

22 Organization Workstation Workstation Workstation 2.1: Authenticated user interaction 2.8: Response to user provides Server application certificate Inter-hospital initiating system 2.2: Creation of the request and signature with application certificate Initiating System Certificate Authority provides provides provides Server connection certificate CRL connection certificates 1: SSL/TLS session established 1.1: Verification of the validity of the server certificate TLS connection management module 2: Application exchanges 2.3:Application request transmission TLS connection management module 1.2: Verification of the validity of the server certificate CRL Server certificates Server connection certificate provides provides Target system services certificate authority Authentication and authorization module 2.4: Verification of the signature and validity of the server certificate CRL Application certificates 2.6: Transmission of application request 2.5: Verification of user rights 2.7: Application response sent Consent directive and access rights database Application processing module Target system application service Figure 4 : Organization based information exchange scenario Direct Authentication functionality In this configuration, the end user is identified and authenticated directly on the target system through the VIHF. The security of the exchanges with the target system can be implemented using either model described below. The choice of which security mechanisms to implement and which configuration to use is the responsibility of the target system, as a result of a risk analysis, ensuing security policy, and indirect authentication characteristics. 1) Connection between the Organization and the Target System model Connections are established between the initiating system and the target service over TLS. The target system defines the TLS version that must be used as a result of risk analysis, ensuing security policies and confidentiality and non-repudiation requirements and direct authentication features. 2) Application exchange level model Exchanges between the initiating and target systems are performed over SOAP. All exchanges identify an end user, whose identity is included in a VIHF token that contains his national identifier, profession, specialty, scope of practice, as well as the organization's identifier. The profession, specialty, and scope of practice documented in the VIHF token are expected to represent the user's details within the organization in which they practice. Classification : Public 22/41

23 Based on its needs, the target system can implement access control in part or in full over: Some or all the information contained in the VIHF token, The service invoked and the associated access policy. As a result of a risk analysis, ensuing security policy, and direct authentication characteristics, the target system can identify the appropriate security mechanisms to implement such as the WS-Security profile with or without digital signature VIHF Token Content A VIHF token, which is a security assertion in the form of a SAML 2.0 token, is submitted by the initiating system with each request to the target system in order to transmit information that can be used to authenticate a user and determine his access permissions. The content of the VIHF token depends on whether direct or indirect configuration is in use, and on the security policy decisions of the target service. The target service's security policies can optionally require the token to have a SAML 2.0 compliant signature. In addition to the SAML fields, a VIHF specific application profile is defined to transport the necessary information to implement access control. This information may be originated by: The CPS Information System, in the case of: Healthcare professionals that possess a smartcard with certificates, Organizations that possess a server certificate, The Information System of the organization that submits the assertion, The user themselves for information like purpose of use for instance Standard fields The attributes of the SAML2.0 "Assertion" required root object must contain a value, attributes. The initiating system must fill the following standard fields within the Assertion object. The fields are all required with the exception of the AudienceRestriction field. Classification : Public 23/41

24 /Assertion/Issuer Format: DN (Distinguished Name). Value: The field must contain the identity of the assertion submitter. In this context it must contain the DN of the physical or legal entity that submitted the assertion. The attribute must contain the value: urn:oasis:names:tc:saml:1.1:nameid-format:x509subjectname. Source: If the token is signed, the DN contained in the X.509 certificate must be used. Otherwise, use the DN contained in the X.509 authentication certificate that initiated the TLS connection: - In the case of indirect authentication; the server certificate submitted by the CPS-PKI, - In the case of direct authentication, the CPS certificate of the healthcare professional. The DN structure must conform to the RFC 2253 "UTG-8 String Representation of Distinguished Names" specification of December Reminder of the RFC 2253 Rules: The Relative Distinguished Name (RDN), which is a comma separated string, must appear in reverse order from the certificate. While the attributes within the multi-valued RDN are separated by a "+" and their order is unimportant. Example of the DN of a physician healthcare professional: CN= SN=DUPONT+GN=JEAN,OU=Physician,O=GIP-CPS,C=FR Example of the DN of an employee of an organization identified in FINESS: CN= /0001+SN=DUPONT+GN=JACQUES,OU= ,L=Paris (75),O=GIP-CPS,C=FR /Assertion/Subject/NameID The value must contain the identifier of the end user sent by the initiating system. Format: Alpha-numeric string Value: For the Direct Authentication configuration: Classification : Public 24/41

25 The national identifier of the healthcare professional must be obtained from the certificate. The source of this information is specified in reference appendix [4] 2, under the name «PS_IdNat». Please Note : For pharmacists that have CPE smartcards but not CPS or CPF, please refer to paragraph for specific instructions for processing Pharmacist smartcards. For the Indirect Authentication configuration: The national identifier of the healthcare professional must be constructed as per the description in reference appendix [4], under the name «PS_IdNat» /Assertion/AuthnStatement/AuthnContext/AuthnContextClassRef The field must reference the user's authentication method that will produce the SAML assertion from the initiating system. This does not refer to the authentication mode for the target system. This authentication method is encoded using the SAML 2.0 nomenclatures in the SAML standard saml-authncontext-2.0-os 3 document. The accepted values may be enforced by the target system. If the CPS smartcards is used for authentication, the field's value will be: urn:oasis:names:tc:saml:2.0:ac:classes:smartcardpki /Assertion/AuthnStatement@AuthnInstant This attribute must include the date and hour when the authentication was performed by the system producing the SAML assertion, i.e. the initiating system. The date and hour must be expressed in Coordinated Universal Time (UTC) /Assertion/Conditions/AudienceRestriction This attribute is optional, but its presence may be enforced by the target system if the information system's Security Policy 4 OID is known. This attribute must contain one or more Audience entries that in turn contain a URI that references the security policy of the related sending system, to help the target system process the assertion. Format: OID Source: 2This reference refers to the 4th reference document listed on the title page of this module, i.e.: the Cross- Functional Appendix of data sources for professionals and organizations 3 saml-authn-context-2.0-os : 4 ASIP Santé's work on the Politique Générale de Sécurité des Systèmes d Information de Santé (PGSSI-S) should eventually specify which Security Policy types apply including the corresponding OIDs. Classification : Public 25/41

26 Sending system and The attribute NotBefore contains the date and hour expressed in Coordinated Universal Time (UTC) and contains the start time of the validity of the assertion. The attribute NotOnOrAfter contains the date and hour expressed in Coordinated Universal Time (UTC) and contains the end time of the validity of the assertion. The difference between two values gives the life span of the token. The target system can determine the maximum acceptable life span, which can be reduced by the sending system. If the token is signed, the value of NotBefore must not be later than the signature date. Format : xs:datetime Source : Sending system Classification : Public 26/41

27 Additional Attributes The additional attributes are <saml:attribute> entries included in the <saml:attributestatement> tag of the SAML token. The fields are described below: Attribute 5 Required/ Description Optional VIHF_Version R Version of the VIHF being used urn:oasis:names:tc:xacml:2.0:subje ct:role R Functional role of the user, can be multi-valued but must contain the user's profession at a minimum as per section Secteur_Activite R Sector in which the user practices urn:oasis:names:tc:xacml:2.0:resou rce:resource-id R if needed 6 Patient identifier for the subject of the request Ressource_URN R The resource that is targeted by the user urn:oasis:names:tc:xspa:1.0:subjec t:purposeofuse Mode_Acces_Raison urn:oasis:names:tc:xspa:1.0:subjec t:subject-id R R If Break Glass O Indicates the access mode requested by the user, i.e. Normal, Breakglass or Center 15 Default value = normal Purpose for the breakglass User identity, such as: First name, last name and/or service within a healthcare organization Identifiant_Structure R Identifier of the healthcare organization or physician office that submitted the request LPS_Nom O Name of software used to submit the request LPS_Version O Version of software used to submit the request LPS_ID O Serial number or installation identifier of the software used to submit the request 5 Attribute names are in french as they appear in the original HIS code base. 6 The element urn:oasis:names:tc:xacml:2.0:resource:resource-id is required for all flows concerning a patient. For flows that are not related to a specific patient, the element urn:oasis:names:tc:xacml:2.0:resource:resource-id is not included in the VIHF. Classification : Public 27/41

28 Formats and Values of the Additional Attributes of the VIHF Token VIHF_Version Format : Decimal Value: 1.0 Source: Configuration of the initiating system urn:oasis:names:tc:xacml:2.0:subject:role Format : HL7 v3 CE data type Value: The attribute subject :role is multi-valued. The first occurrence of the attribute must contain: For a PS (healthcare professional) smartcard: the code and displayname of the healthcare professional's profession followed by the codesystem (OID) of the table used for the encoding, For a PF (healthcare professional in training) smartcard: the code and displayname of the individual's future profession following by the codesystem (OID) of the table used for the encoding, For a non-healthcare professional data producer 7 : the code and displayname that corresponds to the subject, such as a patient, device, physician's assistant, or other entity, followed by the codesystem (OID) of the table used for the encoding. The second occurrence is only used for physicians and pharmacists and is absent for all other subjects. The attribute must contain: For a physician: the code and displayname of the physician's specialty or another domain of expertise corresponding to the context at the moment of the creation of the token, followed by the codesystem (OID) of the table used for the encoding, For a pharmacist: the pharmacist's table and the displayname corresponding to the context of the moment of the creation of the token, followed by the codesystem (OID) of the table used for the encoding. Source: 7 A non-healthcare professional data producer can include physician assistants and other people within the professional's employ, or medical devices who may collect or produce healthcare data. Classification : Public 28/41

29 Please refer to the specification in reference appendix [4], in the subjectrole section. Example for a physician: <saml:attribute Name="urn:oasis:names:tc:xacml:2.0:subject:role"> <saml:attributevalue> <Role xmlns="urn:hl7-org:v3" xsi:type="ce" code="10" codesystem=" " displayname="médecin 8 "/> </saml:attributevalue> <saml:attributevalue> <Role xmlns="urn:hl7-org:v3" xsi:type="ce" code="sm54" codesystem=" " displayname="médecine Générale (SM)"/> </saml:attributevalue> </saml:attribute> 8 Attribute values are in french because they are taken from a french value set. Classification : Public 29/41

30 Secteur_Activite Format: Code^OID Value: The code for the user's scope of practice followed by the codesystem (OID) of the table used for the encoding. Source: Please refer to the specification in reference appendix [4], in the healthcarefacilitytypecode section urn:oasis:names:tc:xacml:2.0:resource:resource-id The use of this attribute is recommended by the IHE Technical Framework supplement called Cross- Enterprise User Assertion - Attribute Extension (XUA++) and is used to identify the patient. Format: HL7 v2.5 CX format as described in the reference document [3]: Constraints on HL7 v2.5 data types that apply to the IHE IT Infrastructure Technical Framework within the scope of IHE France v1.2 of October Value: This metadata points to the INS 9 -A if available, and otherwise defaults to the INS-C. Components 1, 4 and 5 are required. Component 1 - Identifier Component 1 in this case is the INS patient identifier. This component contains the INS-A if possible, and otherwise defaults to the INS-C. The INS-C is 22 integers in length. INS-A is 13 integers in length. Component 4 - Assigning authority Component 4 is the INS assigning authority, and is used as follows: 1st sub-component: Namespace ID (IS) = empty 2nd sub-component: Universal ID (ST) : OID of the assigning authority of the IN type used, i.e.: for INS-A or for INS-C 3rd sub-component: Universal ID type (ID) = ISO Component 5 Identifier Type Component 5 is the INS-A for patients identified by their INS-A. Component 5 is the INS-C for patients identified by their INS-C. Examples : 9 INS: Identifiant National de Santé - The generic acronym for a national health identifier, used in France. The INS is distinct from the social security identifier used for health payment Classification : Public 30/41

31 Example with INS-A: ^^^& &ISO^INS-A Example avec INS-C: ^^^& &ISO^INS-C Ressource_URN Format: URN 10 Value: For services that do not relate to a patient: urn:{target} where {target} identifies the target resources of the service being invoked. For services that relate to a specific object in the target system: urn:{target}:{target object identifier} When a system such as the DMP indexes objects using patient identifiers, the target object's identifier must not be used to convey the patient identifier. The urn:oasis:names:tc:xacml:2.0:resource:resource-id attribute must be used to convey the patient identifier. Source: Supplied by the initiating system's application, depending on the service and possibly on the object targeted by the user urn:oasis:names:tc:xspa:1.0:subject:purposeofuse Format: HL7 v3 CE data type Value The PurposeOfUse attribute must contain one of the following attributes values: code: Depending on the access mode requested by the user, the attribute can have one of the following values: 10 As specified in RFC 2141 Classification : Public 31/41