Pakkumusettepanek

EUROPEAN COMMISSION DIRECTORATE-GENERAL FOR HEALTH AND FOOD SAFETY General Affairs Information systems eHealth DSI Patient Summary and ePrescription System Architecture Specification DOCUMENT VERSION 2.1.0 DATE 01/06/2017 STATUS Wave 1 Operation ready DG SANTE, CEF eHealth DSI, 2017 Reuse is authorised, provided the source is acknowledged. COVER AND CONTROL PAGE OF DOCUMENT Document old name: D3.7.2 Final System Technical Specification Document name: System Architecture Specification Distribution level*: PU Status: Wave 1 Operation ready Author(s): eHealth DSI provider Organization: * Distribution level: PU = Public, PP = Restricted to other programme participants, RE = Restricted to a group specified by the consortium, CO = Confidential, only for members of the consortium. ABSTRACT In this document, the eHealth DSI architecture is partitioned into the three classical viewpoints: Business View, Information System View and Technology View. This approach, inter alia, supports a sufficient level of abstraction useful to architect a system of heterogeneous healthcare national infrastructure. Furthermore this level of heterogeneity makes eHealth DSI a typical field for a Service Oriented Architecture (SOA) style. In this context the architecture must be abstracted from the complexity-characteristic-platform of underlying systems (loose coupling principle). The specific technical implementation of a service should be hidden for the consumer. The components of an eHealth DSI National Contact Point (NCP) can be viewed like a logical “wrapper” of the different National Infrastructures. This document covers the most technical part (technology view), giving guidelines for an implementation of an eHealth DSI NCP. It is meant to embrace those works in the most comprehensive manner without repeating those results unnecessarily. CHANGE HISTORY Version Date Status Changes From Review V0.8 29/10/2010 updates ASIP Santé, WP3.3 LOMBARDY members V2.0.0 28/03/2017 Remove all eHealth DSI provider references to epSOS and requirements V2.0.1 21/04/2017 Integrate the eHealth DSI provider modifications linked to the CP-002 V2.0.2 23/05/2017 Remove the eHealth DSI provider overlapping information about the eHealth DSI web services V2.1.0 01/06/2017 Released for eHealth DSI Solution eHMSEG adoption Provider TABLE OF CONTENTS 1 Executive Summary................................................................................................................. 6 2 Introduction............................................................................................................................... 7 3 Context & Methodology ......................................................................................................... 8 3.1 Methodology and approach.........................................................................................................8 4 Business View ........................................................................................................................... 9 4.1 eHealth DSI Information Model ................................................................................................9 4.1.1 Actors, Roles and Objects ................................................................................................. 9 4.1.2 Relationship between actors & objects: Information Model ............................. 9 4.2 eHealth DSI processes .................................................................................................................. 10 4.2.1 Establishment of a secure context between 2 NCPs............................................ 10 4.2.2 Medical data exchange & handling ............................................................................. 12 4.2.3 Groups of eHealth DSI processes................................................................................. 14 4.2.4 Description of the flow of control ............................................................................... 14 4.2.5 Exception Handling ........................................................................................................... 21 4.3 Synthesis: Business view ............................................................................................................ 22 5 Information System View.................................................................................................... 23 5.1 From Business view to eHealth DSI Information System ..................................... 23 5.2 Descriptions of the eHealth DSI services......................................................................... 26 5.2.1 Trust – Audit Services ...................................................................................................... 27 5.2.1.1 Internal & External Services.......................................................................................... 28 5.2.1.2 Internal Services ................................................................................................................ 28 5.2.1.3 External Services................................................................................................................ 28 5.2.2 Data Exchanges – Data Transformation Services ................................................. 28 5.2.2.1 Internal & External Services.......................................................................................... 28 5.2.2.2 Internal Services ................................................................................................................ 29 5.2.2.3 External Services................................................................................................................ 29 5.2.3 eHealth DSI support Services ....................................................................................... 29 5.2.3.1 National Contact Point Routing Table ....................................................................... 29 5.2.3.2 Trusted Certificates .......................................................................................................... 29 5.2.3.3 Taxonomy for the eHealth DSI pivot format central function ......................... 29 5.2.3.4 Traits Handshake central function ............................................................................. 30 5.3 NCP considerations ........................................................................................................................ 30 5.3.1 NCP Interface to national domain ............................................................................... 32 5.4 Security considerations .............................................................................................................. 32 5.5 Information Objects....................................................................................................................... 32 5.5.1 Healthcare Professional (HP) ....................................................................................... 33 5.5.1.1 Healthcare Professional Address ................................................................................ 34 5.5.1.2 HealthCare Professional Organization ...................................................................... 34 5.5.2 Patient .................................................................................................................................... 34 5.5.3 Patient Summary (PS)...................................................................................................... 34 5.5.3.1 Medication Summary ....................................................................................................... 35 5.5.4 ePrescription (eP) ............................................................................................................. 35 5.5.5 eDispense .............................................................................................................................. 36 6 Technology View .................................................................................................................... 37 6.1 From Information System view to Technology view ............................................... 37 6.2 eHealth DSI platform .................................................................................................................... 38 6.2.1 Foreword............................................................................................................................... 38 6.2.2 eHealth DSI Domains ........................................................................................................ 38 6.2.2.1 eHealth DSI communication layer .............................................................................. 39 6.2.2.2 Business layer ..................................................................................................................... 39 6.2.2.3 National communication layer ..................................................................................... 39 System Architecture Specification_v2.1.0 Page 4 of 69  6.3 eHealth DSI Technical Architecture.................................................................................... 39 6.3.1 Introduction ......................................................................................................................... 39 6.3.2 Service Architecture ......................................................................................................... 40 6.4 Composite Structure ..................................................................................................................... 42 6.4.1 Layers Description ............................................................................................................ 42 6.4.1.1 The National Communication layer ........................................................................... 43 6.4.1.2 The business layer ............................................................................................................. 43 6.4.1.3 The National Communication layer ........................................................................... 43 6.4.1.4 The Platform layer............................................................................................................. 43 6.4.2 Components Description ................................................................................................ 43 6.4.2.1 Inbound Protocol Terminator ...................................................................................... 44 6.4.2.2 Outbound Protocol Terminator ................................................................................... 45 6.4.2.3 Workflow Manager ........................................................................................................... 46 6.4.2.4 Transformation Manager ............................................................................................... 47 6.4.2.5 Terminology Access Manager ....................................................................................... 49 6.4.2.5.1 Interaction diagram for semantic ........................................................................... 51 6.4.2.6 Security Manager ............................................................................................................... 53 6.4.2.7 AuditTrail .............................................................................................................................. 54 6.4.2.8 Configuration and Monitoring Manager................................................................... 54 6.4.2.9 NationalConnector ............................................................................................................ 55 6.4.3 Components Communication workflow .................................................................. 56 6.4.3.1 Patient Identification........................................................................................................ 56 6.4.3.2 Data Exchange (PS & eP) ................................................................................................ 58 6.4.3.3 Notification ........................................................................................................................... 59 6.5 Security Architecture.................................................................................................................... 61 6.5.1 Trusted Federation of NCPs .......................................................................................... 61 6.5.1.1 NCP certificates................................................................................................................... 62 6.5.2 Message exchange infrastructure ............................................................................... 62 6.5.3 Upper Layer (Iso 7) ........................................................................................................... 63 6.5.3.1 Transmission of authenticated HP ............................................................................. 63 6.5.3.2 Common message format ............................................................................................... 63 6.5.3.3 Signature on message ...................................................................................................... 63 6.5.4 TCP Message Layer (Iso 4) ............................................................................................. 63 6.5.5 IPsec VPN Network Layer (Iso 3)................................................................................ 63 6.5.6 Physical Infrastructure Layer (Iso 1) ........................................................................ 64 6.5.7 Regarding the use of Certificates and PKI ............................................................... 64 6.5.8 Regarding the use of Certificates and PKI ............................................................... 64 6.5.9 Regarding the use of Certificates and PKI ............................................................... 64 6.5.10 Regarding SOAP faults ..................................................................................................... 65 6.5.10.1 Message processing fault ........................................................................................... 65 6.5.10.2 Business processing / request faults .................................................................... 65 6.5.10.3 Clinical processing / content faults ....................................................................... 65 6.5.11 Security zone ....................................................................................................................... 66 6.5.12 Session context ................................................................................................................... 66 6.5.13 Adopted Standards............................................................................................................ 66 6.6 Profile and Transaction Mapping......................................................................................... 68 7 Terminology and Glossary ................................................................................................. 69 7.1 Wording conventions ................................................................................................................... 69 7.2 eHealth DSI Glossary ..................................................................................................................... 69 System Architecture Specification_v2.1.0 Page 5 of 69 1 Executive Summary The goal of eHealth DSI is to demonstrate that pan-European health data exchange can be effective in seamless manner for the Healthcare Professional (HP). Two basic pillars have to be kept in mind: existing national healthcare infrastructures / legislation remain unchanged; trust among Country is based on contracts and agreed policies. A brief synthesis of the principles that drive the architecture is: 1. all eHealth DSI communications are done via gateways and thus have a Business to Business communication model, 2. eHealth DSI must not alter existing medical data in the national systems, 3. records of all exchanges within eHealth DSI are required and stored, 4. business transactions are designed separately of security but rely on the provision of a security context (“Circle of Trust”), 5. the architecture and its services must be extensible to cover possible new supplementary specification in further implementations of eHealth DSI, 6. a Service Orientated Architecture (SOA) is suitable to provide a loosely integrated suite of services that can be used within the multiple business domains covered by country in eHealth DSI, 7. the opportunity to implement a common components solution that fits country needs to ease medical European exchanges. Figure 1: eHealth DSI "overall picture A circle of trust is built between NCP in the "eHealth DSI abstract space", the only way a country can exchange with another country. System Architecture Specification_v2.1.0 Page 6 of 69 In this document, the eHealth DSI architecture is partitioned into the three classical viewpoints: Business View, Information System View and Technology View. This approach, inter alia, supports a sufficient level of abstraction useful to architect a system of heterogeneous healthcare national infrastructure. Furthermore this level of heterogeneity makes eHealth DSI a typical field for a Service Oriented Architecture (SOA) style. In this context the architecture must be abstracted from the complexity-characteristic-platform of Acting as a “red line”, a simple core- underlying systems (loose coupling building blocks figure of the eHealth DSI principle). The specific technical implementation of a service should be architecture is used as much as possible hidden for the consumer. The throughout this document. components of an eHealth DSI National Contact Point (NCP) can be viewed like a logical “wrapper” of the different National Infrastructures. The basic blocks of the architecture (eHealth DSI profiles) are built upon three main operations: Query, Retrieve and Notify. Those operations are the unitary blocks needed to perform the exchanges of data between countries in the eHealth DSI context. This document covers the most technical part (technology view), giving guidelines for an implementation of an eHealth DSI NCP. It is meant to embrace those works in the most comprehensive manner without repeating those results unnecessarily. 2 Introduction The main goal is to provide an appropriate view for eHealth DSI, detailing functionalities, components, interfaces and infrastructures, from which technical realizations result. Chapter 5 and 6 gives the more technical specs about NCP-NCP. eHealth DSI has the objective of improving health care services for European citizens therefore its use must remain simple for both patient and health care professionals. Such a system will increase the value of pan-European health data exchange providing new feeds for existing processes and infrastructures. The challenge is to demonstrate that pan-European health data exchange can be done in a regularly and easily manner without changing existing national healthcare infrastructures and legislations, within a trust framework (contracts and agreed policies) among countries. eHealth DSI architecture is to provide PS and eP cross-border interoperability. eHealth DSI is implemented as a set of interacting National Contact Points (further, simply “NCPs”) built on top of Web technology. Each NCP agrees to exchange medical data under a mutual circle of trust as shown on figure below: System Architecture Specification_v2.1.0 Page 7 of 69  Figure 2: Mutual circle of between NCPs The number of NCPs is first limited to a first wave of countries but will increase in the future as new country enter eHealth DSI. Therefore the architecture must be scalable in respect to the number of participating countries and the number of supported use cases. The eHealth DSI can be considered as a project for communication between National Infrastructures of Countries and not directly between HP/HCPO1 or a patient and an HP/HCPO. The eHealth DSI Architecture is the technical and conceptual translation of those main sources: 1. the Use Cases (UC), 2. the functional and non-functional requirements deduced from the UCs, 3. the security specification, 4. the identity management specification, 5. the semantic services specification, 6. the common components specification, 7. the common implementation. This document firstly focuses on the key business specifications that help to drive the design work on the architecture. It, then, states the basic concepts and principles that were derived from the analysis of the use cases requirements. On this basis, the core content of this document is given through different views of the architecture that will be explained in the next chapters: 1. A Business View 2. An Information System View 3. A Technology View 3 Context & Methodology This chapter gives an overview of the methodology followed in order to provide the eHealth DSI architecture, focuses on the key specification. It then concludes on the basic principles that drive the architecture design. 3.1 Methodology and approach As mentioned in the Introduction, the architecture is partitioned into the three classical views derived from TOGAF2 1 In this document, no distinction between the Healthcare Professional (HP) and the HCP Organization (HCPO) will be made (HP/HCPO). 2 Opengroup, TOGAF Version 9, 2009 (www.opengroup.org). System Architecture Specification_v2.1.0 Page 8 of 69   Business Architecture (Business view), which describes a Computationally Independent Model referring to the eHealth DSI domain of interest without technical considerations. This view is devoted to identification of the actors, data objects and relevant processes for the eHealth DSI system to operate from a business point of view (HP/HCPO/Patient).  Information System Architecture (IS view), which describes a Platform Independent Model and looks at the system in a computational complete way but without any implementation specific detail. This view is principally devoted to the identification of eHealth DSI services - and their collaboration - derived from the processes (ref. to Business view). Components and service interface are described as well.  Technology Architecture (Technology view), which describes a Platform Specific Model (i.e. a general webservices stack, not specific to a programming language/technology) that maps and specifies the Information System view onto specific technology options for the eHealth DSI system. This view refers to the eHealth DSI Profiles and their most technical part. 4 Business View The Business View deals with how the business processes, associated individuals and business units relate to each other. The Business view represents the concepts that are supposed to be stable whatever the implementations or the Use Cases are applied. The eHealth DSI is designed to accomplish operational task driven by the business strategies. The business driven approach and the technology driven approach meet in order to logically and technically match business use case scenario. 4.1 eHealth DSI Information Model This chapter gives a high level representation of the eHealth DSI information model, including domain actors (i.e. a person, a device, another system or sub-system) and objects. 4.1.1 Actors, Roles and Objects Actors can act on the eHealth DSI system or is acted on by the eHealth DSI system. A role is related to an actor having a specific behaviour in a particular context: provider and consumer. The eHealth DSI system bridges the communication between formats based messaging under two modes of communication: Outbound and Inbound. The consumer (e.g. HP/HCPO asking for a Patient Summary) uses the outbound actor (i.e. NCP-B) to query the inbound actor (i.e. NCP-A), then the inbound actor retrieves the medical data under its national infrastructure and acts as a provider. Simply put: the provider retrieves information from its own country and the consumer queries for information. Actors are: Patient, HP/HCPO (no distinction is made in this document with HP and HCPO), Infrastructures of country A and B, NCPs. Objects are: Patient Summary, ePrescription, eDispense, Patient Consents (for PS, eP, eDispense). 4.1.2 Relationship between actors & objects: Information Model As a consequence from the analysis of FR/NFR from [PS Functional requirements] and [eP Functional requirements], the architecture is able to consider the eHealth DSI information model as described in figure 6. NB: NCP-A and NCP-B are not represented here, but considered in relationship as follows: System Architecture Specification_v2.1.0 Page 9 of 69  • NCP-A: Patient Summary, ePrescription, eDispense, Patient Identification, Patient Consent • NCP-B: HP, HCPO, eDispense, HP/HCPO authentication Figure 3: eHealth DSI Information Model NB: • Medication Summary is part of the Patient Summary but it is not represented as such in the above figure. • Patient consent (not represented here as a manipulated document – but used as attribute to an operation) contains the information about roles of the HP. 4.2 eHealth DSI processes The scope of this sub-chapter is to support the identification of services. One of the powerful aspects of services oriented approach in respect of messaging or transaction approach is the capacity to design generic services, reusable in different scenarios versus the definition of messages tightly coupled with the specific integration context. In eHealth DSI, the two different contexts (ePrescription and Patient Summary) share the same basic business activities into 2 main steps: - Secure context establishment - Data Exchange and Handling The eHealth DSI core business processes can therefore be represented as such: Figure 4: eHealth DSI Core Business Processes 4.2.1 Establishment of a secure context between 2 NCPs Within eHealth DSI, the consumer (Query operations) and the provider (Retrieve operations) do not know each other. The Circle of Trust is among NCPs. They are System Architecture Specification_v2.1.0 Page 10 of 69 solely able to establish mutual trust relationships. The final trust relationship is (n:n) and set up based on direct trust relationships among NCPs. The key issue is that a NCP can rely on the agreed behaviour of another NCP. While country B needs access control to protect its HPs from accidentally accessing data in an illegal way (e.g. because the data controller in country A allows for an access that is forbidden by the law of country B), country A has to protect the privacy of its citizens and to ensure the integrity of its internally managed data objects. The [Security Services Specification] details elements related to the trust secure context infrastructure and those security issues are treated in section 5.3. The communication between 2 NCPs: MUST include mutual requestor/sender authentication (unique and non-repudiable identification) and MUST prevent attacks on the communication level, MUST include mechanisms for confidentiality, integrity and non-repudiation, MUST provide a unique identification and a non-repudiable authentication of HP/HCPO, MUST provide means to make a business request non-repudiable for the HP, MUST ensure that the originator information of a medical data object is authentic, MUST ensure that a medical data object has not been modified while transmitted. Figure 5: Secure Context Establishment Basically: • Step 1: a HP is identified and is authorized to access the eHealth DSI System, • Step 2: A Patient Identification process follows, • Step 3: The Confirmation of the Treatment Relationship is established between the patient and the HP/HCPO. System Architecture Specification_v2.1.0 Page 11 of 69 The Secure Context Establishment supports the separation of basic security concerns from the business transactions. The latter is achieved by defining a security context that the business transactions can rely on. Before an eHealth DSI transaction is carried out on business level, a chain of trust relationships between the involved actors has to be established. This chain of trust is based on (mutual) authentication. The above figure shows the necessary steps. The HP authentication allows for the HP/HCPO its authentication in country B. For the authentication of the HP/HCPO - who issues the request - and for the authorisation of that HP/HCPO by the patient - who is the owner of the requested medical data object - country A has to trust the processes of country B. The Patient identification between country A and country B in order to allow for ID mapping in such a way that ID domain, on one hand, and medical data domain, on the other hand, can be strictly separated. The process starts routing calls to NCP-A. Patient ID data is entered by HP/HCPO of country B and information regarding patient’s country is given. Based on that mutual trust the patient identification and authentication (as far as required by country A) is done, initiated by the HP/HCPO of country B but controlled by the NCP-A. The Treatment Relationship Confirmation is established between the HP/HCPO and the patient. A treatment relationship is validated when the HP/HCPO checks the box provided by his regular interface. 4.2.2 Medical data exchange & handling Medical data exchange & handling is the core business activity of eHealth DSI. This does include PS and eP exchange. Two groups of processes have emerged to handle data exchange. System Architecture Specification_v2.1.0 Page 12 of 69  Figure 6: Data Exchange and Handling Data retrieval HP/HCPO-B gathers information liable to be treated by NCP-B. Local infrastructures have many different ways to process their medical data. NCP-A must be able to treat data even if data source or format changes. First an automated task, called Discovery, is operated on retrieved local/national format. If no exception arises, then the data transformation to the eHealth DSI format can start. Data transformation has a set of rules for transforming a national format into an eHealth DSI format. The transformation is achieved by associating national patterns with templates (validation). The structure of the eHealth DSI pivot format (CDA envelope) can be different from the structure of the national source document. Elements from the PS & eP can be filtered; reordered and arbitrary structure can be appended to fill up the eHealth DSI format. A signature for the document is then provided at the end of the process. Data is always displayed synchronously, and MUST adapt various technologies. NB: The processes described in this section have a general value for eHealth DSI. However, Privacy Law of some Countries MAY require that data transformation is performed not in the NCP, but in the system where the information is kept or in the system where the information is exploited. Send Notification The notification supports the ability to notify – typically Country B – a change of status on the data retrieved from Country A (i.e. an indicator referring to a state transition). It also supports the ability to send data originated in Country B to Country A (e.g. dispensation/supply). System Architecture Specification_v2.1.0 Page 13 of 69 4.2.3 Groups of eHealth DSI processes As a summary, the identified building blocks can be sorted out as in the following figure: Figure 7: Processes supporting core building blocks 4.2.4 Description of the flow of control The following figures provide a view of data processing and secure context through the data exchange request. HP Identification & Authentication System Architecture Specification_v2.1.0 Page 14 of 69  Figure 8: eHealth DSI HP Identification & Authentication At the beginning of the process, identification procedure initiated by the HP is insufficient to face the threat of a false HP identity. The authentication can solve this problem HP provides identification information and NCP verifies the formal correctness of provided information through the attribute mapping check operation. The proclaimed identity and genuine identity of the HP will be validated during the authentication check step of the initial protocol. The identification/authentication result will be finally sent back to the HP/HCPO B. NB: HP/HCPO and Infrastructure A/B parts are country concern. The processes involved are presented as guidelines with no mandatory requirement. Patient Identification System Architecture Specification_v2.1.0 Page 15 of 69  Figure 9: Patient Identification When a patient needs a health service (health care, ePrescription) in a foreign country B two sub-cases are considered: The HP receives necessary identification information and is able to identify the patient. Patient identification information is not enough according to country A regulations and requires additional data (e.g. temporary password). Countries can use TAN (Temporary Access Number) for patient authentication. It is not a mandatory field and countries are free to choose traits for their citizens. Only Identification of a patient by a HP in country B is represented in this schema. NB: HP/HCPO and Infrastructure A/B parts are country concern. The processes involving them are presented as guidelines with no mandatory requirement. Treatment Relationship Confirmation System Architecture Specification_v2.1.0 Page 16 of 69  Figure 10: Treatment Relationship Confirmation A treatment relationship confirmation issue by HP/HCPO informs the patient that his medical data will be accessed. The patient MUST be informed to give his consent for this operation. The identity of HP/HCPO with a signature is also encapsulated in the message. The signature of NCP-B MUST be recognized by NCP-A. When the message reaches country A, the Patient privacy policies state who can benefit the right to access his/her data’s. A patient has to state his consent for the exchange of his/her medical data in accordance with the patient consent policy in country A. According to the type of data that needs to be accessed, country A determines the status as a result of consent and policy verification in country A. In addition to the Actors role, confirmation or rejection depends on the type of data. It will be mandatory for country B to provide this assertion, but country A MAY decide to ignore it. An attribute that will be used for indicating an emergency access scenario will be included in the TRC assertion. NB: HP/HCPO and Infrastructure A/B parts are country concern. The processes involved are presented as guidelines, country states if they deliver Medical Data for the patient. Data Retrieval System Architecture Specification_v2.1.0 Page 17 of 69  Figure 11: Data retrieval The data retrieval process returns medical data under National Format. The steps to follow in order to achieve the semantic transformation process are provided here: 1) The medical document is retrieved by NCP-A. The document MAY be digitally signed. 2) The nominal process is the following: NCP-A verifies the validity of the signature and checks the authenticity and integrity of the document. In case of a successful verification NCP-A signs the document. 3) The document is transformed into the eHealth DSI pivot format by NCP-A. 4) The original document is provided as a PDF or rendered as PDF and enveloped. 5) NCP-A creates a detached signature over the pivot document, the PDF document and the original signature. If PDF is provided by the system, there is no need for NCP-A to sign it. This attests that: authenticity and integrity were checked and the pivot document is a transformation of the original document. 6) Both documents (original and pivot) and signatures are sent to NCP-B. System Architecture Specification_v2.1.0 Page 18 of 69  7) NCP-B transforms the pivot document into country B native format and handles it over to the HP. Transformation and data validation are specific to each country (various national formats in use). The retrieval task is a national concern and in any case Country A is responsible to provide the result or the exception/failure outcome back to the requestor (Country B). NOTE: To avoid multiple dispensations for the same prescription, pharmacist retrieves ePs and dispenses. A policy will be defined that a pharmacist always MUST first retrieve the current list of available prescriptions before he can dispense anything. This is in line with the Industry Team proposition that it is up to the pharmacist to manage its stock and that state machine and eP lifecycle management is to be done in Country A. Figure 12: Semantic Services – NCP-A Data Transformation System Architecture Specification_v2.1.0 Page 19 of 69  Figure 13: Semantic Services – NCP-B Data Transformation NB: HP/HCPO and Infrastructure A/B parts are country concern. The processes involving them are presented as guidelines with no mandatory requirement. Send Notification Figure 14: Send Notification Notification occurs when an event is triggered (e.g. a dispensed medicine in country B). The notification object is then transported from B to A and verified. Because System Architecture Specification_v2.1.0 Page 20 of 69 partial dispensation of a medicine is possible, Country A must provide a way to update the ePrescription. Unless the Notification result has been sent, no more dispense for the same ePrescription will succeed the validation process in country A. NCP-A gives its ok ("Notification validation"); NCP-B does not wait for eP result (no return arrow from A); NCP-A assures updates ("Mapping ePrescription"). NB: HP/HCPO and Infrastructure A/B parts are country concern. The description of functionalities is presented as guidelines but presents no mandatory requirement. 4.2.5 Exception Handling eHealth DSI has to be secure even if a failure arises. That is, the involved actors should stay in a well-defined state with a well-defined fault handling. Therefore exceptional events MUST be reported among system components in a way that allows the systems that are affected by the failure to process the respective message in a way that: • an appropriate reaction can be taken, • further dependent failures are prevented, as few system components are affected as possible. To reach this objective, 5 general principles for eHealth DSI exception handling have been defined: • There are NCP-related exceptions, which MUST be defined in this document. There are National-Structure-related exceptions, which SHOULD be covered by the national infrastructures. For each exceptional solution (i.e. long response time), the eHealth DSI exception handling specification MUST provide guidance stating i) if it MUST be communicated among gateways or ii) if it MUST, SHOULD or MAY be handled solely within the affected national infrastructure. • eHealth DSI services system MUST provide all system user and system partners (i.e. HP, NCP and National Infrastructures) with appropriate feedback, even if the transaction failed. • An error feedback system must be established, including the support of a national helpdesk. A hierarchy of error messages (3 classes) should be established which is easily understandable to the HP user, making clear when the user should abort the system: o Class I: Try-again, if it is a temporary error-producing situation (e.g. service not available), o Class II: user-centric advice, what went wrong (e.g. failed identification), o Class III: call to higher instance as something fundamental went wrong (e.g. national hotline). It is not mandatory for each country to support such a “hotline”, but it is mandatory to specify a national contact if a fatal error must be propagated. • The decision to propagate an error-message is related to its code severity. There are five levels of severity in eHealth DSI defined (cf. table below). It is mandatory to propagate the last “CRITICAL” Level. Every bilateral agreement between two countries can define to give one of the severity levels a dedicated action. Severity Code Description Debug Only for internal use (technical experts) Info Only for internal use Warning Some flaws, but the transaction is performed Error The transaction may or not succeed CRITICAL Critical failure, transaction must be cancelled System Architecture Specification_v2.1.0 Page 21 of 69  • Trust between countries is essential for eHealth DSI, especially in a failure situation. Therefore every failure MUST be recognized in the Audit Trail. It might be sufficient to just use a general error code with participants, date and time. But regarding to the severity code, it can also be most important to log as much information as possible. 4.3 Synthesis: Business view A classical distinction is made between “services” considered at the business level and those considered at technical level (i.e. Information System view and Technology view). Referring to OASIS-SOA-RM, “Services are the mechanism by which needs and capabilities are brought together”. The services enable distributed capabilities that may be under the control of different ownership domains. Service provides a uniform means to offer, discover, interact with and use capabilities to produce desired effects consistent with measurable preconditions and expectations. The main services for eHealth DSI at a business level are represented in the figure below: Figure 15: The eHealth DSI services at business level Identification Service: This service first enables NCPs identification/authorization/authentication from HP/HCPO of country B to National Infrastructure of country A. To enable exchange of data, the binding service creates a channel of communication, as a secure way to enable the circle of trust. PS Service & ePrescription Service: data are sent through the PS & ePrescription services. Those services check for the validity and the transformation to the pivot format back and forth. System Architecture Specification_v2.1.0 Page 22 of 69  Figure 16: The eHealth DSI Business View As stated before (see above, Secure Context Establishment figure), it has been chosen not to have the Circle of Trust security service appear in order to help reading the overall eHealth DSI business processes. 5 Information System View The Information System View provides a blueprint for the individual application systems to be deployed, the interactions between the application systems, and their relationships to the core business processes of the organization with the frameworks for services to be exposed as business functions for integration. Because of the sensitive context of transmitting medical data special attention is given to security and legal issues (e.g. levels of trust, operator access rights, and patient consent). The cross-country exchange of medical data does not only provide legal challenges but first and foremost problems regarding the structure and content of such information. This chapter defines the structure and the high level behaviour of a NCP while the next chapter (Technology View) defines the technology mapping. 5.1 From Business view to eHealth DSI Information System Each block described in the Business View requires Services to operate. A service represents a unit of essential functionality exposed to others participants from which the eHealth DSI Architecture is structured. The highest level for eHealth DSI services is consistent with the building blocks introduced previously. The information system view of eHealth DSI focuses on NCP services. The blocks are the basis for NCP services structure therefore applicative functions described in this chapter are related to one of the following parts of a NCP:  eHealth DSI NCP interfaces System Architecture Specification_v2.1.0 Page 23 of 69   internal NCP service architecture  National interface Figure 17: eHealth DSI basic structure The eHealth DSI NCP interfaces regard to services provided and consumed by other NCPs of the eHealth DSI infrastructure. eHealth DSI interfaces are “normative” for an eHealth DSI NCP. A NCP is a "participant" of eHealth DSI world if and only if it is compliant to normative eHealth DSI interfaces in terms of structure, behaviour and security policy. The main part of this service is related to NCP to NCP exchange, but some common utility services can be centralized now or in the future. The National interfaces are the services provided and consumed by a NCP in the “National world”. The implementation of these interfaces, obviously, strictly depends on the specific characteristic and standard adopted by every National Infrastructure. The internal NCP service architecture defines a structure of sub components and relative internal interfaces of a NCP. This set of specification supports the realization of Common Components and can be viewed as a facility for eHealth DSI. Obviously an exception is the subcomponents for the realization of National Interfaces realized on a National basis. The responsibility of this part is to implement: • the business logic (data discovery / Exchange / Transformation services) necessary to expose and consume the eHealth DSI NCP interface with the necessary protocol, schema and terminology mapping from and to the National protocol, schema and terminology • trust services (security) for the handling of the defined security policy (eHealth DSI and National) • audit Services for the realization of the audit requirement • support (utilities) internal services The figure below is a high level representation for eHealth DSI communication across NCPs, Country A and Country B with a more detailed view of the NCP services structure. System Architecture Specification_v2.1.0 Page 24 of 69  Figure 18: eHealth DSI logical view • Data discovery / exchange: group of services to enable message sending either within the country or outside, to another NCP. It includes Patient Identification service • Trust services: ensure trust and notably message or data validation, verification, signature, mapping • Transformation: gather the services for data object schema providing (eHealth DSI pivot format or national format) and taxonomy mapping • Audit: bring together all the application services needed for system traceability • Support: gather the application services needed to ensure service availability, response time, guaranteed delivery and session to access eHealth DSI Each NCP in eHealth DSI World can play the role of consumer and provider of eHealth DSI services and, in the same way, impersonate the corresponding role of consumer and provider of National services. As a consequence, NCP services are parted in internal services and external ones. The figure below illustrates the separation of concerns between eHealth DSI world and national World. It is not the scope of this section to be yet specific about internal and external services. Figure 21 will serve that point later in the document. System Architecture Specification_v2.1.0 Page 25 of 69  Figure 19: Services regarding national and eHealth DSI domains 5.2 Descriptions of the eHealth DSI services In the following sections the elaborated eHealth DSI services are subdivided into Trust & Audit (covering services related to security issues) and Data Exchange & Transformation (covering services related to any data exchange out of or through the eHealth DSI domain). Furthermore the services are subdivided into internal (living within the eHealth DSI domain) and external (living within the national domain) services. Some services are related to both domains. Support services are discussed in the section dedicated to eHealth DSI Central Services. Figure 20: Services "zoning" Overview System Architecture Specification_v2.1.0 Page 26 of 69 5.2.1 Trust – Audit Services The proposed Information System View, later described in chapter security clearly separates the European security context and the national security context. The separation is realized by the logical component National Contact Point (NCP) which is connected to the eHealth DSI and the National Infrastructure via dedicated interfaces. Each interface has its own network security, own PKI and own semantics as cryptographic standards, taxonomy and messaging. From the eHealth DSI point of view, there is one and only one NCP per Country mediating all communication related to the involved countries. According to the description of the NCP functionality, two (security) domains representing the levels of trust have been identified: the eHealth DSI security domain and the national security domain. While the eHealth DSI security domain covers all communication between two NCPs and ensures data protection and privacy, the national security domain ensures the national policies between the NCP and its national gateways. Figure 21 shows the different way to establish End-to-End Trust: 1. Brokering trust by linking security contexts, 2. Pretending End-to-End security by brokering security objects, 3. True End-to-End Trust by using End-to-End security objects. eHealth DSI implements (1) for confidentiality and (2) for integrity and authenticity. Figure 21: Security Context ("trust Chain") eHealth DSI NCPs set up a “Circle of Trust” which is instantiated by the respective communicating gateways. Each NCP as a legal entity guarantees that each communication initiated or accepted by one of its gateways complies with the eHealth DSI security policy, the respective national legislation and all additional agreements among the cooperating countries. It even more guarantees for the integrity and authenticity of its gateways by providing the respective gateway certificates. The eHealth DSI Circle of Trust defines the actors and transaction for the management and establishment of mutual trust relationships among eHealth DSI gateways and for the operation of a secure channel between these gateways. Thus, it provides a foundation for setting up and maintaining a closed network of trusted nodes on top of an insecure network (e. g. the internet). The Circle of Trust profile makes use of Transport Layer Security (TLS/SSL) to establish connection between System Architecture Specification_v2.1.0 Page 27 of 69 country A and country B; and VPN (ipSec) must be used to protect data flows between the 2 NCPs, as well as for signing the SAML assertions (see Chapter “Technology View”). 5.2.1.1 Internal & External Services Internal & External services are services which are available within the eHealth DSI infrastructure and the interface for the national infrastructure. NCP_Audit_Service: The service is responsible for auditing of every data access or attempts. There are two aims of auditing, first to satisfy the data privacy law regarding the right of data sovereignty of the patient and second the non-repudiation of origin. It is assumed that the audit trail includes information encoded in eHealth DSI taxonomy in addition to information encoded in national taxonomy. Therefore it is spread over both domains in the model. The component must facilitate the non-repudiation of the actions of every involved party on a technical and organizational level for each and every transaction successfully processed or denied (e.g. prescribing doctor, dispensing pharmacist, NCP routing/mapping, data resource URL retrieval, patient’s identifier query). 5.2.1.2 Internal Services Internal services are services residing on the eHealth DSI internal side. NCP_Security_Service_epSOS: This security service is responsible for the verification and affirmation of integrity, authenticity and confidentiality of each transaction within the eHealth DSI domain (e.g. between NCPs, localization services). Therefore it is able to validate signatures and check the status of certificates that are assigned to its security domain. P_ID_Provider: This service is responsible for uniquely identifying a patient within eHealth DSI by discovering the unique patient identifier referring to the home community of a patient and the patient identifier that must be used for querying for patient data within that community. 5.2.1.3 External Services External services are services connecting the eHealth DSI infrastructure with the country’ national infrastructure. HCP_ID_Provider: This service is responsible for providing a unique Id for a HP within eHealth DSI, which has to be provided by national authorities. NCP_Security Service_National: This security service is responsible for the verification and affirmation of integrity, authenticity and confidentiality of each transaction within the national domain (e.g. between HPs and NCP, authorization services). Therefore it is able to validate signatures and check the status of certificates that are assigned to its security domain. HCP_Confirmation_Service: The component HCP_Authorization_Service provides and controls the consent assertion that is needed to transport the authorization of the HP by the patient. 5.2.2 Data Exchanges – Data Transformation Services 5.2.2.1 Internal & External Services NCP_Semantic_Service: The mapping of medical information and taxonomy is done by the semantic services therefore this component belongs to the System Architecture Specification_v2.1.0 Page 28 of 69  internal and external domain. To facilitate a faster implementation we propose the development of an outline for an interface where the most common format is described. 5.2.2.2 Internal Services NCP_Localisation_Services: The service locates the communication counterpart (NCP-A) and has access to locate tables and maps country IDs to endpoint URLs. It provides the means to discover and access medical resources, while storage is left to national implementation. Localization of data is done via location independent Unified Resource Names (URN), provided by an URN-Resolver, which can be transcript to URLs referring to the concrete data store. 5.2.2.3 External Services NCP_Message_Adapter: The adaptation of the national communication protocol is done by the NCP_Message_Adapter, e.g. the splitting of ePrescriptions or the correlation of related messages. It lives in the national domain, because the eHealth DSI internal business logic depends on information provided by the existing national infrastructure. 5.2.3 eHealth DSI support Services There are a number of information sources which are relevant for every NCP and must be in the same state for every NCP. Examples for this are common taxonomies, schemas, and WSE addresses of NCPs. This shared data is centrally managed in order to avoid inconsistencies and version conflicts in a generalization process of eHealth DSI. Services3 are implemented within a NCP by using a static configuration table. It is the responsibility of each NCP to keep the configuration up to date from centrally managed data storage. Each NCP MUST be in charge to manually download new version of any updated data. This operation can be done with a secure method (via SSL, TLS, or SFTP) to upload / download files to and from FTP servers. 5.2.3.1 National Contact Point Routing Table The Locate central function is a simple NCP Routing Table which facilitates the connections between two NCPs. This service is independent of the form of distribution (e.g; centrally maintained, replicated or locally maintained copies) and can be made available as an XML-document. It is maintained locally. This information is encoded in a NCP configuration file. Each NCP MUST hold a copy of the configuration files of all the other NCPs. 5.2.3.2 Trusted Certificates Certificate services are country issues. Technical trust in country A is established by acknowledging the certificates that were announced by country B and vice versa after legal trust confirmed. Certificates from different certificate service providers should be used per communication layer (VPN, TLS, WS-Security). 5.2.3.3 Taxonomy for the eHealth DSI pivot format central function The Taxonomy central function serves as a library for all existing and valid eHealth DSI pivot formats and all relevant schemas. This information should be robust most 3 Term Service does not mean a web service to synchronise local and remote data, but instead a function link to a manual process for eHealth DSI. System Architecture Specification_v2.1.0 Page 29 of 69 of the time and not to be changed. Therefore this information can be duplicated into each NCP. This should also be relevant for later performance issues. It is the responsibility of each country A to keep the configuration up to date for the NCP. 5.2.3.4 Traits Handshake central function NCP-A and NCP-B should be able to agree on the identity traits that have to be provided by country B in order to identify a patient. Information on which traits are required for which country are coded within a static client-side configuration. It is the responsibility of each country B client/portal to keep the configuration up to date. 5.3 NCP considerations As stated before, a national contact point (NCP) is the single legal representative of a Country’ eHealth DSI services that guarantees the compliance of all the country’ eHealth DSI services with the eHealth DSI information governance. All communication to or from a national health care system of a country is done through its NCP; direct access to national services MUST NOT be possible. Therefore the NCP is the very basic node entity within eHealth DSI. This logical component can be addressed via two clearly separated interfaces (NCP_IF_National and NCP_IF_EPSOS from figures in chapter 5), each one accessible out of the according network (figure 20). While the concrete implementation of a NCP has to be done by the according country, the interfaces defined in the chapter Technology View must be served according to eHealth DSI specification. Underneath the shield of a single NCP a country may deploy multiple communities where each community is running its own instances of eHealth DSI services to serve the HCPOs, HPs, and patients that are assigned to the community. Access to a community’s eHealth DSI services is mediated through a community gateway that is established as part of the NCP. Typical examples of communities are regions running their own health services and Cross Enterprise Document Sharing (as agreed XDS Profile) affinity domains as networks of co-operating healthcare enterprises. Countries with centralized health services are assumed to be a single community. Each community is identifiable by a unique ID administrated by the country’s NCP. The next figure shows a conceptual view of the basic NCP architecture. The diagram shows the scope of eHealth DSI and the responsibilities of the NCP. System Architecture Specification_v2.1.0 Page 30 of 69  Figure 22: high Level Architecture of an eHealth DSI NCP The following figure gives a more detailed view on the composition of the NCP. As explained before each NCP works as an interface between the national infrastructure of the country and the eHealth DSI domain. Each NCP hosts services which work in different contexts and have strongly separated responsibilities. Figure 23: Detailed Composition of NCP components System Architecture Specification_v2.1.0 Page 31 of 69 5.3.1 NCP Interface to national domain The interface that connects the NCP to the national network (NCP_IF_National) is composed of the sub interface to request a patient ID (IF_PID_Requestor), the sub interface that is used for the applications ePrescription (eP) and Patient Summary (PS), both served by IF_Medical_Data and the sub interface that is used to request a HP identity assertion (IF_HCP_ID_Provider). Processes and components beyond the interface that connects the NCP with the national infrastructure (NCP_IF_National) are not part of the eHealth DSI specifications. 5.4 Security considerations Since eHealth DSI deals with medical data, there is a need to implement strong security mechanisms to ensure the authenticity, integrity and security of this data. The basic security principle in eHealth DSI is the “circle of trust”, which means that each and every NCP trusts its peers from other Countries. In addition to this basic principle, several additional security services are needed to provide the necessary level of security. For a more detailed description of these services (see [Security services specification]). The security services are the following: 1. Access control: It MUST be ensured that only authorized HPs can retrieve data from eHealth DSI. Each NCP is responsible for accepting or rejecting an authorization request of a HP of its country. For all NCPs are to trust each other a HP only needs to authenticate at the NCP of his country. Data exchange MUST follow the national law of the involved country. Implementation lies in the responsibility of the involved NCPs of the countries. It MUST be ensured, that the data transmitted within eHealth DSI stays intact to ensure the safety of the patient. 2. Data Confidentiality: Since medical data is a highly sensible data it MUST be ensured that no unauthorized party is allowed access to this data. 3. Non Repudiation: Non-repudiation of origin MUST be ensured by each NCP. It therefore logs every transmission and the involved parties (see auditing services) and enables signing and encryption mechanisms not only between NCPs but also between HP/HCPOs and NCPs. 4. PKI: For the certificate management a PKI is needed which acts as a CA and administrates a list of trusted eHealth DSI certificates and a revocation list. 5. Auditing and Accounting: Each NCP logs each and every data access (and every party accessing the data) via its interfaces. For proper traceability this service includes a time service synchronizing all NCP-clocks. 5.5 Information Objects This chapter comprises data objects administrated by the NCP. The following figure gives an overview of the necessary business objects and their relation. These objects are more closely described in course of this chapter. System Architecture Specification_v2.1.0 Page 32 of 69  Figure 24: Schematic representation of the Data Objects and their relations 5.5.1 Healthcare Professional (HP) A Healthcare Professional is a physician participating in eHealth DSI identifiable by its unique id. It is affiliated to zero or more HealthCare Professional Organizations, depending on national legislation. A HP is related to 0..n HCPOs and is associated with 1..n Healthcare Professional Addresses. System Architecture Specification_v2.1.0 Page 33 of 69 5.5.1.1 Healthcare Professional Address Healthcare Professional Address is related to 0..n HPs. Since a Healthcare Professional Address can be in the system, even though an HP is removed from the eHealth DSI context, this address doesn’t necessarily have to be deleted, therefore an address belonging to no HP SHOULD be allowed. 5.5.1.2 HealthCare Professional Organization A HealthCare Professional Organization is a logical entity within the national environment known to the NCP and uniquely identifiable by its id. A HCPO is related to 1..n HPs. At any given time in the context of an eHealth DSI transaction, an HP MUST be associated with only one HCPO. 5.5.2 Patient A patient is an individual person participating in eHealth DSI by giving permission (prior consent) in his home community to process his/her medical data to a foreign country. Within his home country each patient is assigned to a single community that can mediate access to that patient’s PS and ePrescriptions. This community is called the patient’s home community. It may be possible that, in future projects based on eHealth DSI, data of each patient is being managed in multiple communities but this scenario is out of scope of eHealth DSI. For participating in eHealth DSI the patient has to give within his home community his permission (consent) for the usage of his data by eHealth DSI (prior consent). Additionally the patient has to give its permission for the actual usage of its data in the foreign country by explicitly authorizing a health care operator to do so (activation of an existing consent). Alternatively the involved HP in country B may request an emergency access to the patient’s data (e.g. in case the patient is not responsive). This access has to be handled by the NCP in regard to country A’s legislation (country A can accept or decline this request). A patient MUST be related to 0..1 PS, 0..* ePs and 0..n eDispenses. 5.5.3 Patient Summary (PS) The patient summary contains the patient’s medical information. The patient summary may also include the medication summary. As previously stated every access to the Patient Summary and ePrescription data is read only4. There will be no write access to this data within eHealth DSI. Figure 25 shows the lifecycle of a PS within eHealth DSI. The PS is available if the patient has agreed to take part in eHealth DSI, and is not available if the patient decides not to take part in eHealth DSI anymore. 4 Actually, patient summary and prescription data are provided through services, therefore the actual national database is not accessible directly. System Architecture Specification_v2.1.0 Page 34 of 69  Figure 25: Life cycle of the Patient Summary Every PS MUST be related to exactly 1 patient. 5.5.3.1 Medication Summary The Medication Summary is not requested as an OPTIONAL part of the PS, but it is left to country the responsibility to define mutual agreement for Medical Summary. 5.5.4 ePrescription (eP) The eP object contains information about the medicine prescribed in country A. The status management of the eP is an internal country affair (i.e. it may differ from country to country). The minimum basic status is “Available” or “Not Available” as presented for the Patient Summary. Figure 26 shows a suggested lifecycle for an eP. When looking at the lifecycle the following states can be reached by an eP: 1. Ordered: This state is reached when the prescriber has written the eP and the eP is included in the patient’s electronic health record (EHR). 2. Placed: This state is reached when the ordered eP has been recorded into the national/regional eP service and is now ready to be accessed by the dispenser. 3. Cancelled: This state is reached if the eP is invalidated before dispensed completely. 4. Suspended: If an eP can be dispensed more than one time and requires a certain time span between dispensions, the eP assumes the state Suspended in this time. It reaches the state partially dispensed when the eP becomes available again. 5. Partially Dispensed: If a single ePrescription contains multiple items - or items which can be multiply dispensed - it reaches this state if the eP is not dispensed completely. 6. Completed: This state is reached when all ePrescription items have been fully dispensed. 7. Closed: This state is reached if the eP loses its validity before it has been fully dispensed (e.g. the eP’s time validity has run out, or the patient has withdrawn consent). System Architecture Specification_v2.1.0 Page 35 of 69 An ePrescription with a given consent is valid for the duration defined by country A and may contain multiple ePrescription Items which may not all be dispensed in one transaction. An eP MAY include multiple but MUST include at least one ePrescription item. Every eP is related to exactly 1 patient. Figure 26: Suggested Lifecycle of an ePrescription 5.5.5 eDispense In eHealth DSI the event of a patient’s eDispense is handled via a notification message from country B to country A. Country A has to decide how to handle the eDispense event. Since an ePrescription may contain multiple ePrescription items, it must be possible to allow multiple eDispenses for one ePrescription. There are two ways for the NCP to handle multiple eDispenses: • If not all eP Items have been dispensed as seen in the notification, generate a new eP containing only the non-dispensed medicines. This is a task of the HCPO. Nevertheless, according to every country legislation, this option may be implemented at the NCP level. • If not all ePrescription Items have been dispensed, return the original ePrescription again and raise an error if a notification is received on an already dispensed medicine. This requires that the pharmacists MUST wait for the result of the notification before the pharmacist can dispense the medicine to the patient. The eDispense object contains information about a dispensed eP. A Dispense MUST be related to exactly one dispensing HP. System Architecture Specification_v2.1.0 Page 36 of 69 Service Internal External Data Object NCP_Audit_Service X Healthcare Professional (HP) NCP_Security_Service_epSOS X Healthcare Professional Address NCP_Security_Service_National X HealthCare Professional Organization (HCPO) HCP_Authorization_Service Patient NCP_Semantic_Service X Patient Summary (PS) NCP_Localisation_Services Medication Summary X NCP_Message_Adapter ePrescription X P_ID_Provider Dispense X X HCP_ID_Provider X X Internal Services at National level are not described in this document. The document does not aim at changing the National Infrastructure and does not provide any guideline for this task. Internal Service presentation is only presented to ease the comprehension of the whole NCP. The National Connector MUST wrap Internal Services. This document proposes the interface for the National Connector as it is described in the Technology View chapter (components description), not its implementation. At the other hand, Internal Services are technically described, starting with the next chapter: Technology View. 6 Technology View The scope of this chapter is to give the webservices stack view of eHealth DSI in order to build systems and infrastructures needed for operations. This chapter is addressing: • The description of services and its external interface, • The mapping of transactions and profiles with identified services and interfaces. On this basis, the intent of this chapter is to help the countries completing their own call for tender in order to prepare the system. 6.1 From Information System view to Technology view The primary reason for developing technological view is to support the application by providing the fundamental technology and solution for eHealth DSI: Information System Architecture Specification_v2.1.0 Page 37 of 69 system view on the previous chapter needs to get implemented. To do so, eHealth DSI profiles - acting as basic unit manipulated in the architecture - are integrated. Furthermore, the Technology View details the structure and relationships of the technical services provided by the Gateways, how the components will work, and how technology will support the eHealth DSI’s application goals. This makes a responsive asset for a successful technological model. The technological view addresses this need, by providing a context of the system in response to the changing needs for the data PS and eP exchange environment. Finally, the Technological View enables to achieve the right balance between efficiency and requirements. In essence, it aligns the eHealth DSI business view and system information view. At the same time, it assures the needs of the composition for integrated components. 6.2 eHealth DSI platform 6.2.1 Foreword The eHealth DSI platform aims to allow the “pan-European health data exchange in a regular and easy manner without changing existing national healthcare infrastructures and legislations, within a trust framework (contracts and agreed policies) among countries”. This task is accomplished through a Business-to- Business cooperation of a set of national gateways (the technical embodiment of National Contact Points) under a mutual circle of trust. The notion of platform in eHealth DSI context must be applied with some careful specification. The term “platform” is inherently relative. For this reason, the eHealth DSI architecture has its specific “normative” platform model in “service space”. The choice at this level is the WS* stack and some supporting eHealth standard and open specification. However, some architectural definition is outlined in a Platform Independent flavor5: eHealth DSI gateway “internal” components architecture can be implemented with different specific low-level technology platform. 6.2.2 eHealth DSI Domains The following figure illustrates the different domains of eHealth DSI outlined in Chapter “Business View”. Domains categorize those capabilities: • National infrastructure (National Infrastructure of HP and HCPO) • National communication layer • Business layer • eHealth DSI communication layer 5 with “Platform Independent Model” and “Platform Specific Model” we make an explicit reference on a Model Driven terminology (see www.omg.org/mda) directly. System Architecture Specification_v2.1.0 Page 38 of 69  Figure 27: eHealth DSI domains view This does imply technically: 6.2.2.1 eHealth DSI communication layer eHealth DSI communication layer includes components with common Interfaces that MUST be considered as “normative” with Web services that use open, XML-based standards and transport protocols to exchange data between Gateways. 6.2.2.2 Business layer Business layer does implement components specified in a Platform Independent model (e.g. java or C#) for this document. This layer includes all components and their specific interfaces, to resolve specific business functions of eHealth DSI. The components in this layer do not directly communicate to the national infrastructure or exchange messages with other NCPs. 6.2.2.3 National communication layer National communication layer Infrastructure interfaces are strictly related to national infrastructure and specified only at functional level, hence they are described as abstracted from the application type (national responsibility). Only the Interfaces of the components can be described, but the implementation is more a national concern because of the heterogeneity of national infrastructure. 6.3 eHealth DSI Technical Architecture 6.3.1 Introduction The eHealth DSI platform model can be viewed as federations of services connected via specified contracts that define their service interfaces. The resulting system design is a Service Oriented Architecture (SOA). For the eHealth DSI basic goal of interoperability, SOA is a relevant architectural style: it can decouple interface and implementation as well as avoid dependence or future rigidity. In an SOA solution, the only characteristic of a service that a requesting application needs to know about is the “public” interface. Countries can decide to run the business logic under different operating environments, with different languages and framework or different internal solution architecture. As defined previously the normative technology platform for eHealth DSI SOA is the web services stack. The design of the general architecture of eHealth DSI and the design of the eHealth DSI services is based on the following basic assumptions: 1. The design uses the service-oriented paradigm. System Architecture Specification_v2.1.0 Page 39 of 69  2. All services are passive, the Service Consumers and Service Providers communicate synchronously. 3. All eHealth DSI medical data as well as all patient and HP identity data is administered in autonomous systems. Any exchange of these data is mediated by national gateways following a B2B paradigm. 4. The federation of NCPs is implemented via a »circle of trust«. 6.3.2 Service Architecture Capabilities required by the eHealth DSI are implemented through the architecture described hereafter. SOA is an architecture that enables business agility through the use of common services. The service-oriented paradigm distinguishes among three roles: service provider, service consumer, and service registry. The service provider offers a service that is used by the service consumer. The service provider can publish a description of the service in a service registry. eHealth DSI services are implemented as Web Services whose interfaces are specified with the Web Service Description Language. eHealth DSI Web services are passive. Communication between services consumer and service provider is always initiated by the service consumer. The service provider is passive and reacts to inquiries from the service consumer. The communication between service consumer and services provider is synchronous. The service consumer’s control flow is disrupted until the service provider has processed the service consumer’s request. Service consumer and provider communicate over the Internet using XML-based SOAP messages transported via the HTTP protocol. Each eHealth DSI service is operated under the responsibility of a National Contact Point (NCP). The role of the service consumer is always taken by NCP of country B (country of care). The role of the service provider is always taken by NCP of country A (country of affiliation). A service registry is not used. Instead it is assumed that service descriptions and service location information is made available for service consumers by organisational means and static local directory services. This figure below represents the collaboration among the participant of eHealth DSI Service Architecture6. Along with the UML stereotype «ServiceContract», the main service contract is represented: it defines the interface provided and consumed by the main components (participants). 6 The representation makes use of UML profile for Services (SoaML, see http://www.omgwiki.org/SoaML/doku.php.). System Architecture Specification_v2.1.0 Page 40 of 69  Figure 28: Core eHealth DSI technical service architecture Moreover Gateways interact with the National Level as well through NationalServices, in order to allow national infrastructures to get the eHealth DSI capabilities, which is the resulting action of eHealth DSI. The eHealth DSI Gateways interacts externally towards the eHealth DSI network for these purposes: • The exchange of eP, PS and eDispense documents is implemented respectively with OrderService, PatientService, DispensationService, ConsentServices service contracts. • The Patient Identification is done with the service IdentificationServices. • Regarding this service, Gateway plays both a consumer and provider role. • Operating system (e.g. Linux) enables to configure time synchronization for eHealth DSI. • Extra inner/outer Services inside of the gateway such as security, transformation, external and internal communication will be described along the following chapters. NB: • Security concerns are not mentioned in this schema but are detailed further in the chapter Security. • The epSOSWebFrontEnd Portal component is part of NCPeH Architecture specifications. But the epSOSWebFrontEnd Portal component remains the countries decision according to their existing architecture7. The details about these services interfaces are described in chapter 6.5, following the components and composite structure description. 7 This component is an implementation of a UI Mediator pattern (http://www.soapatterns.org/ui_mediator.php see Thomas Erl, SOA Design Pattern, Pretience Hall, 2009). The epSOSWebFrontEnd in this way establish mediator logic responsible for ensuring timely interaction and feedback with user-interfaces and presentation logic. System Architecture Specification_v2.1.0 Page 41 of 69 6.4 Composite Structure In this section the link between services and technical components describe the composite structure. Figure 29: Composite Structure of the NCP Gateway Implementation This figure represents an implementation of the NCP. Any other implementations would remain possible as long as all the business functional requirements are respected. For instance, the WorkflowManager component is not mandatory, but the business operations associated to the Manager are mandatory. NCP Gateway implementation component offers service and request ports both to the eHealth DSI network (“normative” interfaces) and to the National Infrastructure (country specific interfaces). The gateway internal structure is organized to accept/send messages from other NCPs with the InBoundProtocolTerminator/OutBoundProtocolTerminator. The WorkflowManager acts as a controler and composes the flow between others component. The SecurityManager is under the control of the WorkFlowManager, as it is for the TransformationManager. The dedicated task to communicate with the National Infrastructure in done by the NationalConnector. 6.4.1 Layers Description All the mentioned services are implemented through the NCP gateway under the following layers. System Architecture Specification_v2.1.0 Page 42 of 69 6.4.1.1 The National Communication layer • The InboundProtocolTerminator acts as the entry point for any eHealth DSI messages, it adapts the entry to the inner components like the WorkFlowManager • The OutBoundProtocolTerminator plays the opposite role of the InBoundProtocolTerminator by adapting messages from inner NCP components for other NCPs. 6.4.1.2 The business layer • The SecurityManager is a guarantor for eHealth DSI protection and integrity. • The TransformationManager turns eHealth DSI pivot into national schema and vice versa. • The TerminologyServiceAccessManager is translating a given concept designation into the requested target language as well as transcoding a given “local” coded into the appropriate eHealth DSI coded. • The WorkflowManager, as a role of a controller which does interact with other components (e.g. InboundProtocolTerminator). It helps the structured implementation for the wave 1, inspired by the MVC IT pattern8. 6.4.1.3 The National Communication layer • The NationalConnector is in charge to link Business NCP components to the national Infrastructure. Authentication and authorization service for local HP is included in the NationalConnector. • A PolicyManager can be added is needed, but for a sake of simplicity it is not include in the figure “Composite Structure of the NCP Gateway Implementation”. 6.4.1.4 The Platform layer • ConfigurationAndMonitoringManager manages configuration and monitors components. • The Audit Trail support eHealth DSI all transactions that must be audited (other component such as AuditTraitsRepository can be added). How these components interact to support the Data Exchange and the Patient Identification scenarios are described in Section Component Communication. NB: An authentication and authorization service for local HP is included in the NationalConnector. 6.4.2 Components Description • Components are part of the starting eHealth DSI platform for service orientation throughout software engineering. They are often mapped with services able to fulfil eHealth DSI requirements. • In the following text, DocumentID is considered to be an OID (Object IDentifier). • HP identification/authentication and consent confirmation (or Treatment Relationship confirmation) implementation is left to country but SAML assertion is required for safeguarding business requests. 8 http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller. System Architecture Specification_v2.1.0 Page 43 of 69 6.4.2.1 Inbound Protocol Terminator Figure 30: Inbound protocol Terminator The InboundProtocolTerminator is the entry point for an eHealth DSI message arriving in the NCP. The InboundProtocolTerminator component plays the role of a service provider SOAP web services for other NCPs. The InboundProtocolTerminator performs verification of WS-Security SAML tokens and deserializes SOAP message into objects for the use of WorkflowManager. It adapts messages to the components inside of the NCP. WebService implementations provided by the InboundProtocolTerminator are the following: • Patient Identification Service • Patient Service • Order Service • Dispensation Service • Consent Service The InBoundProtocolTerminator renders the eHealth DSI medical data into a form suitable for the WorkFlowManager. System Architecture Specification_v2.1.0 Page 44 of 69 6.4.2.2 Outbound Protocol Terminator Figure 31: Outbound protocol Terminator The OutboundProtocolTerminator plays role of a service consumer. It serializes message objects in a SOAP request, adds corresponding WS-Security tokens and routes it to the NCP addressed by the country of affiliation of the patient. When the response arrives, it performs the deserialization of the SOAP response into object instance for the use of the WorkFlowManager. The OutboundProtocolTerminator is able to communicate over the network to other NCPs, because it is a consumer, it acts as a client and can query services located to the InboundProtocolTerminator. Even if this component is not needed for a business purpose, it realizes the adaptation of messages. With the ProtocolTerminators eHealth DSI get a structured organization for a dedicated task to a specific component. System Architecture Specification_v2.1.0 Page 45 of 69 6.4.2.3 Workflow Manager Figure 32: Workflow Manager The WorkflowManager conducts the invocation of components to process requests. In software architecture this component isolates business logic from input and presentation to other Component. It eases independent development, testing and maintenance. The WorkflowManager runs the eHealth DSI medical data and add new logic for example, calculating if the patient has given his consent or not. Different views can exist for the same data (e.g. Patient Summary), and depends where the data is located (Business zone, NationalConnector zone, eHealth DSI zone), but the WorkflowManager receives the suitable data because the other components adapt the business model to the behavior of the WorkflowManager. The WorkflowManager that contain the business rules knows how to carry out specific tasks to other components. System Architecture Specification_v2.1.0 Page 46 of 69 6.4.2.4 Transformation Manager The TransformationManager component is in charge of the following activities: Translating and/or transcoding (if necessary) the original data compliant to eHealth DSI CDA syntax from the national language and possibly from the national code system(s) in the document creator country (in most cases Country A) to the eHealth DSI Reference Terminology. Creating an eHealth DSI unstructured CDA by embedding the original data from document creator presented in the pdf format. This data must be presented in a pdf format so that the document consumer country can read it. Translating the coded data elements from the eHealth DSI Reference Terminology to the national language in document consumer country (in most cases Country B). Note: That a relationship Must exists between the eHealth DSI pivot document and the embedded PDF CDA. Figure 34: Transformation Manager ToEpSOSPivot(EpSOSOriginalData_ReplacedDocId) :EpsosCDA Textual description of operation Transformation of national data to eHealth DSI pivot format : After having received a toEpSOSPivot() request, this component takes the EpSOSOriginalData (already compliant to eHealth DSI CDA syntax) and using the TAS capabilities, accomplishes the eventual transcoding of the terms present in the eHealth DSI value sets, while also keeping the original codes and display name. An eHealth DSI pivot document with eHealth DSI coded concepts is therefore produced. The eHealth DSI pivot document shall to have a link to the EpSOSOriginalData. Exceptions: in case of processing error or warning the responseStatusStructure should be properly valorized. System Architecture Specification_v2.1.0 Page 47 of 69  Input parameters EpSOSOriginalData : Medical document in its original data format as provided from the NationalConnector to this component. [Mandatory] ReplacedDocId is an instance identifier describing the document to be replaced. Output parameters EpSOSCDA structure Response structure including the eHealth DSI pivot CDA and the response status structure. The response status structure provides information about the operation results, including possible errors and warning. Notes ToEpSOSPDF(EpSOSOriginalData; OriginalPDF ) : EpSOSPDF Textual description of operation Transformation of national data to eHealth DSI pivot format : After having received the ToEpSOSPDF() request, this component takes the EpSOSOriginalData and the OriginalPDF and generates an unstructured CDA embedding the PDF using the information already present in the eHealth DSI original data. As a final result the PDF embedded CDA is returned to the requesting component. The embedded PDF CDA shall to have a link to the EpSOSOriginalData. Exceptions: in case of processing error or warning the responseStatusStructure should be properly valorized. Input parameters EpSOSOriginalData Medical document in its original data format as provided from the NationalConnector to this component. [Mandatory] OriginalPDF Printable representation (PDF/A) of the original national data as we expect have been seen by the originator HP [Mandatory]. Output parameters EpSOSPDF structure response structure including the eHealth DSI unstructured CDA embedding the original pdf and the response status structure. The response status structure provides information about the operation results, including possible errors and warning. Notes Translate (EpsosCDA; TargetLanguageCode) : TranslatedEpSOSCDA System Architecture Specification_v2.1.0 Page 48 of 69  Textual description of operation Translation from eHealth DSI pivot data to consumer country language : After having received a translate() request, this component starts to process the received EpsosCDA in order extract the eHealth DSI coded concepts. Subsequently, for each coded concept found, it makes use of the TSAM capabilities for the purpose of obtaining the representation of that concept in the target TargetLanguageCode identifier. This information is therefore used by this component to update the displayName attribute of that coded entry. After the completion of this translation phase, an eHealth DSI pivot document with “translated” concepts is obtained. This document is therefore returned to the requesting party. No changes are applied to the document identifiers. Exceptions: in case of processing error or warning the responseStatusStructure should be properly valorized. Input parameters EpsosCDA Document in eHealth DSI pivot format (with eHealth DSI codes) TargetLanguageCode. Identifier (code) of the target language. Output parameters TranslatedEpSOSCDA eHealth DSI pivot CDA with translated eHealth DSI codes into the consumer country language. Notes 6.4.2.5 Terminology Access Manager Terminology Access Manager has two roles: • Translating a given concept designation into the requested target language using the information present in the Terminology Repository. Translation stands for the capability of associating to an eHealth DSI coded concept the localized concept description or display name: i.e. the translation into the target language of the “concept” conveyed (e.g. code “30001000” EDQM can have the display names “Φύσιγγα”, “Ampulka” or “Ampoule”, depending on where it is used.). • Transcoding a given “local” coded concept into the appropriate eHealth DSI coded concept using the information present in the Terminology Repository. Transcoding means the capability of getting the eHealth DSI quasi- synonymous9 associated to a “local” coded concept. 9 i.e. a coded concept derived from the appropriate eHealth DSI Value Set semantically equivalent to a given coded concept. System Architecture Specification_v2.1.0 Page 49 of 69  Figure 35: Terminology Access Manager The eHealth DSI Reference Terminology has as a starting point the eHealth DSI MVC (Master Value Sets), which in turn is the basis for the eHealth DSI MTC (Master Transcoding Catalogue). The mapping activity from the “local” coded concept to the eHealth DSI Value Sets present in the eHealth DSI MVC is out of scope of eHealth DSI and it is the responsibility of the National Linguistic Competence Centers from each country. getEpSOSConceptByCode(LocalConcept) : TranscodingResponseStructure Textual description of operation Transcoding a given “local” coded concept into the appropriate eHealth DSI coded concept using the information present in the Terminology Repository. This component issues a getEpSOSConceptByCode () request in order to know the best matching eHealth DSI Concept, according to the information provided. Input parameters LocalConcept; the LocalConcept structure in order to search within the Terminology Repository for the best matching eHealth DSI Concept, according to the local information provided (e.g., if no code system version is indicated, the latest version will be provided). System Architecture Specification_v2.1.0 Page 50 of 69  Output parameters TranscodingResponseStructure Response structure including: 1. the eHealth DSI Reference Concept: this means the Concept Code, the English designation, the concept code system (OID), Code System Version, Value Set OID; Value Set Version, 2. The responseStatusStructure, providing information about operation result, including possible errors and warning. Exceptions in case of not existing transcoding or processing error the responseStatusStructure should be properly valorised getDesignationByEpSOSConcept(EpSOSRefConcept; TargetLanguageCode) : TranslatingResponseStructure Textual description of operation Translating a given concept designation into the requested target language using the information present in the Terminology Repository : This component issues getDesignationByEpSOSConcept () request in order to know the target language eHealth DSI Designation, according to the information input parameters provided. EpSOSRefConcept EpSOSRefConcept structure in order to search within the Terminology Repository for the target language eHealth DSI Designation, according to the local information provided Output parameters translatingResponseStructure Response structure including: 1. the target language concept designation; 2. the responseStatusStructure providing information about operation result, including possible errors and warning. Exceptions in case of not existing translation or processing error the responseStatusStructure should be properly valorised 6.4.2.5.1 Interaction diagram for semantic This section describes the two interaction uses in which the Semantic Components are involved: System Architecture Specification_v2.1.0 Page 51 of 69  Figure 36: eHealth DSI CDA translation This interaction is used for the purpose of obtaining the eHealth DSI pivot CDA and the CDA with the original PDF embedded. It shows the WorkflowManager to ask for the translation of the eHealth DSI CDA document. System Architecture Specification_v2.1.0 Page 52 of 69  Figure 37: Transformation to eHealth DSI CDA This interaction is used for the purpose of obtaining a translated version of the eHealth DSI pivot CDA into the target language. 6.4.2.6 Security Manager The SecurityManager component is responsible for creation and verification of digital signatures that are applied to medical documents. Figure 38: Security Manager sign(CDATA) : Signature Textual description of operation This operation processes a XML DSig signature for a given XML according to the XML DSig standard and the eHealth DSI specifications. Only known documents are signed and before the signature processing a schema validation is done. The documents that are known are configurable. Input parameters CDATA XML Document to sign Output parameters SignedDocument checkSignature(CDATA, Signature) : CheckSignatureResult Textual description of operation The XML DSig signature of a XML document is validated including the validation of the certificate that confirmed the signature. Input parameters CDATA XML containing Signature Digital signature Output parameters CheckSignatureResult Encoded in the status information are Validity of signature Validity of certificate Notes All the known and trusted certificates have to be registered by configuration beforehand. System Architecture Specification_v2.1.0 Page 53 of 69 6.4.2.7 AuditTrail This internal component is designed to implement the Audit Trail objectives. This component provides interfaces for the Audit Trail Service acting as service point, in order to keep track of events to be logged. This AuditTrail component is responsible for receiving an EventLog message in an ATNA- compatible way. Figure 39: Audit Component put(EventLog) The AuditTrail accept an audit trail entries in an ATNA-compatible way, encapsulated in the Event Log. This document does not give detail for the storage procedure of the audit records. The Audit Trail function is considered to be sufficient for data non repudiation and traceability, if a failure occurs. 6.4.2.8 Configuration and Monitoring Manager This subcomponent should be responsible for analyzing the audit trail and, based on a configurable way easy to maintain for administrator. Alert should prevent possible abuses (such as excessive requests issued from a HP or a patient is queried from more than one country at a time). Figure 40: Configuration and Monitoring Configuration and Monitoring Manager is responsible for keeping eHealth DSI configuration, at the application boot start, the synchronicity with central eHealth DSI repository (e.g. NCP routing and taxonomy access). Process for Synchronicity establishment is not sketch in this document. The monitoring can detect fraud, according to the security requirements. System Architecture Specification_v2.1.0 Page 54 of 69 6.4.2.9 NationalConnector Figure 41: National Connector This component is designed to implement the objectives related to National Infrastructures connection and National Data handling, only the interfaces can be common between countries. The implementation is a very specific task for each country, and depends and the national infrastructure. To draw a parallel, National Connector is like a plug or a socket as devices for removable connecting the NCP. Country must design the socket to be able to plug to the National Connector. Because plugs over countries can be different, implementation of the National Connector is different. The National Connector maps logical functional Components of the NCP to the national Infrastructure. Country MUST provide storage and be able to handle the medical Data persistence (PS, eP, Consent). The NationalConnector is the entry and exit point from and to the NCP. Countries are free to develop and build the implementation of the National Connector with the interfaces define in this document. Country can export the interface as service, to communicate with the NationalConnector needed. System Architecture Specification_v2.1.0 Page 55 of 69 6.4.3 Components Communication workflow 6.4.3.1 Patient Identification Figure 42: Patient Identification 1. After the HP/HCPO B is authenticated (precondition), the component dataDisplay initiates the searchPatient, by calling the right function located on the NationalConnector. The findIdentityByTraits() needs patient attributes as input arguments (The name of the transaction: findIdentityByTraits() is not mandatory, it is country decision.). All incoming transactions at the NationalConnector are audited by the AuditTrails component. 2. The request is forward to the WorkflowManager, where the business logic starts. 3. The NCP B OutboundProtocolTerminator wraps the request into a SOAP envelope and sends it to the InboundProtocolTerminator in A. Audit Trails B keeps track of what does leave from country B, as the same occurs in country A when the message arrives. Any incoming message that arrives to the InboundProtocolTerminator for the request contains the wrapped information for the patient. Decoding and unwrapping is done inside in the InboundProtocolTerminator. 4. The WorkflowManager extracts the identity traits from the object and uses them as an input arguments when calling NationalController for the findIdentityByTraits() operation. System Architecture Specification_v2.1.0 Page 56 of 69  5. The NationalConnector queries the patient Data result in from the national infrastructure in A and the returns the object to the Workflow Manager. The transcation is audited by the AuditTrails component. The name of the transaction: findIdentityByTraits() is not mandatory, it is country decision. 6. The Traits Patient Response goes back to NCP B throught the same components (1-5), and arrives to the Inbound Terminator in B (previously named OutBoundTerminator when message goes out). Upon the arrival of the SOAP response, both ProtocolTerminator makes a corresponding record in the audit trail. 7. The WorkFlowManager in B receives the unwrapped message from InboundProtocolTerminator and transmit the request to the NationalConnector in B. 8. The Patient Identification Response Traits is returned to the originator of the request, the HP B. System Architecture Specification_v2.1.0 Page 57 of 69 6.4.3.2 Data Exchange (PS & eP) Figure 43: Patient data workflow 1. HP/HCPO B is authenticated and the patient is identified (Precondition). The HP calls for retrieving prescriptions of the patient by calling a corresponding method located at the NationalConnector in B and providing ID of the patient. The call list (the wording: “ListPatientRequest” is not mandatory) is initiated by the HP B data display component (HP B Portal). 2. The AuditTrail component keeps track of the message passing through the NationalConnector. (The same audit is done when the response returns). The AuditTrail is considered to be sufficient for data non repudiation, if a failure occurs. The NationalConnector forwards the request to WorkflowManager. 3. The WorkflowManager forwards the request to OutboundProtocolTerminator (named BoundTerminator on the figure, because the name switches between System Architecture Specification_v2.1.0 Page 58 of 69  In and Out). The SecurityManager function Sign() the message with the NCP-B signature. 4. After the massage passed through the terminators and arrives at the WorkFlowManager in A. The NationalConnector make the appropriate call to the national infrastructure and records the request in the audit trail. The response should contain requested prescriptions in the national format of country A. On the figure, the GetPatientData action and response is a country transaction. 5. The WorkflowManager receives the response from NationalConnector and calls The TransformationManager to obtain the eHealth DSI pivot CDA and the CDA with the original PDF embedded. 6. The WorkflowManager calls the SecurityManager component, and sign the XML Message with the NCP-A signature. 7. The NCP A OutboundProtocolTerminator wraps the request into a SOAP envelope and sends it to the InboundProtocolTerminator in B (BoundTerminator). Audit Trails keeps track of messages exchanged. The incoming message that arrives in B contains the wrapped information for the patient. 8. WorkflowManager transfers patient data to SecurityManager for the signature verification. 9. For the purpose of obtaining a translated version of the eHealth DSI pivot CDA into the B country language, the WorkflowManager get the return data from the TransformationManager. 10. Patient data is returned to the HP B, if the message has passed successfully all the steps. The proposed interfaces might support other retrieval mechanisms too, as retrieving documents by setID. For the scope of this project, considering that only one Patient Summary may exist and a limited number of prescriptions are usually active, it’s reasonable to suppose the usage of a “direct” request for retrieval through the list() operation. The treatment relationship (as a SAML assertion signed by NCP B or HP) is covered in the security chapter. 6.4.3.3 Notification System Architecture Specification_v2.1.0 Page 59 of 69  Figure 44: Notification workflow 1. HP/HCPO B is authenticated and the patient is identified (Precondition). The HP calls for retrieving prescriptions of the patient by calling a corresponding method located at the NationalConnector in B and providing ID of the patient. ePrescription has been already delivered to the pharmacy. The call initialize (InitializeDispensationRequest) is initiated by HP B data display component (HP B Portal). 2. The AuditTrail component keeps track of the message passing through the NationalConnector. (The same audit is done when the response returns). The NationalConnector forwards the request to WorkflowManager. 3. The WorkflowManager forwards the request to OutboundProtocolTerminator (named BoundTerminator on the figure, because the name switches between In and Out). The SecurityManager Sign() the message with the NCP-B signature. System Architecture Specification_v2.1.0 Page 60 of 69  4. After the massage passed through the terminators and arrives at the WorkFlowManager in A. The NationalConnector make the appropriate call to the national infrastructure and records the request in the audit trail. The response should contain requested prescriptions in the national format of country A. 5. The WorkflowManager receives the response from NationalConnector and calls The TransformationManager to obtain the eHealth DSI pivot CDA and the CDA with the original PDF embedded. 6. The WorkflowManager calls the SecurityManager component, and sign the XML Message with the NCP A signature. 7. The NCP A OutboundProtocolTerminator wraps the request into a SOAP envelope and sends it to the InboundProtocolTerminator in B (BoundTerminator in the figure). Audit Trails keeps track of messages exchanged. The incoming message that arrives in B contains the wrapped informations for the patient. 8. WorkflowManager transfers patient data to SecurityManager for the signature verification. 9. For the purpose of obtaining a translated version of the eHealth DSI pivot CDA into the B country language, the WorkflowManager gets the return data from the TransformationManager. 10. Patient data is returned to the HP B, if the message has passed successfully all the steps. 6.5 Security Architecture The security Architecture of eHealth DSI is based on Trust and Communication Relationships between Inbound and Outbound Gateways. The concept of trust is pivotal in eHealth DSI. Services are set up through the network as a basis for secure messaging. The eHealth DSI circle of trust means that service providers join together in order to exchange authentication information. This circle of trust contains an identity provider, a service that maintains and manages identity information. The [Security Services Specification] defines a secure channel that is made up from a VPN and TLS. 6.5.1 Trusted Federation of NCPs NCPs are implemented federally in order to allow for a virtual integration of autonomous sources of medical data and identity information. The independence of the information sources is preserved as all access to an information source is mediated through the eHealth DSI services which are implemented at NCP level. This complies to a Business-to- Business paradigm where end users and data sources are decoupled by enterprise level entry services that map external requests onto internal operations and vice versa. Part of this mediation is the brokerage of trust by matching security objects of the NCP-to-NCP trust domain into a local trust domain and vice versa. The administration of the identities of patients and HPs is decentralized. Authentication of a HP can only be done on the NCP that recognizes this HP. The existence of a treatment relationship between a patient and a HP can only be attested within the legal framework of the PoC. With eHealth DSI HP authentication System Architecture Specification_v2.1.0 Page 61 of 69 and treatment relationship attestment is always performed by the NCP where the PoC connects to. The eHealth DSI “Circle of Trust” (CoT) consists of pairs of mutually trusted consuming and providing gateways. A consuming gateway provides the computing environment for the operation of an eHealth DSI service consumer. A providing gateway operates the Web Service Endpoint (WSE) of the service provider. Each gateway is operated under the legal responsibility of a NCP. 6.5.1.1 NCP certificates It is assumed that a list of valid NCP certificates is distributed as part of the eHealth DSI configuration. Certificate verification in performed within the NCP by checking whether the certificate is registered with this list or not. Status validation is done by either OCSP or CLS (depending on what protocols the CA offers). 6.5.2 Message exchange infrastructure eHealth DSI service providers and consumers use the eHealth DSI messaging infrastructure to exchange request and response messages among each other. The message infrastructure builds upon the eHealth DSI communication infrastructure that connects the eHealth DSI network of trusted nodes. The trusted node infrastructure implements the core eHealth DSI security services which ensure the confidentiality of medical data transmission and the availability and authenticity of eHealth DSI services. The following layers compose the message exchange Infrastructure: Figure 50: Message exchange layers System Architecture Specification_v2.1.0 Page 62 of 69 6.5.3 Upper Layer (Iso 7) The upper layer supports the message exchange mechanisms for the implementation of eHealth DSI business. Security elements for the standardised enveloping of data and documents are also added. They include: • transmission of authenticated HP attributes under SAML Assertion, • common message format between service as described previously through service exchanges, • signature on message elements for auditing and brokering of document authenticity claims. 6.5.3.1 Transmission of authenticated HP The HP Identity Assertion is a means of user identity. This enables relying parties to run their business tasks without identifying the requester since this is done by a trusted third- party authentication service. Those assertions are encoded as SAML assertions [SAML 2.0], organised under a structured elements. They do also include a signature which references the security certificate. 6.5.3.2 Common message format The eHealth DSI Common Message Format is a SOAP 1.2 message contained as the Body of an HTPP 1.1 [RFC2616] message. All messages MUST be SOAP Envelopes with an XML payload in the SOAP Body. Optional binary data MUST be carried as Base 64 encoded octets within the XML payload if not otherwise stated for the respective operations. Request messages MUST be sent using an HTTP POST, response messages are carried over the backchannel. The encoding of the containing XML document MUST be set to UTF-810. All eHealth DSI SOAP messages MUST comply with the WS-I Basic Profile 1.1 [BP11]. All eHealth DSI SOAP messages MUST comply with the WS-I Secure Basic Profile 1.0 [BSP10]. All eHealth DSI SOAP message MUST be described in a WSDL 1.1 Service Description. All WSDL type definitions MUST be in XML Schema format. 6.5.3.3 Signature on message When auditing and brokering documents the signature is used to prove the authenticity of messages, and it is based on an x509 certificate. 6.5.4 TCP Message Layer (Iso 4) Transport Layer Security MUST be supported by the eHealth DSI network. Transport Layer Security (TLS) are cryptographic protocols that provide security for communications over networks such as the Internet. TLS and SSL encrypt the segments of network connections at the Transport Layer end-to-end. For a mutual authentication every node must validate the certificate of the other node. NCP-B SSL certificate and NCP-A SSL certificate MUST be used to establish a TLS v1.0 [RFC 2246] connection between country B and A NCPs. 6.5.5 IPsec VPN Network Layer (Iso 3) A gateway-to-gateway VPN MUST be set up between all eHealth DSI nodes. IPSec ESP transport modus MUST be used. Perfect Forwarding Secrecy MUST be 10 UTF-8 is more efficient than UTF-16 for European languages. Older encodings such as ISO-8859-x do not cover all languages in a single encoding, and will only pose interoperability problems. UTF-8 is the default in XML, and coverage is a requirement of the XML specification. System Architecture Specification_v2.1.0 Page 63 of 69 activated. SA Lifetime SHOULD be based on the number of exchanged packets and SHOULD NOT exceed 4GB. Algorithms and key lengths MUST be used. Gateway certificates MUST comply with the certificate profiles. The issuing CAs and all components and services for managing the lifecycle of the certificates must comply with the respective eHealth DSI security policies (see [Security Services Specification]). IPSec mechanism is eHealth DSI application independent (Transparent to user). I do provide access control, data origin authentication and data confidentiality. 6.5.6 Physical Infrastructure Layer (Iso 1) This layer is responsible for moving bits between two NCPs. The communication is done from NCP to NCP. It is part in the figure to illustrate the basis of eHealth DSI communication. 6.5.7 Regarding the use of Certificates and PKI It is assumed that a list of valid NCP certificates is distributed as part of the eHealth DSI configuration. Certificate verification in performed within the NCP by checking whether the certificate is registered with this list or not. Status validation is done by either OCSP or CLS (depending on what protocols the CA offers). All cryptographic keys and algorithms used for eHealth DSI and its implementations MUST fulfil at least the requirements of [ECRYPT-II D.SPA.57] for Level-5 (Legacy Standard) security. This corresponds to 96-bit security (symmetric equivalent). Countries participating in circle of trust MAY agree to choose another algorithm catalogue as long as this does not fall behind [ECRYPT-II D.SPA.57] level-5. Only non-patented hash algorithms of the SHA-2 family MUST be used. SSL client authentication certificates must be Common PKI compatible. 6.5.8 Regarding the use of Certificates and PKI The following constraints are in accord with the ITI-19 transaction specification: • Data.Algorithms and key lengths MUST be used. • The node certificates MUST comply with the eHealth DSI Node Authentication Certificate Profile • The issuing CA and all components and services for managing the lifecycle of the eHealth DSI Node Authentication Certificates must comply with the respective eHealth DSI security policies (see [Security Services Specification]). 6.5.9 Regarding the use of Certificates and PKI SAML Assertions is an XML-based standard for exchanging authentication and authorization data between security domains, that is, between an identity provider (a producer of assertions) and a service provider (a consumer of assertions). A SAML assertion attests the authenticity of the user and the existence of a treatment relationship. A SAML assertion attests the HP Identity Assertion. An element MUST link two assertions For instance; the presence of the patient-id and sender-vouches means the presence of a treatment assertion. System Architecture Specification_v2.1.0 Page 64 of 69 In case of emergency country can decide to add in the treatment relationship assertion an emergency indicator. 6.5.10 Regarding SOAP faults SOAP faults: A three different level errors type had been identified in order to handle errors at the appropriate level of abstraction. They are described in the following figure: Figure 51: Soap faults 6.5.10.1 Message processing fault The standard SOAP fault mechanism is used for failures that origin in the encoding of the SOAP message or the contents of the SOAP header. It is assumed that the respective errors are discovered during the processing of the message at the front- end tiers of the NCP-A. They mainly address failures that originate at NCP-B. Typical examples of such errors are missing security token or usage of undefined attributes within security token. 6.5.10.2 Business processing / request faults Error Messages in the SOAP response body: Error reporting mechanisms of the business level protocol are used for failures that are discovered during the business- level processing of security token and SOAP body elements. These errors may as well be discovered during policy enforcement at the NCP as during the processing of the request within the national infrastructure. Failures usually either originate at the PoC in country B or at the national infrastructure in country A. These errors SHOULD be reported to the HP in country B as it is assumed that either the HP or the patient MAY be able to take action to successfully re-issue the request. Typical examples of such errors are missing consents and temporary component failures in country A. 6.5.10.3 Clinical processing / content faults Error messages related to the creation of the document content. There may be cases where failure may result in some elements of clinical information missing for example in a patient summary. These clinical content errors should be conveyed within the document content. The SOAP body transactions and SOAP header were exchanged without errors at the lower two levels. System Architecture Specification_v2.1.0 Page 65 of 69 6.5.11 Security zone The [Section II - Security Services] (chapter 5) exposes how message exchanges within the eHealth DSI architecture are treated in regard to security (referred to as “End-to-End Security”). Figure 52: End-to-End security and Trust Zones Access Control Security Service is also taken care of in the [Section II - Security Services] (chapter 2). Notably, it gives highlights to the use of XACML (eXtensible Access Control Markup Language) for eHealth DSI when considering access policy. 6.5.12 Session context Considering the potential number of exchanges for the eHealth DSI, a stateless processing MUST be used at business level. Explicit sessions11 with session identifiers exchanged for the application layer are out of scope. In country B, a session in eHealth DSI consists: • a HP identity assertion • a patient identifier that is accepted by country A • a treatment relationship assertion. In Country A, a session MAY be set up for the following tasks: • an internal session for performance reasons but this session is not visible outside of NCP-A (i.e. in the country health information service). • the possibility is left to country decisions but it has to be noted that sessions may recover load-balancing and fall-over capabilities. 6.5.13 Adopted Standards This table provides a summary of the port level requirements for message integrity, authentication and confidentiality used for each of the Request and Response methods between the secured entities12. 11 A session is a logical connection between service provider and service consumer extending over multiple exchanges by maintaining state of the security context on both sides. System Architecture Specification_v2.1.0 Page 66 of 69  Sender Operation Message Message Authentication Confidentiality Algorith m Receiver Integrity NCP A → findIdentity FindIdentityByT NCP X.509: UNT-user NCP X.509: Security raitsRequest Services NCP B ByTraits UNT, Body, Signature Specification Timestamp NCP B → findIdentity findIdentityByTr NCP X.509: R X.509: Security aitsResponse Services NCP A ByTraits Body Body, Signature Specification NCP A → initialise initializeReques NCP X.509: UNT-user R X.509: Security t Services NCP B Body, UNT, Body, Signature Specification Timestamp NCP B → initialise InitialiseRespon R X.509: Security se Services NCP A Body, Signature NCP A → put PutRequest NCP X.509: UNT-user R X.509: Specification Security Services NCP B Body, UNT, Body, Signature Specification Timestamp NCP B → put PutResponse R X.509: Security Services NCP A Body, Signature Specification NCP A → list ListRequest NCP X.509: UNT-user R X.509: Body, Security Services NCP B UNT, Signature Specification Timestamp NCP B → list ListResponse NCP X.509: R X.509: Body, Security Services NCP A Body Signature Specification NCP A → discard DiscardRequest NCP X.509: UNT-user R X.509: Body, Security Services NCP B UNT, Signature Specification Timestamp NCP A → discard DiscardRespon NCP X.509: R X.509: Body, Security se Services NCP B Body Signature Specification The Message Integrity column (i.e. which parts of the message need to be signed in each case) is explained here: • “UNT” (UserNameToken) – The wsse:UsernameToken element in the WS Security header containing the identity of the user who originally made the request as defined in the UsernameToken profile of WSS10 (see http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token- profile-1.0.pdf) • “Timestamp” – The wsu:Timestamp element added to the message when it was created as defined in WSS10 • “Body” – This is the part of the SOAP message (e.g. soap:Body) that contains the business document The Authentication column consists of the following entries: • [“UNT-user,”] “Cert Auth” • UNT-user is a UserNameToken as defined in WSS10 but without a password, i.e. it contains a UserName only. It identifies the original user that issues the request. • Cert Auth indicates that authentication consists of an examination of the public key certificate whose private key was used to sign the message. The Confidentiality column indicates whether or not the message is encrypted. It contains one of the following: • “None”. The security analysis concluded that confidentiality was not required 12 This representation has been derived from SCM Security Architecture document developed by the W S-I Sample Applications team. System Architecture Specification_v2.1.0 Page 67 of 69  • Certificate “:” MessageParts. In which case confidentiality was applied as described below. • Certificate identifies the public key which is used to encrypt the symmetric key which is used to encrypt the various parts of the message. Its structure and semantics is the same as “Certificate” as defined under Message Integrity except that the certificate is being used for encryption rather than signing. • Message Parts are a list of the parts of the message that are encrypted. Each part encrypted separately. It may contain some combination of: “Body”, “Start Header” and “Signature”. “Signature” means the digital signature that results from signing the message is encrypted. The Algorithm column describes the cryptographic algorithms used if the message is signed or encrypted. Algorithms Key, Data and Digest must follow Security Services Specification recommendations. • “Key”: Asymmetric Algorithm identifies the algorithm used to generate public/private key pairs. In the Sample Application it is used to generate and verify signatures as well as to encrypt and decrypt the symmetric key used to encrypt and decrypt the message content. (See also ftp://ftp.rsasecurity.com/pub/pkcs/ascii/pkcs-1.asc) • “Data”: Symmetric Algorithm identifies the algorithm used for encrypting and decrypting the message content. (See also http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf). • “Digest”: Secure Hash Algorithm identifies the algorithm used for calculating the unique fingerprint for each of the signed parts of the message. (See also http://www.itl.nist.gov/div892/iip_pubs/draft-ietf-ipsec-ciph-sha-256-01.txt). • There are several options in regard to the selection of auditors in regards of independence and certification, depending on the availability of resources such as internal audit staff and procedures. 6.6 Profile and Transaction Mapping The purpose of this section is to map the technical components with the eHealth DSI Transactions. Technical components Reference eHealth DSI Transactions Query Medical Data [epSOS-7] Retrieve Medical Data [epSOS-8] InboundProtocolTermination Notify Medical Data Processing [epSOS-9] epSOS-12: Patient ID Discovery Query Medical Data [epSOS-7] Retrieve Medical Data [epSOS-8] OutBoundProtocolTerminator Notify Medical Data Processing [epSOS-9] epSOS-12: Patient ID Discovery Query Medical Data [epSOS-7] Retrieve Medical Data [epSOS-8] WorflowManager Notify Medical Data Processing [epSOS-9] epSOS-12: Patient ID Discovery Retrieve Medical Data [epSOS-8] TransformationManager Notify Medical Data Processing [epSOS-9] AuditTrails Format Audit Trail [epSOS-5] TymeSyncManagerMediator Maintain Time [epSOS-3] NationalConnector n/a System Architecture Specification_v2.1.0 Page 68 of 69  Attest Authenticity [epSOS-10] Retrieve CRL [epSOS- SignatureManager 15] Verify Certificate Status [epSOS-16] SemanticServicesImpl n/a 7 Terminology and Glossary 7.1 Wording conventions Expression Meaning Conveyed Sense Must Is obliged to Must not is not allowed/permitted/acceptable/permissible is required to be not Required / Mandatory is required that … be not is not to be... Should it is recommend that Best Practice / it is desirable to Recommendation / Left Should not is not recommended to the assessment of the it is not desirable to country May option, but not mandatory, that should be used of the country wishes so Acceptable / Permitted Need not it is not required that no … is required 7.2 eHealth DSI Glossary See [eHealth DSI Glossary]. System Architecture Specification_v2.1.0 Page 69 of 69  Nõuded pakkuja meeskonnale Turvatestimine ja testimisraportite kontrollimine 1. Üldised nõuded meeskonnale 1.1. Pakkuja peab esitama tööde teostamiseks vähemalt kaks turvatestimist läbi viivat tiimiliiget. 1.1.1. Üks meeskonnajuht, kes vastab talle CV vormil seatud nõuetele; 1.1.2. Vähemalt üks turvatestija (võib esitada ka rohkem), kes vastavad CV vormidel seatud spetsialisti kvalifikatsioonile. 1.2. Meeskonnaliikmete esitamisega kinnitab pakkuja, et esitatud meeskonnaliikmed hakkavad riigihanke tulemusel sõlmitud lepingu alusel töid teostama. Pakkumuses esitatud meeskonnaliikme saab tellija eelneval nõusolekul vahetada üksnes uue meeskonnaliikme vastu, kes vastab vormil toodud tingimustele. 1.3. Täitja meeskonnaliikmed peavad olema tööde teostamiseks objektiivsed ja erapooletud, st nad ei tohi olla osalenud testitava infosüsteemi arendamisel jms töös. 2. Nõuded CV-le 2.1. Pakkuja esitab pakkumuses meeskonnaliikmete andmed, täites iga nõutud liikme kohta etteantud vormi. Esitatud andmed peavad või maldama hankijal kontrollida meeskonnaliikmete vastavust esitatud nõuetele ja hankija kontrollib tingimuste täitmist e elkõige esitatud andmete alusel: 2.1.1. Varasema töökogemuse andmed esitab pakkuja viidates konkreetsetele projektidele, kus meeskonnaliige on isikulikult osalenud t ingimuses nõutud töötundide mahu ulatuses. 2.1.2. Töökogemuse nõude täitmisena ei arvestata vabakutselisena tegutsemist, v.a kui selle perioodi osas on viidatud konkreetsetele projektidele. 2.1.3. Töökogemuse nõude täitmisena ei arvestata täiendkoolitust või koolitööd. 2.1.4. Kui tingimuses on nõutud konkreetse kestusega töökogemust, siis (ka osaliselt) samaaegsete projektide kattuvaid aegu mitmekordselt ei arvestata. St sama ajaperioodi eest ei ole võimalik omandada mitmekordset kogemust. 2.1.5.Projektide andmete esitamisel tuleb iga projekti kohta esitada vähemalt: projekti nimi ja lühikirjeldus, projekti algus- ja lõppaeg kuu täpsusega, projekti tellinud asutus ja tellija kontaktisik ning riigihanke korral märkida riigihanke number. 2.1.6. Viidatud projektid peavad olema hanke algamise ajaks nõutud mahus/ kompetentsi osas täidetud ja tellija poolt vastu võetud. 2.1.7. Ühe viidatud projektiga võib olla hõlmatud mitu kompetentsi/kogemust. Kõik nõutud kompetentsid/kogemused peavad olema lepingute või projektidega omandatud kogemusega kaetud. 2.1.8. Hankijal on õigus pöörduda tellija poole esitatud andmete kontrollimiseks. 2.2. Kui mõne nõutud kompetentsi/kogemuse osas on andmed esitamata või nende alusel ei ole võimalik järeldada, kas nõue on täidetud, on hankijal õigus tunnistada pakkumus mittevastavaks.  2.3. CV-s peab nähtuma kõikide hankija seatud nõuete täitmine, hankija kontrollib nõude täitmist esitatud andmete alusel. CV peab olema esitatud eesti keeles. 2.4. Dokumendis tuleb arvestada, et juhul kui see on objektiivselt võimalik, tuleb lugeda koos märkega "või samaväärne". Samaväärs use tõendamise kohustus lasub pakkujal, kes sellele tugineda soovib. Tõendid samaväärsuse kohta peavad olema esitatud pakkumuse koosseisus. 2.5. Esitatud sertifikaadid peavad olema pakkumuse esitamise ajal kehtivad. Kui pakkuja esitab tähtajalise kestusega sertifikaadi, tuleb pakkujal esitada tööde teostamisel meeskonnaliikme rakendamiseks hankijale uus kehtiv sertifikaadi koopia. 3. CV vormid 3.1. Meeskonnajuht /ees-ja perekonnanimi/_______________________________________ Projektidele viitamisel tuleb märkida vähemalt: - projekti nimi ja lühikirjeldus, - projekti algus- ja lõppaeg kuu täpsusega, - projekti tellinud asutus ja tellija kontaktisik, - riigihanke korral riigihanke number, - kui tingimuses on nõutud, siis töötundide arv. Väljade täitmine on kohustuslik. Kogemus läbimurde turvatestimisega projektide täitmisel viimase 24 kuu jooksul, kus meeskonnaliige on isiklikult teostanud töid vähemalt 400h ulatuses ja mille töö metoodika peab olema vastanud OWASP ASVS 4.0 või uuem, tase 1, 2 või 3 (või samaväärne metoodika) veebirakenduse käsitsi turvatestimise verifikatsiooni-  nõuetele. Omab vähemalt ISC2 CISSP JAH/EI. (Certified Information Nimetada konkreetne olemasolev sertifikaat, mis vastab tingimusele. Systems Security Professional) sertifikaati (või samaväärne). Sertifikaadi koopiad lisatakse pakkumuse juurde. 3.2. Turvatestija /ees-ja perekonnanimi/_______________________________________ Projektidele viitamisel tuleb märkida vähemalt: - projekti nimi ja lühikirjeldus, - projekti algus- ja lõppaeg kuu täpsusega, - projekti tellinud asutus ja tellija kontaktisik, - riigihanke korral riigihanke number, - kui tingimuses on nõutud, siis töötundide arv. Väljade täitmine on kohustuslik. Kogemus läbimurde turvatestimisega projektide täitmisel viimase 24 kuu jooksul, kus meeskonnaliige on isiklikult teostanud töid vähemalt 400h ulatuses ja mille töö metoodika peab olema vastanud OWASP ASVS 4.0 või uuem, tase 1, 2 või 3 (või samaväärne metoodika) veebirakenduse käsitsi turvatestimise verifikatsiooni- nõuetele. Omab vähemalt IACRB CWAPT (Certified Web Application Penetration JAH/EI. Tester) Nimetada konkreetne olemasolev sertifikaat, mis vastab tingimusele. või Sertifikaadi koopiad lisatakse pakkumuse juurde. GIAC GWAPT (Web Application Penetration Tester) või EWPTXv2 (eLearnSecurity Web Application Penetration Tester eXtreme) või OSWE (Offensive Security Web Expert) või IACRB CMWAPT (Certified Mobile and Web App Penetration Tester) sertifikaati  My Health @ EU eHealth Digital Service Infrastructure Electronic cross-border health services in the EU NCPeH Components Specifications DOCUMENT 5.0.0 VERSION DATE 30/04/2021 STATUS Wave 5 Release Candidate DG SANTE, CEF eHealth DSI, 2021 Reuse is authorised, provided the source is acknowledged. COVER AND CONTROL PAGE OF DOCUMENT Document name: NCPeH Components Specifications Distribution level*: PU Status: Wave 5 Release Candidate Author(s): eHealth DSI provider Organization: * Distribution level: PU = Public, PP = Restricted to other programme participants, RE = Restricted to a group specified by the consortium, CO = Confidential, only for members of the consortium. ABSTRACT This document covers the technical specifications of the eHealth DSI common components that have to be put in place by eHealth DSI countries in order to allow for a secure and privacy-aware exchange of identifiable medical data. The document is presented as a consolidated specification of the already implemented eHealth DSI solution. It furthermore serves as the foundation of the eHealth DSI services technical specification, which is aimed at reusing as much of the work already done and to preserve much of the backwards compatibility between both initiatives. CHANGE HISTORY Version Date Status Changes From Review V4.0.0 15/05/2020 Wave 4 Operation eHealth DSI Solution Ready – Integrate the Provider CP-036 and CP-042 required changes V3.1.0 09/09/2019 Wave 3 Operation eHealth DSI Solution Ready - HotFix Provider Integrate the modifications linked to the CP-eHealthDSI- 024: Formalize the 'Description' element in the eP list V3.0.0 02/07/2019 Wave 3 Operation eHealth DSI Solution Ready -Administrative Provider update V2.2.0 30/06/2018 Wave 2 Operation eHealth DSI Solution Ready Provider V2.1.0 01/06/2017 Released for eHealth DSI Solution eHMSEG adoption Provider V2.0.6 24/05/2017 Remove eHealth DSI provider inconsistencies in the naming notation of the Metadata V2.0.5 23/05/2017 Remove the eHealth DSI provider overlapping information about the  eHealth DSI web services V2.0.4 11/05/2017 Correct the error code eHealth DSI provider for the Unknown Filter (must be 4204) in section 3.4.1.5 V2.0.3 04/05/2017 Remove the eHealth DSI provider overlapping information about the Audit Trail Profile, X.509 Certificate profiles, SAML Profile and Cryptographic Algorithms V2.0.2 27/04/2017 Integrate the eHealth DSI provider modifications linked to the CP-001 (Evidence emitter) V2.0.1 21/04/2017 Integrate the eHealth DSI provider modifications linked to the CP-002 V2.0.0 28/03/2017 Remove all references eHealth DSI provider to epSOS and requirements 1.0 2012-11-06 APM Cleaned-up version for release to EC TABLE OF CONTENTS 1 Introduction ................................................................................................................. 7 1.1 eHealth Digital Service Infrastructure................................................................. 7 1.2 eHealth DSI Common Components Specification .......................................... 7 1.3 Conventions .......................................................................................................................... 8 1.4 Organisation of this Document ................................................................................. 8 2 eHealth DSI Services Functional Specification ................................................. 9 2.1 eHealth DSI Service-Oriented Architecture...................................................... 9 2.1.1 Service Roles ............................................................................................................ 9 2.1.2 Trusted federation of national Contact Points ......................................... 10 2.1.3 eHealth DSI Services Overview ...................................................................... 10 2.1.4 Services Localisation .......................................................................................... 10 2.1.5 General Considerations for Service Operations ....................................... 11 3 eHealth DSI Service Implementation ................................................................ 11 3.1 Conventions and Restrictions ................................................................................. 11 3.1.1 NCP: A Standards based Implementation .................................................. 11 3.1.2 IHE Cross Community Access (XCA) ............................................................ 12 3.1.3 Error Handling ...................................................................................................... 13 3.1.4 Information Messages and Warnings .......................................................... 14 3.1.5 Object Identifier ................................................................................................... 14 3.1.6 Namespaces ........................................................................................................... 15 3.2 eHealth DSI Identification Service ........................................................................ 15 3.2.1 findEntityByTraits() Operation ...................................................................... 15 3.2.1.1 Event Identification ............................................................................................ 16 3.2.1.2 Restrictions on the Use of Traits .................................................................... 16 3.2.1.3 Use of Pseudonyms and Temporal Identifiers ......................................... 17 3.2.1.4 Patient Authentication ....................................................................................... 17 3.2.1.5 Requested Accuracy of Matches..................................................................... 17 3.2.1.6 Example Request Message ............................................................................... 17 3.2.1.7 Active Participant Role ID Codes ................................................................... 19 3.2.1.8 Response Message (Full Success Scenario) ............................................... 19 3.2.1.9 Response Message (No Patient ID Discovered) ....................................... 21 3.2.1.10 Example Response Messages ...................................................................... 23 3.2.2 Security Audit Considerations ........................................................................ 25 3.2.3 Protocol Requirements...................................................................................... 26 3.3 eHealth DSI Patient Service ...................................................................................... 26 3.3.1 List() Operation .................................................................................................... 27 3.3.1.1 Request Message .................................................................................................. 27 3.3.1.2 Example Request Message ............................................................................... 28 3.3.1.3 Expected Actions .................................................................................................. 29 3.3.1.4 Response Message (Full Success Scenario) ............................................... 29 3.3.1.5 Response Message (No Patient Summary Provided) ............................ 33 3.3.1.6 Example Response Message ............................................................................ 34 3.3.2 Security Audit Considerations ........................................................................ 39 3.3.3 Protocol Requirements...................................................................................... 39 3.4 eHealth DSI Order Service ......................................................................................... 40 3.4.1 List() Operation .................................................................................................... 40 3.4.1.1 Request Message .................................................................................................. 40 3.4.1.2 Example Request Message ............................................................................... 41 NCPeH_Components_Specifications_v5.0.0 Page 4 of 84  3.4.1.3 Expected Actions .................................................................................................. 42 3.4.1.4 Response Message (Full Success Scenario) ............................................... 42 3.4.1.5 Response Message (No ePrescriptions Provided) .................................. 46 3.4.1.6 Example Response Message ............................................................................ 47 3.4.2 Security Audit Considerations ........................................................................ 49 3.4.3 Protocol Requirements...................................................................................... 49 3.5 eHealth DSI Dispensation Service ......................................................................... 50 3.5.1 Initialize() Operation.......................................................................................... 50 3.5.1.1 Request Message .................................................................................................. 50 3.5.1.2 Expected Actions .................................................................................................. 52 3.5.1.3 Response Message (Full Success Scenario) ............................................... 53 3.5.1.4 Response Message (Failure or Partial Failure Scenario) ..................... 53 3.5.1.5 Example Response Message ............................................................................ 54 3.5.1.6 Security Audit Considerations ........................................................................ 55 3.5.2 Discard() Operation ............................................................................................ 55 3.5.2.1 Request Message .................................................................................................. 55 3.5.2.2 Expected Actions .................................................................................................. 57 3.5.2.3 Response Message (Full Success Scenario) ............................................... 57 3.5.2.4 Response Message (Failure or Partial Failure Success Scenario) ..... 57 3.5.2.5 Response Message (Full Success Scenario) ............................................... 58 3.5.2.6 Security Audit Considerations ........................................................................ 59 3.5.3 Protocol Requirements...................................................................................... 59 4 eHealth DSI Communication and Messaging Infrastructure .................... 60 4.1 Audit Trail Implementation ..................................................................................... 60 4.1.1 TLS Configuration ................................................................................................ 60 4.2 Time Synchronisation .................................................................................................. 61 4.3 eHealth DSI Common Message Format .............................................................. 61 4.3.1 Transport Layer Profile ..................................................................................... 61 4.3.2 Message Layer Profile ........................................................................................ 61 4.3.3 XML Message Schema Format ........................................................................ 62 4.3.4 SOAP Binding......................................................................................................... 62 4.3.5 Embedding of Security Token ......................................................................... 62 4.3.5.1 SAML Assertions .................................................................................................. 62 4.3.5.2 Message Signature ............................................................................................... 62 4.3.6 Processing of SOAP Messages ......................................................................... 63 4.4 Exception Handling ........................................................................................................ 63 4.4.1 Communication Failures ................................................................................... 64 4.4.2 Encoding and Consistency Failures .............................................................. 64 4.4.2.1 SOAP Error Profile ............................................................................................... 64 4.4.2.2 General Message Handling Errors ................................................................. 65 4.4.2.3 SOAP Message Encoding and Addressing Errors .................................... 65 4.4.2.4 Security Header Encoding and Consistency Errors ................................ 66 4.4.2.5 Audit Trail Considerations ............................................................................... 67 5 eHealth DSI Profiles on Assertions and Certificates.................................... 68 5.1 Cryptographic keys and Algorithms.................................................................... 68 5.2 HP Identity Assertion ................................................................................................... 68 5.3 Treatment Relationship Confirmation Assertion ....................................... 68 5.4 eHealth DSI Certificate Profiles .............................................................................. 68 6 Appendix ..................................................................................................................... 68 NCPeH_Components_Specifications_v5.0.0 Page 5 of 84  6.1 Coding Conventions (Normative).......................................................................... 68 6.1.1 Country Codes ....................................................................................................... 68 6.2 eHealth DSI Identifiers (Normative) ................................................................... 69 6.2.1 Uniform Resource Names (URNs) ................................................................. 69 6.2.2 eHealth DSI OIDS.................................................................................................. 70 6.2.3 eHealth DSI CDA Documents and Codes ..................................................... 70 6.3 WSDLs ..................................................................................................................................... 70 7 References .................................................................................................................. 70 7.1 Normative References .................................................................................................. 70 NCPeH_Components_Specifications_v5.0.0 Page 6 of 84 1 Introduction This document covers the technical specifications of the eHealth DSI common components that have to be put in place by eHealth DSI countries in order to allow for a secure and privacy-aware exchange of identifiable medical data. The document is presented as a consolidated specification of the already implemented eHealth DSI solution. It furthermore serves as the foundation of the eHealth DSI services technical specification, which is aimed at reusing as much of the work already done and to preserve much of the backwards compatibility between both initiatives. 1.1 eHealth Digital Service Infrastructure The core principle of eHealth DSI is to bridge existing national eHealth infrastructures instead of setting up a new, centralised European healthcare service network from scratch. To make this approach work technical, semantic and legal interoperability among European eHealth infrastructures must be achieved. This includes identity matters as well as security matters and information management issues within heterogeneous, distributed environments. None of the problems faced by eHealth DSI is new or extremely challenging: cross-border data exchange is common practice in many domains, nearly every European country has use cases and processes for cross-enterprise health data exchange defined and decoupled security services spanning federated domains are well covered by international standards. Therefore the challenge for the development of technical specifications for the eHealth DSI building blocks is not to find a solution that works for the defined use cases. The challenge is to find a solution that 1) can evolve over the next years and lay ground for a seamless, secure and privacy-aware exchange of any kind of medical data across Europe, 2) can easily connect to the existing infrastructures without imposing unreasonable new risks on the privacy and integrity of existing data managing systems, 3) is flexible enough to be used in conjunction with different means of identification, authentication and authorisation to allow for any citizen and country to participate based on existing legal regulations and technical actualities and 4) is widely accepted and has the potential for reuse of software components and test tools. 1.2 eHealth DSI Common Components Specification The eHealth DSI Common Components Specification is the technical baseline of eHealth DSI: There MUST NOT be any normative statement on the shape and behaviour of any eHealth DSI building block that is on a technically lower level than this specification. While specifications on identity management [Identity management Specifications] and security services [Security Services Specification] define the core concepts and guidelines for these issues, the eHealth DSI Common Component Specifications defines the technical means that serve these concepts. The scope of the eHealth DSI Common Components Specification is determined by: - technical interoperability: the specification does only cover aspects of cross-border data exchange that are indispensable for technical interoperability NCPeH_Components_Specifications_v5.0.0 Page 7 of 84  -shared responsibility: whenever possible, only the shape of data exchanged "on the wire" is specified while the processes and systems for issuing and consuming these data objects are considered to be national responsibilities The objective is to define the eHealth DSI interoperability building blocks in a way that they can be implemented independently from each other by different vendors. The eHealth DSI Common Components Specification builds upon the implementation independent technology view of [System Architecture Specifications]. It provides the normative specification of the eHealth DSI services’ operations by mapping them onto established standards. 1.3 Conventions The keywords MUST, SHOULD, MAY, SHOULD NOT and MUST NOT are used as defined in [RFC 2119]. For indicating the optionality of certain functionalities or data fields the following keywords are used: - "R" or "Required": Functionalities and data fields marked as "R" MUST be provided. - The notation "R+" is used to indicate that eHealth DSI is stricter on the mandatory nature of the functionality or data field than the underlying base standard. - "O" or "Optional": Functionalities and data fields marked as "O" MAY be omitted. - "R/O": Data fields marked as "R/O" are conditionally mandatory. - "X": Functionalities and data fields marked as "X" MUST NOT be used. 1.4 Organisation of this Document This document consists of four main parts in order to separate different levels of abstraction and to allow different groups of readers to easily access the information that is relevant for them without having to read the whole document: - Chapter 2 of this document specifies the functionality of the eHealth DSI Services by outlining the data elements that have to be exchanged in order to implement the defined service operations. This eHealth DSI functional service specification is targeted at system architects who are responsible for connecting HCPOs and existing national infrastructures to eHealth DSI components. - Chapter 3 specifies the implementation of the eHealth DSI services by providing the eHealth DSI Mappings of the service operations. These specifications describe how the eHealth DSI services’ operations are mapped onto existing standards and healthcare profiles. This part is targeted at software designers and developers who are responsible for the implementation of eHealth DSI services and for their integration with existing national infrastructure components. - Chapter 4 defines the eHealth DSI communication and messaging infrastructure. It describes the protocols to be used for establishing the eHealth DSI network of trusted nodes and specifies the common formats for messages. Chapter 4 is mainly targeted at systems administrators who are responsible for the configuration of web service platforms and network nodes. - Chapter 5 specifies the syntax and semantics of the assertions and certificates that are used by the eHealth DSI services. This chapter is targeted NCPeH_Components_Specifications_v5.0.0 Page 8 of 84  at security administrators who are responsible for the management of certificates and the configuration of security services. Sample messages and the WSDLs for all eHealth DSI services’ interfaces are provided in an appendix to this document. 2 eHealth DSI Services Functional Specification The eHealth DSI architecture is based on a service-oriented paradigm. [NCPeH Architecture Specification] defines the eHealth DSI services and service interfaces and shows how these interact with each other in order to implement the eHealth DSI use cases on patient summary, ePrescription and original clinical documents (OrCD). This chapter builds upon the technology viewpoint on the eHealth DSI architecture by further refining the functional specification of the eHealth DSI services’ interfaces. For each service operation the input and output as well as the requested effect and the preconditions for a success scenario are defined. 2.1 eHealth DSI Service-Oriented Architecture The design of the general architecture of eHealth DSI and the design of the eHealth DSI services is based on the following basic assumptions: 1. The design uses the service-oriented paradigm. 2. All services are passive, the service consumers and service providers communicate synchronously. 3. All eHealth DSI medical data as well as all patient and HP identity data is administered in autonomous systems. Any exchange of these data is mediated by national gateways following a B2B paradigm. 4. There are no central services except the ones needed for the operation of a secure eHealth DSI infrastructure; the federation of national gateways is implemented via a »circle of trust«. 2.1.1 Service Roles The service-oriented paradigm distinguishes among three roles: service provider, services consumer, and service registry. The service provider offers a service that is used by the service consumer. The service provider can publish a description of the service in a service registry. eHealth DSI services are implemented as Web Services whose interfaces are specified with the Web Service Description Language [W3C WSDL 1.1]. eHealth DSI Web services are passive. Communication between service consumer and service provider is always initiated by the service consumer. The service provider is passive and reacts to requests from the service consumer. The communication between service consumer and services provider is synchronous. The service consumer’s control flow is suspended until the service provider has processed the service consumer’s request. Service consumer and provider communicate over the Internet using XML-based SOAP messages transported via the HTTP protocol (see chapter 4.3 for details). Each eHealth DSI service is operated under the responsibility of a National Contact Point (NCP). The role of the service consumer is always taken by the NCP of the country of care (country B). The role of the service provider is always taken by the NCP of the country of the patient’s affiliation (country A). A service registry is not used. Instead it is assumed that service descriptions and service location information is made available for service consumers by organisational means and static local directory services (see section 2.1.4). As with other centrally managed data (e. g. value set catalogues and trusted certificates), the mechanisms for securely distributing NCPeH_Components_Specifications_v5.0.0 Page 9 of 84 this information among NCPs are out of the scope of this document and will instead be covered by the eHealth DSI documents on security policies and pilot operations. 2.1.2 Trusted federation of national Contact Points National Contact Points (NCPs) are implemented federally in order to allow for a virtual integration of autonomous sources of medical data and identity information [OFW- NCPeH]. The independence of the information sources is preserved as all access to an information source is mediated through the eHealth DSI services which are implemented at NCP level. This complies to a Business-to-Business paradigm where end users and data sources are decoupled by enterprise level entry services that map external requests onto internal operations and vice versa. Part of this mediation is the brokerage of trust that is achieved by matching security objects of the NCP-to-NCP trust domain into a local trust domain and vice versa. The administration of the identities of patients and healthcare professionals (HPs) is decentralized. Authentication of a HP can only be done within the country of care that recognizes this HP. The existence of a treatment relationship between a patient and a HP can only be attested within the legal framework of the point of care (PoC). With eHealth DSI HP authentication and treatment relationship attestment are therefore performed within the country of care (e. g. by using an existing Identity Provider service of the national infrastructure). A brokerage of the HP authentication and treatment relationship confirmation into the eHealth DSI domain is performed in a way that the NCP at country B confirms the respective claims and maps them onto a unified syntax and semantics that can be processed by the NCP of country A. The eHealth DSI "Circle of Trust" consists of pairs of mutually trusted consuming and providing gateways. A consuming gateway provides the computing environment for the operation of an eHealth DSI service consumer and acts as the exit point from the national domain into the eHealth DSI domain. A providing gateway operates the Web Service Endpoint (WSE) of the service provider and acts as the entry point from the eHealth DSI domain into the national domain. Each gateway is operated under the legal responsibility of an NCP. A basic assumption of eHealth DSI is that mutual trust exists between NCPs. The authenticity and integrity of the services in the gateway-mediated NCP-2-NCP communication is secured with digital certificates. Examinations of the certificates and their exchange (with a limited number of NCPs) are to be synchronized among the eHealth DSI service providers [Security Services Specification, NCPeH Architecture Specification]. 2.1.3 eHealth DSI Services Overview To foster interoperability among European healthcare infrastructures without forcing countries to modify their running eHealth services, only NCP gateway-to-gateway interfaces are considered as "normative" with eHealth DSI. These interfaces are provided by web services that use open, XML-based standards and transport protocols to exchange data between gateways. The full list of eHealth DSI web services acc. to [NCPeH Architecture Specification] is shown in Table 1. Service Mediated Data Functional Specification Identification Service Patient identifiers and demographics [Identity Management Specification] Patient Service Patient summary documents [PS Functional requirements] NCPeH_Components_Specifications_v5.0.0 Page 10 of 84 Order Service ePrescription documents [eP Functional requirements] Dispensation Service eDispensation documents [eP Functional requirements] OrCD Service OrCD documents Table 1: eHealth DSI Services Overview 2.1.4 Services Localisation In eHealth DSI, service discovery and location will be based on dynamic look-up [NCPeH Architecture Specification]. Each NCP MUST describe its service addresses and certificates in a centrally managed location table that complies to the eHealth DSI Service Metadata Publisher format as specified in [Service Location and Capability Lookup Profile] (see section 2) of this document. Each NCP holds a copy of the other NCP's location tables as part of its internal configuration. 2.1.5 General Considerations for Service Operations In order to successfully operate the eHealth DSI use cases on patient summary and ePrescription, the following preconditions MUST be met: 1) The service consumer MUST be able to locate the service provider. The respective end point addresses and certificates MUST be provided through a [Service Location and Capability Lookup Profile] (see section 2). Up-to-date copies of all service providing NCP’s Service Metadata Publisher files MUST be available to the service consumer. 2) A secure channel MUST have been established between service consumer and service provider nodes (see section 4.1 for the establishment of the eHealth DSI Trusted Node Infrastructure). 3) The service provider MUST be able to verify the authenticity of the service consumer and vice versa. This requires that service consumer and service provider only make use of digital certificates that can be verified by the counterpart (see [SAML Profile] for the definition of the respective certificate profiles). 4) The requesting HP MUST have been authenticated in the country of care (see [Identity Management Specification] for details on HP authentication). The service provider MUST be able to verify the attesting HP identity assertion (see [SAML Profile] for the specification of the HP Identity Assertion and [X.509 Certificate Profiles]. for the certificate profile of the NCP signature certificate that MUST be used for attesting the successful authentication of an HP). Further general requirements for secure and privacy-aware operations that MUST be considered are defined in [System Architecture Specification] and [Security Services Specification]. Failures during a service’s operation or faulty conditions for using a service MUST be handled. Part of this fault handling is that a respective audit trail entry MUST be written at all NCPs who are aware of the fault. See section 4.4 for details. 3 eHealth DSI Service Implementation The eHealth DSI service interface defines the semantics of identification and data sharing operations for European health services. "On the wire" the service operations are implemented by SOAP messages that are exchanged between an initiating gateway (operated by NCP-B) and a providing gateway (operated by NCP-A). NCPeH_Components_Specifications_v5.0.0 Page 11 of 84 This chapter specifies the mapping of eHealth DSI service operations onto standardised messages and as such is the normative implementation guideline for the eHealth DSI-facing NCP interface. 3.1 Conventions and Restrictions 3.1.1 NCP: A Standards based Implementation The eHealth DSI NCP2NCP interface is based on the IHE X* family of Interoperability Profiles and additionally utilises a set of supporting profiles (Figure 6). Figure 6: IHE actors and transactions that are profiled by eHealth DSI The IHE profiles that are implemented for eHealth DSI NCP-to-NCP data exchange are: - Cross Community Fetch (XCF) - Cross-Community Access (XCA) incorporating a modified getAll() transaction - Cross-Enterprise Document Reliable Interchange (XDR) - Cross-Community Patient Discovery (XCPD) The eHealth DSI service specifications that build on these IHE profiles introduce various extensions and restrictions on IHE actor and transaction definitions in order to properly cover the eHealth DSI use cases and to align with the eHealth DSI security framework: - Registry query and repository retrieve transactions are conflated to a single list() operation (see section 3.1.2). - Additional error messages are defined that cover specific failure conditions of the eHealth DSI use cases on Patient Summary and ePrescription. - Warning messages are introduced (see section 3.1.4) to allow for notifications on specific environmental conditions that apply to a country and that MAY affect the NCPeH_Components_Specifications_v5.0.0 Page 12 of 84  interpretation of data in another country. - The optionality of data fields is aligned to European privacy regulations. - The application of security measures and the contents of the SOAP security header are specified normatively (see section 4.3.5). 3.1.2 IHE Cross Community Access (XCA) IHE XCA defines message interchange formats for listing and retrieving patient related documents. It is based on a stored query model1 where the requestor provides attribute- value pairs in the query. It is up to the responding site to map the query attributes onto its internal registry information model. For documents matching the provided attributes’ values, the document identifiers (and minimum metadata) are provided. The initiator of the original request may then chose a subset of these listed documents to issue a simple retrieve based on the document identifiers. At this point IHE XCA only supports scenarios where a query to request a list is first performed by returning document metadata (»LeafClass«) or just document IDs (»ObjectRef«), followed by an additional document retrieve operation. In contrast eHealth DSI is based on a pattern, that allows for easier handling of dynamic data and keeps the NCP-A stateless [PS Functional requirements]. For eHealth DSI the retrieval of a single patient summary or a patient’s set of ePrescriptions is performed by a single fetch() operation which returns all objects that match a given filter query within the response message. In order to implement this eHealth DSI document sharing pattern, eHealth DSI introduced a new IHE profile for returning documents on otherwise XCA compliant queries. This eHealth DSI-inspired XCF option allows for an integrated query and retrieve message. 3.1.3 Error Handling Failures during operation execution can be of different kinds; e.g. they may be caused by syntactic mismatches, insufficient access rights, country-A component failures, or protocol failures. eHealth DSI makes use of three different error reporting mechanisms in order to allow for a better handling of errors on the appropriate level of abstraction (see Figure 7): - SOAP faults: The standard SOAP fault mechanism is used for failures that originate in the encoding of the SOAP message or the contents of the SOAP header. It is assumed that the respective errors are discovered during the processing of the message at the eHealth DSI communication tier of the NCP-A and that they mainly address failures that originate at NCP-B. Typical examples of such errors are missing security token or usage of undefined attributes within security token. - Error Messages in the SOAP response body: Error reporting mechanisms of the business level protocol (e. g. XCA) are used for failures that are discovered during the business-level processing of security token and SOAP body elements. These errors may as well be discovered during policy enforcement at the NCP as during the processing of the request within the national infrastructure. The failure usually either originates at the Point of Care in country B or at the national infrastructure in country A. These errors SHOULD be reported to the HP in country B as it is assumed that either the HP or the patient MAY be able to take action to successfully re-issue the request. Typical examples of such errors are missing consents and temporary component failures in country A. - Error messages related to the creation of the document content: There may be cases where failure to access certain systems within a national infrastructure may result in some elements of clinical information missing (e.g. in a patient summary). 1 IHE XCA – as IHE XDS.b – does not exchange full query statements but only query arguments that are filled into predefined slots of a database stored query at the service side. NCPeH_Components_Specifications_v5.0.0 Page 13 of 84  These clinical content errors should be conveyed within the document content. The SOAP body transactions and SOAP header were exchanged without errors at the lower two levels. Figure 7: eHealth DSI error handling A list of all SOAP fault codes and conventions to be followed for transmitting SOAP faults are provided in section 4.4 of this document. Business level error messages and their proposed processing are provided in the "response message" sections of the eHealth DSI service specifications. Lower level communication and protocol failures are covered in section 4.4.1 of this document. 3.1.4 Information Messages and Warnings eHealth DSI implements medical data sharing among different legal and technical environments. This might lead to scenarios where the NCP at the patient’s country of affiliation MAY wish to send further information on the data collection procedure or on the source environment together with the data to the HP in the country of care. An example for this is a notice on automatically collected data that was not approved by an HP. Even an uncertain state of a request’s fulfilment – e.g. NCP was not able to access all relevant data sources – MUST be reported to the data consumer in order to provide a correct semantic context for the provided data. To allow for this exchange of context information, all ebXML based eHealth DSI messages provide the ability to include an <rs:RegistryErrorList/> element (with an success indicator) for transmitting information and warnings together with provided medical data. Warnings that only affect the contents of a single document are reported in an explicit clinical statement within that document. 3.1.5 Object Identifier In the absence of an official eHealth DSI OID [ISO OID] a temporary OID is assigned as the root OID 1.3.6.1.4.1.12559.11.10.1.3 for eHealth DSI. - (Branch 1 was allocated to eHealth DSI CDA templates: 1.3.6.1.4.1.12559.11.10.1.3.1). - Branch 2 (1.3.6.1.4.1.12559.11.10.1.3.2) was allocated to Common Components The following branches are defined for codes and code systems: OID Branch Description 1.3.6.1.4.1.12559.11.10.1.3.2.1 Patient Identification related codes and code systems 1.3.6.1.4.1.12559.11.10.1.3.2.2 HP/HCPO identification, authentication, authorisation related codes and code systems 1.3.6.1.4.1.12559.11.10.1.3.2.3 Medical data sharing related codes and code systems NCPeH_Components_Specifications_v5.0.0 Page 14 of 84 1.3.6.1.4.1.12559.11.10.1.3.2.4 Consent encoding and management related codes and code systems The following branches are defined for eHealth DSI CDA templates: OID Branch Description 1.3.6.1.4.1.12559.11.10.1.3.1.1.1 ePrescription 1.3.6.1.4.1.12559.11.10.1.3.1.1.2 eDispensation 1.3.6.1.4.1.12559.11.10.1.3.1.1.3 Patient Summary 1.3.6.1.4.1.12559.11.10.1.3.1.1.8 eHDSI OrCD Laboratory Result 1.3.6.1.4.1.12559.11.10.1.3.1.1.9 eHDSI OrCD Hospital Discharge Report 1.3.6.1.4.1.12559.11.10.1.3.1.1.10 eHDSI OrCD Medical Imaging Report 1.3.6.1.4.1.12559.11.10.1.3.1.1.11 eHDSI OrCD Medical Images For a full list of all defined OIDs see appendix 6.2.2 of this document. 3.1.6 Namespaces XML namespace prefixes are used in this document to stand for their respective namespaces as follows. Prefix Namespace ehealth urn:ehealth:v1 soapenv http://www.w3.org/2003/05/soap-envelope wsse http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd saml urn:oasis:names:tc:SAML:1.0:assertion xacml urn:oasis:names:tc:xacml:2.0:policy:schema:os hl7v2 urn:hl7-org:v2 hl7v3 urn:hl7-org:v3 xds urn:ihe:iti:xds-b:2007 xs http://www.w3.org/2001/XMLSchema xsi http://www.w3.org/2001/XMLSchema-instance rimext urn:ihe:iti:xds-ebrim:extensions:20102 query urn:oasis:names:tc:ebxml-regrep:xsd:query:3.0 rim urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0 rs urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0 lcm urn:oasis:names:tc:ebxml-regrep:xsd:lcm:3.0 tsl http://uri.etsi.org/02231/v2# 3.2 eHealth DSI Identification Service The eHealth DSI Identification Service is used to discover a valid patient identifier from an ID assigning authority by providing given identifiers and/or demographic data that is sufficient for patient identification. Figure 8 - Patient Identification Service Interface The implementation of the eHealth DSI Identification Service is based on the standard 2 IHE will be asked to block this namespace for eHealth DSI extensions in order to avoid conflicts with forthcoming IHE extensions to the ebRIM. NCPeH_Components_Specifications_v5.0.0 Page 15 of 84  - HL7 IS: HL7 V3 Identification Service and is an extension to the IHE profile - XCPD: IHE Cross-Community Patient Discovery [IHE XCPD] 3.2.1 findEntityByTraits() Operation The IHE XCPD Cross-Gateway Patient Discovery transaction – as for the semantics and syntax of its content - is based on HL7 Patient Registry Find Candidates Query (PRPA_IN201305UV02) interaction type and used also for the [IHE PIX/PDQ v3] transactions. 3.2.1.1 Event Identification The findEntityByTraits() request is initiated by an HP in the country of care for the identification of a foreign patient. The respective request message conforms to the Patient Registry Find Candidates Query (PRPA_IN201305UV02) interaction type as profiled by the IHE XCPD Cross-Gateway Patient Discovery transaction [IHE XCPD]. For the HL7 transmission wrapper and the HL7 Control Act the conventions identified in the IHE PIX/PDQV3 supplement appendix O [IHE PIX/PDQ v3] and the changes from the XCPD supplement appendix O MUST be followed. In addition the following eHealth DSI-specific restrictions apply: - <receiver/> MUST refer to NCP-A. Other sub-elements than the device-identifier that holds the OID of NCP-A MUST be ignored by the service provider and SHOULD NOT be provided by the service consumer. <sender/> MUST refer to NCP-B. Other sub-elements than the device-identifier that holds the OID of NCP- B MUST be ignored by the service provider and SHOULD NOT be provided by the service consumer. - Asynchronous operations MUST NOT be used. According to [PS Functional requirements] all message interchange in eHealth DSI MUST be synchronous. - Demographic Query Only mode or Shared/national Patient Identifier Query and Feed mode - MUST be used. Other modes defined in [IHE XCPD] MUST NOT be used. - The health data locator option as defined in section 27.2.1 of [IHE XCPD] MUST NOT be used. Where indication of support for the health data locator option is required in responses, the service provider MUST provide the value "NotHealthDataLocator". - The revoke option as defined in section 27.2.2 of [IHE XCPD] MUST NOT be used. - Correlations MUST NOT be cached by the service provider. The respective syntax elements described in section 3.55.4.1.2 of [IHE XCPD] MUST NOT be used. - Reverse Cross-Gateway Queries MUST NOT be used. The homeCommunityId and community patient id assigning authority arguments SHOULD be set to the OID of the responding NCP (NCP-A) in query requests 3.2.1.2 Restrictions on the Use of Traits For a findIdentityByTraits() request only the following traits or a subset of these MUST be used. Service providers SHOULD reject requests that contain other traits than the ones listed below. Identity Trait Source Usage Convention (if provided) NCPeH_Components_Specifications_v5.0.0 Page 16 of 84  LivingSubjectID Personal ID Card SHOULD contain zero or more living subject Id. When present, it shall contain both an assigning authority identifier (root) and individual ID (extension). If multiple subject IDs are given for the same patient, each identifier MUST be provided as a dedicated <LivingSubjectID/> element and some of them might be optional. LivingSubjectName Personal ID Card Family name and given name MUST both be given if no Liv- ingSubjectID is provided. Otherwise this query parameter is optional. LivingSubjectBirthTime Personal ID Card Birth date MUST be given if no LivingSubjectID is provided. Otherwise this query parameter is optional. If given this parameter MUST be encoded as "YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/- ZZZZ]" with year, month and day being mandatory. LivingSubjectGender MUST be "M", "F" or "UN" PatientAddress Personal ID Card SHOULD contain country and city. For detailed information on the encoding of these traits and their optionality for the XCPD modes see [IHE XCPD]. The set of required traits for patient identification are defined by each eHNCP-A according the [Service Location and Capability Lookup Profile]; Service Metadata Publisher EHEALTH-107. 3.2.1.3 Use of Pseudonyms and Temporal Identifiers A country MAY wish to protect its patients’ privacy by negotiating an eHealth DSI shared identifier from a pseudonymous or temporal national patient identifier. In this case Shared/national Patient Identifier Query and Feed mode MUST be used. On successful identification within country A the response message MUST at least provide the patient’s date of birth in order to allow the HP in country B to verify the accuracy of the identification. 3.2.1.4 Patient Authentication The eHealth DSI Identification Service allows for the identification of a patient. If a country requires an additional authentication of its citizens when they ask for medical care in another country, this country MUST define its own authentication service. The eHealth DSI Identification Service findIdentityByTraits operation only provides the mechanism for piggybacking the exchange of transparent authentication data between NCPs. This is done by using two HL7v3 instance identifier within a single <LivingSubjectID/> element; one identifier is used for identifying the patient while the other one is used for authentication of the patient. The service provider MUST be able to distinguish identifier and authentication object by their roots (assigning authorities). 3.2.1.5 Requested Accuracy of Matches The HL7 Patient Registry Find Candidates Query allows to further refine the match criteria by setting the match algorithm and specifying a requested minimum degree of match for the provided traits. NCPeH_Components_Specifications_v5.0.0 Page 17 of 84 As the respective <MatchCriterionList> element is optional with the HL7 schema, it SHOULD NOT be used for the eHealth DSI wave 1. If present, the minimum requested match degree SHOULD be set to an integer value of "100". In both cases the responding service SHOULD only respond with identity data of patients who fully match all provided traits. Returning multiple candidates’ identity trails SHOULD be avoided for privacy reasons. 3.2.1.6 Example Request Message The following excerpt from a findEntityByTraits request message shows the IHE XCPD profile of the HL7 PRPA_IN201305UV02 interaction type. The request message can be used to retrieve the identifier of a patient who identified himself with his electronic health card and date of birth. <soapenv:Envelope> <soapenv:Header> … >/soapenv:Header> <soapenv:Body> <hl7v3:PRPA_IN201305UV02 xmlns:xsi="..."> <hl7v3:id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/> <hl7v3:creationTime value="20100304120000"/> <hl7v3:interactionId root="2.16.840.1.113883.1.6" extension="PRPA_IN201305UV02"/> <hl7v3:processingCode code="P"/> <hl7v3:processingModeCode code="T"/> <hl7v3:acceptAckCode code="NE"/> <hl7v3:receiver typeCode="RCV"> <hl7v3:device classCode="DEV" determinerCode="INSTANCE"> <hl7v3:id root="1.2.840.114350.1.13.999.234"/> </hl7v3:device> </hl7v3:receiver> <hl7v3:sender typeCode="SND"> <hl7v3:device classCode="DEV" determinerCode="INSTANCE"> <hl7v3:id root="1.2.840.114350.1.13.999.567"/> </hl7v3:device> </hl7v3:sender> <hl7v3:controlActProcess classCode="CACT" moodCode="EVN"> <hl7v3:code code="PRPA_TE201305UV02" codeSystem="2.16.840.1.113883.1.6"/> <hl7v3:queryByParameter> <hl7v3:queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204"/> <hl7v3:statusCode code="new"/> <hl7v3:responseModalityCode code="R" /> <hl7v3:responsePriorityCode code="I"/> <hl7v3:parameterList> <hl7v3:livingSubjectBirthTime> <hl7v3:value value="19600422"/> <hl7v3:semanticsText/> </hl7v3:livingSubjectBirthTime> <hl7v3:livingSubjectId> <!-- German electronic healthcard card number (Serial Number) --> <hl7v3:value root="1.2.276.0.76.4.8" extension="1234567890"/> <hl7v3:semanticsText/> </hl7v3:livingSubjectId> </hl7v3:parameterList> </hl7v3:queryByParameter> </hl7v3:controlActProcess> </hl7v3:PRPA_IN201305UV02> </soap:body> </soap:envelope> The following example shows the mapping of Czech EHIC data elements onto a PRPA_TE201305UV02 control act. NCPeH_Components_Specifications_v5.0.0 Page 18 of 84 <hl7v3:controlActProcess classCode="CACT" moodCode="EVN"> <hl7v3:code code="PRPA_TE201305UV02" codeSystem="2.16.840.1.113883.1.6"/> <hl7v3:queryByParameter> <hl7v3:queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204"/> <hl7v3:statusCode code="new"/> <hl7v3:responseModalityCode code="R" /> <hl7v3:responsePriorityCode code="I"/> <hl7v3:parameterList> <hl7v3:livingSubjectBirthTime> <hl7v3:value value="19501201"/> <hl7v3:semanticsText/> </hl7v3:livingSubjectBirthTime> <hl7v3:livingSubjectId> <!-- European Health Insurance Card Serial Number --> <hl7v3:value root="......." extension="80203111990000000001"/> <hl7v3:semanticsText/> </hl7v3:livingSubjectId> <hl7v3:livingSubjectName> <hl7v3:value> <hl7v3:family>NOVAK</hl7v3:family> <hl7v3:given>JAN</hl7v3:given> </hl7v3:value> <hl7v3:semanticsText/> </hl7v3:livingSubjectName> <hl7v3:patientAddress> <hl7v3:value> <hl7v3:country>CZ</hl7v3:country> </hl7v3:value> <hl7v3:semanticsText/> </hl7v3:patientAddress> </hl7v3:parameterList> </hl7v3:queryByParameter> </hl7v3:controlActProcess> 3.2.1.7 Active Participant Role ID Codes The eHealth DSI Identification Service provider shall respond with the findEntityByTraits response message containing the patient identifier that is to be used for querying the identified patient’s medical data. The eHealth DSI Identification Service provider MUST verify that the requesting service user has sufficient rights to query for the identifier of the given patient. It is subject to the national security policy of the patient’s country of affiliation, how multiple matches and matches with less than 100% accuracy are handled3. 3 The national security policy of the patient's country of affiliation always overrides service consumer minimum confidence level: for instance, if country A only accept 100% match but country B is requesting with minimum NCPeH_Components_Specifications_v5.0.0 Page 19 of 84 In case of an error that relates to the transmission of the request or the processing of the eHealth DSI security token, the eHealth DSI Identification Service provider MUST respond with a fault message according to section 4.4 of this document. 3.2.1.8 Response Message (Full Success Scenario) The eHealth DSI findEntityByTraits response content is based on HL7 Patient Registry Find Candidates Query Response (PRPA_IN201306UV02) interaction, as profiled by the IHE XCPD Cross-Gateway Patient Discovery result message. For the HL7 transmission wrapper and the HL7 Control Act the conventions identified in the IHE PIX/PDQV3 supplement appendix O and the changes from the XCPD supplement appendix O MUST be followed. In addition the following eHealth DSI-specific restrictions apply:  <receiver/> MUST refer to NCP-B. Other sub-elements than the device-identifier that holds the OID of NCP-B MUST be ignored by the service consumer and SHOULD NOT be provided by the service provider. <sender/> MUST refer to NCP-A. Other sub-elements than the device-identifier that holds the OID of NCP- A MUST be ignored by the service consumer and SHOULD NOT be provided by the service provider.  Asynchronous operations MUST NOT be used. According to [PS Functional requirements] all message interchange in eHealth DSI MUST be synchronous.  Correlations MUST NOT be cached by the service provider. The respective syntax elements described in section 3.55.4.1.2 of [IHE XCPD] MUST NOT be used.  The <processingCode/> MUST be set to "D" (debugging) for eHealth DSI PPT environment. It MUST be set to "P" (production/operation) for eHealth DSI routine operations. For each matching candidate a single <subject/> element MUST be included within the control act wrapper. In addition to the constraints defined in [IHE XCPD] the following conventions MUST be followed for <subject1/patient/> elements: Element Name Opt. eHealth DSI Usage Convention Patient R For each matching candidate a single <patient/> element MUST be provided. Patient/id R This element MUST contain the HL7-II-encoded Id of the patient that MUST be used for subsequent transactions to access the patent’s medical data. The root designator MUST be present. Patient/statusCode R MUST be "active". Patient/patientPerson R Additional demographic data on a patient that matches the query. The encod ing of this data MUST follow the conventions as stated in [IHE XCPD]. See table below for a list of demographics that SHOULD be used for eHealth DSI. confidence level of 75%, then only 100% matches will be returned (see [Identity Management Specification] for details on ID traits matching and confidence levels). NCPeH_Components_Specifications_v5.0.0 Page 20 of 84  Patient/subjectOf1/ R This element encodes the score of the match as an HL7 observation. It queryMatchObservation MUST be used as this: <hl7v3:queryMatchObservation classCode="OBS" mood- Code="EVN"> <hl7v3:code codeSystem="2.16.840.1.113883.1.11.19914"/> <hl7v3:value xsi:type="hl7v3:INT" value="MATCH"/> </hl7v3:queryMatchObservation> Other elements MAY be provided within the result set by the sender but SHOULD be ignored by the receiver. For a FindIdentityByTraits response only the following ID data MUST be provided as child elements of the <patientPerson/> element. Identity Data Opt. Usage Convention (if provided) asOtherIDs/id O This element SHOULD be only given if it provides further information on the scope and context of the used identification mechanism. This information SHOULD be suited to allow the HP to verify the claimed identity of the patient. name O Both family name and given name SHOULD be provided. Note: This element is mandatory wrt. the HL7v3 schema. Therefore at least an empty instance MUST be included with the response. birthTime R+ MUST be provided as "YYYY[MM[DD[HHMM[SS[.S[S[S[S]]]]]]]][+/-ZZZZ]" birthplace O SHOULD contain the country and city of birth administrativeGenderCode O addr O Only city and streetName SHOULD be provided guardian X For the eHealth DSI minors and dependent people will not be treated differently from others. This element MUST NOT be provided as no respective risk assessment has been done. As specified in [IHE XCPD], the following status should be returned:  AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper).  OK (data found, no errors) is returned in QueryAck.queryResponseCode (control act wrapper). 3.2.1.9 Response Message (No Patient ID Discovered) If the eHealth DSI Identification Service provider does not find a matching patient identifier it SHOULD include a <reasonOf/> element with the response message: <reasonOf typeCode="RSON"> <detectedIssueEvent classCode="ALRT" moodCode="EVN"> <code code="ActAdministrativeDetectedIssueCode" codeSystem="2.16.840.1.113883.5.4"/> <!— details on detected issue and proposed activity --> </detectedIssueEvent> </reasonOf> Depending on the reason for not providing a patient identifier, the codes and messages as defined below MUST be used4. 4 All codes using the coding system: codeSystem="1.3.6.1.4.1.19376.1.2.27.3 are to be used per XCPD error code definition. NCPeH_Components_Specifications_v5.0.0 Page 21 of 84  Condition and proposed action Reason Encoding The service requestor tried an identification <triggerFor typeCode="TRIG"> based on an ID only or did not provide enough <actOrderRequired classCode="ACT" moodCode="ENV"> data to univocally identify the patient. <code code="AdditionalDemographicsRequested" (WARNING) codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/ > The HP SHOULD ask the patient for further </actOrderRequired> demographics and re-issue the request. </triggerFor> AA (application accept) is returned in Acknowledgement.typeCode (transmission If specific demographics are requested the respective code values wrapper). of code system 1.3.6.1.4.1.19376.1.2.27.1 as specified in section OK (data found, no errors) is returned in 3.55.4.2.2.6 of [IHE XCPD] SHOULD be used. There may be as QueryAck.queryResponseCode (control act many triggerFor elements, each of them containing an wrapper) ActOrderRequired element as needed to code the attributes which would increase the assurance of the match5. The service provider only allows for patient <triggerFor typeCode="TRIG"> identification by national/shared ID <actOrderRequired classCode="ACT" moodCode="ENV"> (WARNING). <code code="DemographicsQueryNotAllowed" codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/ The HP SHOULD ask the patient for a national > (health care) identification card and re-issue the </actOrderRequired> request using Shared/national Patient </triggerFor> Identifier Query and Feed mode. AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper) The service provider only allows for patient <triggerFor typeCode="TRIG"> identification by national health card or EHIC. <actOrderRequired classCode="ACT" moodCode="ENV"> Queries based on demographics only are not <code code="EHICDataRequested" supported (WARNING) codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/ > The HP SHOULD ask the patient for a health </actOrderRequired> care identification card and re-issue the </triggerFor> request. AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper) <mitigatedBy typeCode="MITGT"> The service provider does not accept the query <detectedIssueManagement classCode="ACT" because responding MAY lead to a disclosure moodCode="ENV"> of private patient data (ERROR). <code code="PrivacyViolation" The HP SHOULD limit the provided traits and codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/ re-issue the request. > </detectedIssueManagement> </mitigatedBy> 5 See IHE ITI CP #535 NCPeH_Components_Specifications_v5.0.0 Page 22 of 84  AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper) <mitigatedBy typeCode="MITGT"> The requestor has insufficient rights to query for <detectedIssueManagement classCode="ACT" patient’s identity data (ERROR). moodCode="ENV"> If access to the patient’s medical data is <code code="InsufficientRights" required at the PoC this MUST be performed codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/ by a person with additional permissions. > </detectedIssueManagement> AA (application accept) is returned in </mitigatedBy> Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act <mitigatedBy typeCode="MITGT"> Patient authentication MUST be piggybacked <detectedIssueManagement classCode="ACT" wrapper) with patient identification. A respective identi- moodCode="ENV"> fier (e.g. GSS TAN) was not provided <code code="PatientAuthenticationRequired" (ERROR) codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/ The HP at the PoC SHOULD ask the patient for > a respective identifier and SHOULD re-issue </detectedIssueManagement> the request. </mitigatedBy> AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper) <mitigatedBy typeCode="MITGT"> The service provider did not find a match with <detectedIssueManagement classCode="ACT" the given minimum accuracy. (INFO) moodCode="ENV"> The service consumer SHOULD re-issue the <code code="AnswerNotAvailable" request with a lower minimum confidence level. codeSystem="1.3.6.1.4.1.19376.1.2.27.3"/> </detectedIssueManagement> AA (application accept) is returned in </mitigatedBy> Acknowledgement.typeCode (transmission wrapper). OK (data found) is returned in QueryAck.queryResponseCode (control act wrapper) <mitigatedBy typeCode="MITGT"> The identity traits provided by the service <detectedIssueManagement classCode="ACT" consumer are not supported by the service moodCode="ENV"> provider. (ERROR) <code code="AnswerNotAvailable" The service consumer SHOULD re-issue the codeSystem="1.3.6.1.4.1.19376.1.2.27.3"/> request with a different set of identity traits. </detectedIssueManagement> AA (application accept) is returned in </mitigatedBy> Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper) NCPeH_Components_Specifications_v5.0.0 Page 23 of 84  <mitigatedBy typeCode="MITGT"> The service consumer defined a confidence <detectedIssueManagement classCode="ACT" level that conflicts with the security policy of moodCode="ENV"> the service provider. (INFO) <code code="PolicyViolation" The service provider SHOULD respond only codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1"/> with the candidate matches that it is allowed to </detectedIssueManagement> provide wrt. its security policy. </mitigatedBy> AA (application accept) is returned in Acknowledgement.typeCode (transmission wrapper). AE (application error) is returned in QueryAck.queryResponseCode (control act wrapper) 3.2.1.10 Example Response Messages The following sample message responds to a query with the patient identifier of a patient who matches the given identity traits. The match is unique and it is a full overlap with the given query. <soapenv:Envelope> <soapenv:Header> ... </soapenv:Header> <soapenv:Body> <hl7v3:PRPA_IN201306UV02 xmlns:xsi="..."> <hl7v3:id root="1.2.840.114350.1.13.999.238" extension="55789"/> <hl7v3:creationTime value="20100304110302"/> <hl7v3:interactionId root="2.16.840.1.113883.1.6" extension="PRPA_IN201306UV02"/> <hl7v3:processingCode code="P"/> <hl7v3:processingModeCode code="T"/> <hl7v3:acceptAckCode code="NE"/> <hl7v3:receiver typeCode="RCV"> <hl7v3:device classCode="DEV" determinerCode="INSTANCE"> <hl7v3:id root="1.2.840.114350.1.13.999.567"/> </hl7v3:device> </hl7v3:receiver> <hl7v3:sender typeCode="SND"> <hl7v3:device classCode="DEV" determinerCode="INSTANCE"> <hl7v3:id root="1.2.840.114350.1.13.999.234"/> </hl7v3:device> </hl7v3:sender> <hl7v3:controlActProcess classCode="CACT" moodCode="EVN"> <hl7v3:code code="PRPA_TE201306UV02" codeSystem="2.16.840.1.113883.1.6"/> <hl7v3:subject typeCode="SUBJ"> <hl7v3:registrationEvent classCode="REG" moodCode="EVN"> <hl7v3:id nullFlavor="NA"/> <hl7v3:statusCode code="active"/> <hl7v3:subject1 typeCode="SBJ"> <hl7v3:patient classCode="PAT"> <!-- Identifier that MUST be used for subsequent requests --> <hl7v3:id root="1.2.276.0.76.4.8" extension="1234567890"/> <hl7v3:statusCode code="active"/> <hl7v3:patientPerson> <hl7v3:name/> <hl7v3:birthTime value="19680513"/> </hl7v3:patientPerson> <hl7v3:subjectOf1 typeCode="SBJ"> <hl7v3:queryMatchObservation classCode="OBS" moodCode="EVN"> <hl7v3:code codeSystem="2.16.840.1.113883.1.11.19914"/> <!-- Query score matching --> NCPeH_Components_Specifications_v5.0.0 Page 24 of 84  <hl7v3:value xsi:type="hl7v3:INT" value="100"/> </hl7v3:queryMatchObservation> </hl7v3:subjectOf1> </hl7v3:patient> </hl7v3:subject1> <hl7v3:custodian typeCode="CST"> <hl7v3:assignedEntity classCode="ASSIGNED"> <!-- Required element containing the homeCommunityId for the community responding to the request --> <hl7v3:id root="1.2.840.114350.1.13.99998.8734"/> <!-- IHE Required element defining whether the responding community supports the QIL transaction for this patient, for eHealth DSI the required value is "NotHealthDataLocator" --> <hl7v3:code code="NotHealthDataLocator" codeSystem="1.3.6.1.4.1.19376.1.2.27.2"/> </hl7v3:assignedEntity> </hl7v3:custodian> </hl7v3:registrationEvent> </hl7v3:subject> <hl7v3:queryAck> <hl7v3:queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204"/> <hl7v3:queryResponseCode code="OK"/> </hl7v3:queryAck> </hl7v3:controlActProcess> </soapenv:body> </soapenv:envelope> The following sample message responds to a request that cannot be fulfilled because of insufficient traits. <soapenv:Envelope> <soapenv:Header> ... </soapenv:Header> <soapenv:Body> <hl7v3:PRPA_IN201306UV02 xmlns:xsi="..."> <hl7v3:id root="1.2.840.114350.1.13.999.238" extension="55789"/> <hl7v3:creationTime value="20100304110302"/> <hl7v3:interactionId root="2.16.840.1.113883.1.6" extension="PRPA_IN201306UV02"/> <hl7v3:processingCode code="P"/> <hl7v3:processingModeCode code="T"/> <hl7v3:acceptAckCode code="NE"/> <hl7v3:receiver typeCode="RCV"> <hl7v3:device classCode="DEV" determinerCode="INSTANCE"> <hl7v3:id root="1.2.840.114350.1.13.999.567"/> </hl7v3:device> </hl7v3:receiver> <hl7v3:sender typeCode="SND"> <hl7v3:device classCode="DEV" determinerCode="INSTANCE"> <hl7v3:id root="1.2.840.114350.1.13.999.234"/> </hl7v3:device> </hl7v3:sender> <hl7v3:controlActProcess classCode="CACT" moodCode="EVN"> <hl7v3:code code="PRPA_TE201306UV02" codeSystem="2.16.840.1.113883.1.6"/> <!-- Used to indicate that more attributes are required --> <hl7v3:reasonOf typeCode="RSON"> <hl7v3:detectedIssueEvent classCode="ALRT" moodCode="EVN"> <hl7v3:code code="ActAdministrativeDetectedIssueCode" codeSystem="2.16.840.1.113883.5.4"/> <hl7v3:triggerFor typeCode="TRIG"> <hl7v3:actOrderRequired classCode="ACT" moodCode="ENV"> <hl7v3:code code="AdditionalDemographicsRequested" codeSystem="1.3.6.1.4.1.12559.11.10.1.3.2.2.1.1"/> </hl7v3:actOrderRequired> </hl7v3:triggerFor> </hl7v3:detectedIssueEvent> NCPeH_Components_Specifications_v5.0.0 Page 25 of 84  </hl7v3:reasonOf> <hl7v3:queryAck> <hl7v3:queryId root="1.2.840.114350.1.13.28.1.18.5.999" extension="18204"/> <hl7v3:queryResponseCode code="OK"/> </hl7v3:queryAck> </hl7v3:controlActProcess> </hl7v3:PRPA_IN201306UV02> </soapenv:body> </soapenv:envelope> 3.2.2 Security Audit Considerations Both the eHealth DSI Identification Service provider and consumer write an audit trail entry according to the ID Mapping audit schema. The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X). eHealth DSI Instance Opt. Description Event R Audited event Human Requestor R HP who triggered the event Source Gateway R Service consumer node address at the country of care Target Gateway R Service provider node address at the country of affiliation Mapping Service R/X Service that provided the mapping. MUST be filled by the service provider. MUST NOT be filled by the service consumer. Audit Source R Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants Patient Source R Patient whose identifier was discovered or mapped Patient Target R Result of the mapping operation Error Message O Only used in case that the transaction was not completed successfully Table 2: eHealth DSI Patient Identification Service Audit Message Categories 3.2.3 Protocol Requirements The eHealth DSI Patient Identification Service FindIdentityByTraits request and response messages will be transmitted using synchronous Web Services Exchange, according to the requirements specified in section 4.3 of this document. Port types and bindings MUST be used as defined in the WSDL given in section 6.4.1 of this document. Acc. to this the eHealth DSI FindIdentityByTraits operation’s request and response data MUST be contained within the message body as follows: eHealth DSI Patient Identification Service Message Body FindIdentityByTraits request PRPA_IN201305UV02_Message (see section 6.4.1) FindIdentityByTraits response PRPA_IN201306UV02_Message (see section 6.4.1) The request message MUST be protected by the service consumer (NCP-B) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. The response message MUST be protected by the service provider (NCP-A) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. NCPeH_Components_Specifications_v5.0.0 Page 26 of 84 3.3 eHealth DSI Patient Service The eHealth DSI Patient Service is used to share an identified patient’s medical summary between the patient’s country of affiliation and the country of care. Both countries are represented by their respective NCPs. Figure 9 - Patient Service Interface The implementation of the eHealth DSI Patient Service is based on the following standards:  ebRIM: OASIS/ebXML Registry Information Model v3.0 [OASIS ebRIM 3.0]  ebRS: OASIS/ebXML Registry Services Specifications v3.06 [OASIS ebRS 3.0]  MTOM: SOAP Message Transmission Optimization Mechanism [W3C MTOM]  XOP: XML-binary Optimized Packaging [W3C XOP] and is based on the following IHE profile:  XCF: IHE Cross-Community Fetch [IHE XCF] For discovery and localisation of the Patient Service instance that is responsible for providing access to the identified patient’s data see section 2.1.4 of this document. 3.3.1 List() Operation The eHealth DSI Patient Service list() operation is implemented as IHE XCF Cross- Gateway Fetch transaction. It is fully compliant with the ebRS 3.0 standard. The eHealth DSI Patient Service list() operation includes the documents listed in the response meta- data, just like they would have been included in Cross-Gateway Fetch (SOAP 1.2 MTOP with XOP encoding attachments). 3.3.1.1 Request Message The list() request is initiated by an HP in the country of care for retrieving the patient summary of an identified patient. The respective request message builds upon the IHE XCF Cross-Gateway Fetch request message. The <AdhocQueryRequest/> element that encapsulates the query parameters MUST be used as follows for eHealth DSI: Element Name eHealth DSI Usage Convention ResponseOption/@returnComposedObjects MUST be "true" ResponseOption/@returnType MUST be "LeafClassWithRepositoryItem" (XCF) AdhocQuery Container for holding the ebML stored query arguments. All arguments MUST be encoded as query slots (see table below). AdhocQuery@id MUST be "urn:uuid:f2072993-9478-41df-a603- 8f016706efe8" which indicates a Fetch (which is an adaption of the findDocuments Query as defined in ITI TF-2a:3.18.1) 6 The integration of ebRS and MTOM as used by eHealth DSI is not compatible with the current version of OASIS ebRS. Support for MTOM will be part of the forthcoming ebRS v4.0. NCPeH_Components_Specifications_v5.0.0 Page 27 of 84 Only synchronous web services exchange MUST be used. The XDS Affinity Domain Option only applies to the national environment. Therefore it MUST NOT be used for NCP-2-NCP message exchange. Stored query argument slots MUST be defined for the patient identifier and the document class code. The document format code and the document type code MAY be given. Other argument slots than the ones listed below MUST be ignored by the service provider and SHOULD NOT be issued by the service consumer. Slot Name Opt Slot Value $XDSDocumentEntryPatientId R Equals to the patient identifier that was provided by the eHealth DSI Identification Service (encoded as HL7 v3 II data type) $XDSDocumentEntryStatus R Only approved documents MUST be returned: 'urn:oasis:names:tc:ebxml-regrep: StatusType:Approved' $XDSDocumentEntryClassCode R Patient summary LOINC code ("60591-5") coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/Code-Scheme. As classification scheme 2.16.840.1.113883.6.1 MUST be used: '60591-5^^2.16.840.1.113883.6.1' $XDSDocumentEntryTypeCode O Patient summary LOINC code ("60591-5") coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/Code-Scheme. As classification scheme 2.16.840.1.113883.6.1 MUST be used: '60591-5^^2.16.840.1.113883.6.1' $XDSDocumentEntryFormatCode O Format qualifier as defined in [CDA templates]; see table below for details on applying these codes to the retrieval of a patient’s medical summary. Only encodings of the patient summary that comply to the requested format code will be returend by the service provider. If this stored query slot is omitted the service provider MUST deliver all available encodings7. For the document format only the format codes defined in [CDA templates] and listed in the following table MUST be used. Document Format Format Code Document content eHealth DSI pivot coded urn:epsos:ps:ps:2010 HL7 CDA document acc. [CDA Patient Summary templates]. The patient’s country of affiliation MUST be able to provide the patient’s summarised medical data in this format. 7 Acc. to [PS Functional requirements] countries MAY provide patient summary data only in eHealth DSI pivot coded format. A query where the format code is omitted will in these cases provide the same result as a query for the eHealth DSI pivot coded document format only. NCPeH_Components_Specifications_v5.0.0 Page 28 of 84  PDF/A source coded urn:ihe:iti:xds-sd:pdf:2008 CDA-enveloped PDF/A encoding of document the original document without any semantic transformation of a patient summary as source coded PDF with a CDA header per IHE XDS-SD. The patient’s country of affiliation SHOULD be able to provide the patient’s summarised medical data in this format. 3.3.1.2 Example Request Message The following excerpt from an eHealth DSI Patient Service list() request message shows a cross-NCP query request that contains argument slots for retrieving the patient summary (LOINC code 60591-5) of an identified patient (patient identifier 90378912821). In this example the service consumer does not specify the requested encoding. Therefore the service provider MUST deliver all available encodings (e.g. eHealth DSI pivot and source coded document). <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" ... > <soapenv:Header> ... </soapenv:Header> <soapenv:Body> <query:AdhocQueryRequest> <query:ResponseOption returnComposedObjects="true" returnType="LeafClassWithRepositoryItem"/> <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> <rim:Slot name="$XDSDocumentEntryPatientId"> <rim:ValueList> <rim:Value>'90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO' </rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryStatus"> <rim:ValueList> <rim:Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved') </rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryClassCode"> <rim:ValueList> <rim:Value>('60591-5^^2.16.840.1.113883.6.1')</rim:Value> </rim:ValueList> </rim:Slot> <!-- Include associations whose sourceObject and targeObject attributes reference ExtrinsicObjects returned --> </rim:AdhocQuery> </query:AdhocQueryRequest> </soapenv:Body> </soapenv:Envelope> 3.3.1.3 Expected Actions The eHealth DSI Patient Service provider shall respond to a ListRequest message with the ListResponse message containing - the identified patient’s patient summary document(s) together with a status notification (full success scenario, see section 3.3.1.4) or - an error message (no patient summary provided, see section 3.3.1.5). The eHealth DSI Patient Service provider MUST verify that the requesting service user has sufficient rights to access the full patient summary of the identified patient. In case of an error that relates to the transmission of the request or the processing of the eHealth DSI security token, the eHealth DSI Patient Service provider MUST respond with a fault message according to section 4.4 of this document. NCPeH_Components_Specifications_v5.0.0 Page 29 of 84 3.3.1.4 Response Message (Full Success Scenario) Depending on the requested format code the eHealth DSI list() response contains the eHealth DSI pivot encoded patient summary document, the PDF/A encoded patient summary document or both documents of the identified patient. The respective message builds upon the IHE XCF Cross-Gateway Fetch response and Cross-Gateway Fetch Response messages. The fields defined for the eHealth DSI ListResponse message MUST be used as follows: Element Name eHealth DSI Usage Convention query:AdhocQueryResponse Response message acc to IHE XCF Cross-Gateway Fetch response message [IHE XCF] @status For the full success scenario the response status MUST be set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" or "urn:ihe:iti:2007:ResponseStatusType:PartialSuccess" (for details see table below) ../rs:RegistryErrorList In case that a warning is given by the service provider, this element holds the respective warning codes and messages. It must be used acc. to section 4.1.13 of [IHE ITI TF-3]. ../rim:RegistryObjectList This element MUST be provided for the full success scenario. It MUST at least contain one child <rim:ExtrinsicObject/> element. ../../rim:ExtrinsicObject For each encoding of the patient summary a <rim:ExtrinsicObject/> element MUST be provided. Each <rim:ExtrinsicObject/> element is described and classified by metadata acc. to Table 3 below. ../../../rimext:Document This element MUST appear as the last element child of an <rim:ExtrinsicObject/> element. It may appear zero or one times. This element contains the base 64 encoded content of the document. The document contents are associated with the DocumentEntry (ExtrinsicObject) metadata by the fact that it is nested inside it within the XML. The base64 encoded document content MAY be encrypted. How encryption is applied and how the encryption key is negotiated should be subject to an additional specification on advanced security safeguards. Each provided patient summary encoding (eHealth DSI pivot and/or source coded PDF) MUST be further classified by metadata. The following table lists the usage conventions that MUST be followed for the eHealth DSI Patient Service response message. If not stated otherwise the classification schemes as defined in section 4.3.1.2 of [IHE ITI TF-3] MUST be used. If no restrictions on metadata values are given, the metadata elements MUST be used as per [IHE XCF]. Metadata (ebRIM names) Binding Opt. eHealth DSI usage convention status Attribute R MUST be "urn:oasis:names:tc:ebxml- regrep:StatusType:Approved" mimeType Attribute R MUST be "text/xml" for both eHealth DSI pivot CDA and CDA- wrapped PDF Name Main R MUST be "Patient Summary". Description Main O MAY be empty. MAY be ignored by the service consumer. VersionInfo Main R MUST be "1.1" NCPeH_Components_Specifications_v5.0.0 Page 30 of 84  creationTime rim:Slot O MAY be omitted by the service provider and MAY be ig- nored by the service consumer. If given, the value MUST be encoded as HL7 v2 Date Time "YYYY[MM[DD[hh[mm[ss]]]]]" hash rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. languageCode rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. repositoryUniqueId rim:Slot O COULD be omitted by the service provider and MAY be processed by the service consumer in an IHE-compatible NI-scenario. serviceStartTime rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by serviceEndTime the service consumer. size rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. sourcePatientId rim:Slot R MUST contain the same value as XDSDocumentEntry PatientID (see below). sourcePatientInfo rim:Slot X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and documents. Therefore all metadata elements that might carry medical or social information MUST be omitted. classCode Classification R Patient summary LOINC code ("60591-5"). As classifica- tion scheme "urn:oid:2.16.840.1.113883.6.1" MUST be used eventCodeList Classification X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and docu- ments. Therefore all metadata elements that might carry medical or social information MUST be omitted. author Classification X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and documents. Therefore all metadata elements that might carry medical or social information MUST be omitted. confidentialityCode Classification R MUST be provided for XCF compatibility but MAY be ignored by the service consumer. Value SHOULD be set to "N", as long as the Minimal Metadata Profile is not published. formatCode Classification R MUST be "urn:epSOS:ps:ps:2010" for eHealth DSI pivot CDA and "urn:ihe:iti:xds- sd:pdf:2008" for eHealth DSI source coded PDF (see [CDA templates]). NCPeH_Components_Specifications_v5.0.0 Page 31 of 84  healthcareFacilityTypeCode Classification R MUST be provided for XCF compatibility and correct ad- dressing. Value MUST be set to ISO 3166-1 alpha-2 coun- try code of the addressed PN. practiceSettingCode Classification R MUST be provided for XCF compatibility. Value MUST be set to "Not Used" in order to protect private patient information. XDSDocumentEntry.uniqueId ExternalIdentif R MUST hold the OID of the document. The ier document unique id value MUST be the same as the value of the document’s <ClinicalDocument/id> CDA header element. XDSDocumentEntry.patientId ExternalIdentif R MUST hold the patient identifier. The service ier consumer MUST verify that this id matches the patient Id that was discovered by the eHealth DSI Identification Service. Table 3: eHealth DSI Patient Summary Metadata Other metadata than the ones listed above SHOULD NOT be provided by the service provider and MUST NOT be processed by the service consumer. By definition only a single patient summary is provided per patient [PS Functional requirements]. If two documents are provided in response to a Patient Service list request, these MUST be different encodings of the same patient’s medical summary data (eHealth DSI pivot coded and PDF/A source coded). If document relationships are defined, an ebRIM association MUST be used for declaring the eHealth DSI pivot coded document as a transformation of the source coded document. As classification scheme urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3 MUST be used per IHE XCF. "eHealth DSI pivot" is defined as the only valid code value for the transformation: <rim:Association id="id of the association" associationType="urn:ihe:iti:2007:AssociationType:XFRM" sourceObject="UUID of the source coded document" targetObject="UUID of the eHealth DSI pivot document" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"> <rim:Classification id="id of the classification" classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3" classifiedObject="id of the association" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" nodeRepresentation="epSOS pivot"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI translation types</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Translation into eHealth DSI pivot format"/> </rim:Name> </rim:Classification> </rim:Association> Metadata (ebRIM names) Binding O eHealth DSI usage convention pt . associationType Attribute R MUST be "urn:ihe:iti:2007:AssociationType:XFRM" sourceObject Attribute R MUST be UUID of the source coded document targetObject Attribute R MUST be UUID of the eHealth DSI pivot document NCPeH_Components_Specifications_v5.0.0 Page 32 of 84  Association Documentation Main O MAY be empty. MAY be ignored by the service consumer. MAY contain a description of the Association according to the Association Documentation object as used by IHE. classificationSheme classification O MUST be "urn:uuid:abd807a3-4432-4053- 87b4- fd82c643d1f3" classifiedObject Attribute O MUST be I.D. of the association nodeRepresentation Attribute O MUST be "eHealth DSI pivot" codingScheme rim:Slot O MUST be "eHealth DSI translation types" and "Translation into eHealth DSI pivot format" If a warning is to be transmitted to the HP (see section 3.1.4) the ebXML Registry Error mechanism MUST be used with a syntax as defined in section 3.43.5 of [IHE ITI TF-2b]. As the location of the warning is implied, the respective location attribute SHOULD be empty. The following table lists the eHealth DSI defined warning codes: Warning Condition and Severity ResponseStatus eHealth DSI Warning Code (error- Message Code (codeContext attribute) attribute) Not all of the requested encodings are PartialSuccess Rendering incomplete 4101 provided (e.g. due to inability to transcode a certain national code). (ERROR) The HP MUST consider additionally the Success Source coded document 2102 source coded document because it MAY must be considered contain information that is not included in the eHealth DSI pivot CDA (e.g. because field were nullified due to missing code mappings) (WARNING) 3.3.1.5 Response Message (No Patient Summary Provided) If the eHealth DSI Patient Service provider is unable to respond with the patient’s summarised medical data in the requested encoding it MUST respond with a ListResponse message that only contains a <AdhocQueryResponse/RegistryResponse>element. For a full list of error messages defined for IHE X* see table 4.1-11 in [IHE ITI TF-3]. The following table lists the additional, eHealth DSI-specific response status types and error/warning/info codes to be used within the <RegistryErrorList> element. Condition and Severity Response Message Code Action to be taken Status The patient has not given Failure No Consent 4701 The HP SHOULD ask the patient to give consent to the requested consent to the requested service in service. (ERROR) country B. If the patient gives consent, the consent MUST be transmitted to country-A by using the respective operation of the eHealth DSI consent service. If such consent giving procedure is accepted by country A, HP SHOULD re-issue the request for medical data. NCPeH_Components_Specifications_v5.0.0 Page 33 of 84  Country A requests a higher Failure Weak 4702 If possible, the HP SHOULD log in authentication trust level than Authenticatio again with a stronger mechanism (e.g. assigned to the HP (e.g. n smartcard) and re-issue the request with password-based login is not the respective identity assertion. accepted for the requested operation). (ERROR) Either the security policy of Failure Insufficient 4703 If the HP can switch to another country A or a privacy policy Rights (appropriate) role, he SHOULD do so of the patient (that was given and re-issue the request. in country A) does not allow the requested operation to be performed by the HP (ERROR). No patient summary is Success No Data 1102 - registered for the given patient. (WARNING) If PDF-coded patient Success Unsupported 4201 The service consumer SHOULD re- summary is requested: Feature issue the request with another encoding. Country A does not provide the (optional) source coded version of the patient summary (INFO) The query argument slots Failure Unknown 4202 The service consumer SHOULD re- used by the service consumer Signifier issue the request with another set of are not supported by the query arguments. service provider. (ERROR) The requested encoding Failure Transcoding 4203 The service consumer SHOULD re- cannot be provided due to a Error issue the request with another encoding. transcoding error. (ERROR) 4204 The service provider is un- Failure Unknown The service consumer MAY re-issue able to evaluate the given Filter the request using another filter argument values (ERROR). expression. 3.3.1.6 Example Response Message The following message is a possible response to the sample request message given in section 3.3.1.2. The patient’s country of affiliation responds with both encodings. No MTOM optimization has been done (since this is a wire-format only optimization). <soapenv:Envelope> <soapenv:Header>....</soapenv:Header> <soapenv:Body> <query:AdhocQueryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> <rim:RegistryObjectList> <!— eHealth DSI pivot CDA patient summary document --> <rimext:ExtrinsicObject id="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" lid="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" objectType="urn:uuid:7edca82f-054d-47f2-a032- 9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"> <!-- These attributes are required by XCA but not used by eHealth DSI. They will be ignored by the eHealth DSI service consumer (NCP-B) --> <rim:Slot name="creationTime"> <rim:ValueList> <rim:Value>20100524</rim:Value> </rim:ValueList> </rim:Slot> NCPeH_Components_Specifications_v5.0.0 Page 34 of 84  <rim:Slot name="languageCode"> <rim:ValueList> <rim:Value>en-us</rim:Value> </rim:ValueList> </rim:Slot> <!-- set to same value as Patient ID (required by XCA) --> <rim:Slot name="sourcePatientId"> <rim:ValueList> <rim:Value>90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Patient Summary"/> </rim:Name> <rim:Description/> <rim:VersionInfo versionName="1.1"/> <!-- HealthcareFacilityType Code --> <rim:Classification id="urn:uuid:5c678da8-6ffa-4a85-90f6-cb2f914d482f" lid="urn:uuid:5c678da8-6ffa-4a85-90f6- cb2f914d482f" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" nodeRepresentation="Not Used"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value> eHealth DSI Healthcare Facility Type Codes-Not Used </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Not Used"/> </rim:Name> </rim:Classification> <!-- PracticeSetting Code --> <rim:Classification id="urn:uuid:b01599e3-79a6-4322-b5fc-f32ada9ee7f4" lid="urn:uuid:b01599e3-79a6-4322-b5fc-f32ada9ee7f4" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" nodeRepresentation="Not Used"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value> eHealth DSI Practice Setting Codes-Not Used </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Not Used"/> </rim:Name> </rim:Classification> <!-- Confidentiality Code --> <rim:Classification id="urn:uuid:d0dc74b9-f013-4639-b9c2-fac2420af0dd" lid="urn:uuid:d0dc74b9-f013-4639-b9c2-fac2420af0dd" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" nodeRepresentation="Not Used"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value> eHealth DSI Confidentiality Codes-Not Used </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Not Used"/> </rim:Name> </rim:Classification> <!-- End of attributes not used by eHealth DSI --> <!-- Class Code - (60591-560591-5) --> <rim:Classification id="urn:uuid:c33ca26a-29b4-45be-a9b9-de60adca4c64" lid="urn:uuid:c33ca26a-29b4-45be-a9b9- de60adca4c64" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" nodeRepresentation="60591-5"> NCPeH_Components_Specifications_v5.0.0 Page 35 of 84  <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>2.16.840.1.113883.6.1</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Patient Summary"/> </rim:Name> </rim:Classification> <!-- Type Code - (60591-5) --> <rim:Classification id="urn:uuid:87a7cfc2-a956-4d6e-af30-c7e78809c95f" lid="urn:uuid:87a7cfc2-a956-4d6e-af30-c7e78809c95f" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" nodeRepresentation="60591-5"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>2.16.840.1.113883.6.1</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Patient Summary"/> </rim:Name> </rim:Classification> <!-- Format Code --> <rim:Classification id="urn:uuid:ae68bdf8-4f32-4829-8313-2dd39ea3ab2d" lid="urn:uuid:ae68bdf8-4f32-4829-8313-2dd39ea3ab2d" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481" nodeRepresentation="eHealth DSI coded summary"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI formatCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="eHealth DSI Coded Summary"/> </rim:Name> </rim:Classification> <!-- Patient ID --> <rim:ExternalIdentifier id="urn:uuid:982f1551-5901-4bc5-8870-801181941817" lid="urn:uuid:982f1551-5901-4bc5-8870-801181941817" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:ExternalIdentifier" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO" registryObject="urn:uuid:fbf2ea29- 3aa3-4bc5-9187-01d7b6b0f481"> <rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.patientId"/> </rim:Name> </rim:ExternalIdentifier> <!-- Unique ID --> <rim:ExternalIdentifier id="urn:uuid:c67e3a92-5300-448d-9af2-0a37e9f129bf" lid="urn:uuid:c67e3a92-5300-448d-9af2-0a37e9f129bf" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:ExternalIdentifier" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.42.20100103225206.3.3" registryObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187-01d7b6b0f481"> <rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.uniqueId"/> </rim:Name> </rim:ExternalIdentifier> <!-- Document contents, before MTOM optimization --> <rimext:Document> UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi..... </rimext:Document> </rimext:ExtrinsicObject> <!—eHealth DSI source coded PDF patient summary document --> <rimext:ExtrinsicObject id="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" lid="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml- regrep:StatusType:Approved" mimeType="text/xml"> NCPeH_Components_Specifications_v5.0.0 Page 36 of 84  <!-- These attributes are required by XCA but not used by eHealth DSI. They will be ignored by the eHealth DSI service consumer (NCP-B) --> <rim:Slot name="creationTime"> <rim:ValueList> <rim:Value>20100524</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="languageCode"> <rim:ValueList> <rim:Value>en-us</rim:Value> </rim:ValueList> </rim:Slot> <!-- set to same value as Patient ID (required by XCA) --> <rim:Slot name="sourcePatientId"> <rim:ValueList> <rim:Value> 90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name/> <rim:Description/> <rim:VersionInfo versionName="1.1"/> <!-- HealthcareFacilityType Code --> <rim:Classification id="urn:uuid:7dda3d1e-8d96-4fee-b691-f1810d44bc8d" lid="urn:uuid:7dda3d1e-8d96-4fee-b691-f1810d44bc8d" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:f33fb8ac-18af-42cc-ae0e-ed0b0bdb91e1" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" nodeRepresentation="Not Used"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value> eHealth DSI Healthcare Facility Type Codes-Not Used </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Not Used"/> </rim:Name> </rim:Classification> <!-- PracticeSetting Code --> <rim:Classification id="urn:uuid:89a73ab3-344a-4098-b827-aca8dea078ef" lid="urn:uuid:89a73ab3-344a-4098-b827- aca8dea078ef" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:cccf5598-8b07-4b77-a05e-ae952c785ead" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" nodeRepresentation="Not Used"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value> eHealth DSI Practice Setting Codes-Not Used </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Not Used"/> </rim:Name> </rim:Classification> <!-- Confidentiality Code --> <rim:Classification id="urn:uuid:fa176711-e83a-4fb2-95a3-a4810b0351fa" lid="urn:uuid:fa176711-e83a-4fb2-95a3- a4810b0351fa" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:f4f85eac-e6cb-4883-b524-f2705394840f" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" nodeRepresentation="Not Used"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value> eHealth DSI Confidentiality Codes-Not Used </rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Not Used"/> </rim:Name> </rim:Classification> NCPeH_Components_Specifications_v5.0.0 Page 37 of 84  <!-- End of attributes not used by eHealth DSI --> <!-- Class Code - Patient Summary (60591-5) --> <rim:Classification id="urn:uuid:8a07ab13-1685-452f-9363-c89a37d9eb5b" lid="urn:uuid:8a07ab13-1685-452f-9363-c89a37d9eb5b" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:41a5887f-8865-4c09-adf7-e362475b143a" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" nodeRepresentation="60591-5"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>2.16.840.1.113883.6.1</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Patient Summary"/> </rim:Name> </rim:Classification> <!-- Type Code - Patient Summary (60591-5) --> <rim:Classification id="urn:uuid:c7cffb04-3537-4e8b-963d-f2f639c734de" lid="urn:uuid:c7cffb04-3537-4e8b-963d-f2f639c734de" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:f0306f51-975f-434e-a61c-c59651d33983" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" nodeRepresentation="60591-5"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>2.16.840.1.113883.6.1</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="Patient Summary"/> </rim:Name> </rim:Classification> <!-- Format Code --> <rim:Classification id="urn:uuid:ca064887-589c-408a-be6f-b7844f473ee6" lid="urn:uuid:ca064887-589c-408a-be6f- b7844f473ee6" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" classificationScheme="urn:uuid:a09d5840-386c-46f2-b5ad-9c3699a4309d" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" nodeRepresentation="urn:ihe:iti:xds- sd:pdf:2008"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI formatCodes</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString xml:lang="en" charset="UTF-8" value="PDF/A Coded Document"/> </rim:Name> </rim:Classification> <!-- Patient ID --> <rim:ExternalIdentifier id="urn:uuid:27d19a5d-7850-4c37-9499-a42fe6fdd5c8" lid="urn:uuid:27d19a5d-7850-4c37-9499-a42fe6fdd5c8" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:ExternalIdentifier" identificationScheme="urn:uuid:58a6f841-87b3-4a3e-92fd-a8ffeff98427" value="90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO" registryObject="urn:uuid:a1c7a9ac- 83aa-4eaf-b5e3-d355b57a5016"> <rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.patientId"/> </rim:Name> </rim:ExternalIdentifier> <!-- Unique ID --> <rim:ExternalIdentifier id="urn:uuid:81854cc8-2b26-45d6-8132-9f9c7eb2e5ae" lid="urn:uuid:81854cc8-2b26-45d6-8132- 9f9c7eb2e5ae" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:ExternalIdentifier" identificationScheme="urn:uuid:2e82c1f6-a085-4c72-9da3-8640a32e42ab" value="1.42.20100103225206.3.2" registryObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016"> <rim:Name> <rim:LocalizedString xml:lang="en-us" charset="UTF-8" value="XDSDocumentEntry.uniqueId"/> </rim:Name> </rim:ExternalIdentifier> <!-- Document contents, before MTOM optimization --> <rimext:Document> UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi.... NCPeH_Components_Specifications_v5.0.0 Page 38 of 84  </rimext:Document> </rimext:ExtrinsicObject> <rim:Association id="urn:uuid:f4618a30-a7fb-49a3-b27f-d1994b9c4e32" lid="urn:uuid:f4618a30-a7fb-49a3-b27f- d1994b9c4e32" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" associationType="urn:ihe:iti:2007:AssociationType:XFRM" sourceObject="urn:uuid:fbf2ea29-3aa3-4bc5-9187- 01d7b6b0f481" targetObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016"> <rim:Classification id="urn:uuid:8ec64c7e-8b7d-4d63-8741-c5a5890e5af3" lid="urn:uuid:8ec64c7e-8b7d-4d63-8741- c5a5890e5af3" classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3" classifiedObject="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" nodeRepresentation="epSOS pivot"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI translation types</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Translation into eHealth DSI pivot format"/> </rim:Name> </rim:Classification> </rim:Association> </rim:RegistryObjectList> </query:AdhocQueryResponse> </soapenv:Body> </soapenv:Envelope> 3.3.2 Security Audit Considerations The service consumer MUST write an audit trail entry according to the HP Assurance Audit Schema. The service provider MUST write an audit trail entry according to the Patient Privacy Audit Schema. The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X). eHealth DSI Instance Opt. Description Event R Audited event Requesting Point of Care R/X HCPO that issued the original request. This category MUST be filled by the service consumer. It MUST NOT be provided by the service provider. Human Requestor R HP that triggered the request Source Gateway R Service consumer node address at the country of Care Target Gateway R Service provider node address at the country of the patient’s affiliation Audit Source R Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants Patient R Patient Event Target R Subject to the Query Error Message O Only used in case that the request handling was not completed successfully For the Event Target Category the following fields MUST be provided: Field Name Opt. Value Constraints ParticipantObjectTypeCode R MUST be "2" (System Object) ParticipantObjectTypeCodeRole R MUST be "24" (Query) ParticipantObjectIDTypeCode R MUST be "10" (Search Criteria) NCPeH_Components_Specifications_v5.0.0 Page 39 of 84  ParticipantObjectID R MUST be string-encoded UUIDs of the returned documents 3.3.3 Protocol Requirements The eHealth DSI Patient Service List() request and response messages will be transmitted using synchronous Web Services Exchange, according to the requirements specified in section 4.3 of this document. Port types and bindings MUST be used as defined in the WSDL given in section 6.4.2 of this document. Acc. to this the eHealth DSI Patient Service List() operation’s request and response data MUST be contained within the message body as follows: eHealth DSI Patient Service Message Body List request CrossGatewayQueryRetrieve_Message (see section 6.4.2) List response CrossGatewayQueryRetrieveResponse_Message (see section 6.4.2) The request message MUST be protected by the service consumer (NCP-B) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. The response message MUST be protected by the service provider (NCP-A) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. 3.4 eHealth DSI Order Service The eHealth DSI Order Service is used to share an identified patient’s ePrescriptions between the patient’s country of affiliation and the country of care. Both countries are represented by their respective NCPs. Figure 10 - Order Service Interface The implementation of the eHealth DSI Order Service is based on the following standards: - ebRIM: OASIS/ebXML Registry Information Model v3.0 [OASIS ebRIM 3.0] - ebRS: OASIS/ebXML Registry Services Specifications v3.08 [OASIS ebRS 3.0] - MTOM: SOAP Message Transmission Optimization Mechanism [W3C MTOM] - XOP: XML-binary Optimized Packaging [W3C XOP] and: - XCF: IHE Cross-Community Fetch [IHE XCF] For discovery and localisation of the Order Service instance that is responsible for providing access to the identified patient’s data see section 2.1.4 of this document. 3.4.1 List() Operation The eHealth DSI Order Service list() operation is implemented as an IHE XCF Cross- Gateway Fetch transaction. It is fully compliant with the ebRS 3.0 standard. The eHealth DSI Order Service list() operation includes the documents listed in the response meta-data, just like they would have been included in Cross-Gateway Retrieve (SOAP 1.2 MTOM with XOP encoding attachments. 8 The integration of ebRS and MTOM as used by eHealth DSI is not compatible with the current version of OASIS ebRS. NCPeH_Components_Specifications_v5.0.0 Page 40 of 84 3.4.1.1 Request Message The list() request is initiated by an HP in the country of care for retrieving the available ePrescription documents of an identified patient. The respective request message builds upon the IHE XCF Cross-Gateway Fetch request message. The <AdhocQueryRequest/> element that encapsulates the query parameters MUST be used as follows for eHealth DSI: Element Name eHealth DSI Usage Convention ResponseOption/@returnComposedObjects MUST be "true" ResponseOption/@returnType MUST be "leafClassWithRepositoryItem" AdhocQuery Container for holding the ebML stored query arguments. All arguments MUST be encoded as query slots (see table below). AdhocQuery@id MUST be "urn:uuid:f2072993-9478-41df-a603- 8f016706efe8" which indicates a Fetch (which is an adaption of the findDocuments Query as defined in ITI TF-2a:3.18.1) Only synchronous web services exchange MUST be used. The XDS Affinity Domain Option only applies to the national environment. Therefore it MUST NOT be used for NCP-2-NCP message exchange. Stored query argument slots MUST be defined for the patient identifier and the document class code. The document format code and the document type code MAY be given. Other argument slots than the ones listed below MUST be ignored by the service provider and SHOULD NOT be issued by the service consumer. Slot Name Opt Slot Value $XDSDocumentEntryPatientId R Equals to the patient identifier that was provided by the eHealth DSI Identification Service (encoded as HL7 v3 II data type) $XDSDocumentEntryStatus R Only approved documents MUST be returned: 'urn:oasis:names:tc:ebxml-regrep: StatusType:Approved' $XDSDocumentEntryClassCode R ePrescription LOINC code ("57833-6") coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/Code- Scheme. As classification scheme 2.16.840.1.113883.6.1 MUST be used: '57833-6^^2.16.840.1.113883.6.1' $XDSDocumentEntryTypeCode O ePrescription LOINC code ("57833-6") coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/Code- Scheme. As classification scheme 2.16.840.1.113883.6.1 MUST be used: '57833-6^^2.16.840.1.113883.6.1' $XDSDocumentEntryFormatCode O Format qualifier as defined in [CDA templates]; see table below for details on applying these codes to the retrieval of a patient’s available ePrescriptions. Only encodings of ePrescription documents that comply to the requested format code will be returend by the service provider. If this stored query slot is omitted, the service provider MUST respond with all available encodings. For the document format only the format codes defined in [CDA templates] and listed in the following table MUST be used. Document Format Format Code Document content NCPeH_Components_Specifications_v5.0.0 Page 41 of 84  eHealth DSI pivot coded urn:epSOS:ep:pre:2010 HL7 CDA document acc. [CDA templates]. ePrescription The patient’s country of affiliation MUST be able to provide the patient’s available ePrescriptions in this format. PDF/A source coded urn:ihe:iti:xds-sd:pdf:2008 CDA-enveloped PDF/A encoding of the document original document without any semantic transformation. The patient’s country of affiliation MUST be able to provide the patient’s available ePrescriptions in this format. 3.4.1.2 Example Request Message The following excerpt from a eHealth DSI Order Service list() request message shows an IHE XCF based Cross-Gateway Fetch request that contains argument slots for retrieving the available ePrescriptions (LOINC code 57833-6) of an identified patient (patient identifier 90378912821). In this example the service consumer does not specify the requested encoding. Therefore the service provider MUST deliver both encodings (eHealth DSI pivot and PDF/A) for all available ePrescriptions. <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" ... > <soapenv:Header> ... </soapenv:Header> <soapenv:Body> <query:AdhocQueryRequest> <query:ResponseOption returnComposedObjects="true" returnType="LeafClassWithRepositoryItem"/> <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> <rim:Slot name="$XDSDocumentEntryPatientId"> <rim:ValueList> <rim:Value> '90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO' </rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryStatus"> <rim:ValueList> <rim:Value> ('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved') </rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryClassCode"> <rim:ValueList> <rim:Value>('57833-6^^2.16.840.1.113883.6.1') </rim:Value> </rim:ValueList> </rim:Slot> </rim:AdhocQuery> </query:AdhocQueryRequest> </soapenv:Body> </soapenv:Envelope> 3.4.1.3 Expected Actions The eHealth DSI Order Service provider shall respond to a ListRequest message with the ListResponse message containing - the identified patient’s available ePrescriptions together with a status notification (full success scenario, see section 3.4.1.4) or - an error message (no ePrescriptions provided, see section 3.4.1.5). The eHealth DSI Order Service provider MUST verify that the requesting service user has sufficient rights to access the available ePrescriptions of the identified patient. In case of an error that relates to the transmission of the request or the processing of the eHealth DSI security token, the eHealth DSI Order Service provider MUST respond with a fault message according to section 4.4 of this document. NCPeH_Components_Specifications_v5.0.0 Page 42 of 84 3.4.1.4 Response Message (Full Success Scenario) Depending on the requested format code the eHealth DSI list() response contains the eHealth DSI pivot encoded ePrescription documents, the PDF/A source coded ePrescription documents of the identified patient or both sets of documents. If both encodings are provided, a 1:1 association between any source coded PDF document and its derived eHealth DSI pivot CDA coded document MUST be given. The respective message builds upon to the IHE XCA Cross-Gateway Fetch response and Cross-Gateway Fetch Response messages, by creating a new combined QueryRetrieve- alike message9. The fields defined for the eHealth DSI Order Service ListResponse message MUST be used as follows: Element Name eHealth DSI Usage Convention Query:AdhocQueryResponse Response message acc to IHE XCA Cross-Gateway Access response message [IHE XCF] @status For the full success scenario the response status MUST be set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" or "urn:ihe:iti:2007:ResponseStatusType:PartialSuccess" (for details see table below) rs:RegistryErrorList In case that a warning is given by the service provider, this element holds the respective warning codes and messages. It must be used acc. to section 4.1.13 of [IHE ITI TF-3] rim:RegistryObjectList This element MUST be provided for the full success scenario. It MUST at least contain one child <rim:ExtrinsicObject/> element. rim:ExtrinsicObject For each instance of a ePrescription document a <rim:ExtrinsicObject/> element MUST be provided. Each <rim:ExtrinsicObject/> element is described and classified by metadata acc. to Table 4 below. rimext:Document This element MUST appear as the last element child of an <rim:ExtrinsicObject/> element. It may appear zero or one times. This element contains the base 64 encoded content of the document. The document contents are associated with the DocumentEntry (ExtrinsicObject) metadata by the fact that it is nested inside it within the XML. The base64 encoded document content MAY be encrypted. How encryption is applied and how the encryption key is negotiated should be subject to an additional specification on advanced security safeguards. Each provided ePrescription document and each of its encodings (eHealth DSI pivot and/or source coded PDF) MUST be further classified by metadata. The following table lists the usage conventions that have to be followed for the eHealth DSI Order Service response message. If not stated otherwise the classification schemes as defined in section 4.3.1.2 of [IHE ITI TF-3] MUST be used. If no restrictions on metadata values are given, the metadata elements MUST be used as per [IHE XCF]. Metadata (ebRIM names) Binding Opt. eHealth DSI usage convention status Attribute R MUST be "urn:oasis:names:tc:ebxml- regrep:StatusType:Approved" mimeType Attribute R MUST be "text/xml" for both eHealth DSI pivot CDA and CDA-wrapped PDF 9 XCF has been specified and currently is in Trial Implementation. NCPeH_Components_Specifications_v5.0.0 Page 43 of 84  Name Main R MAY be empty. MUST be ignored by the service consumer. Description Main R Must contain Product Name/Generic Substance Name, Dosage Form and Strength. VersionInfo Main R MUST be "1" creationTime rim:Slot O MAY be omitted by the service provider and MAY be ignored by the service consumer. If given, the value MUST be encoded as HL7 v2 Date Time "YYYY[MM[DD[hh[mm[ss]]]]]" hash rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. languageCode rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. repositoryUniqueId rim:Slot O MAY be omitted by the service provider and MAY be processed by the service consumer in an IHE-compatible NI-scenario. serviceStartTime rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service serviceEndTime consumer. size rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. sourcePatientId rim:Slot R MUST contain the same value as XDSDocumentEntry.PatientId (see below). sourcePatientInfo rim:Slot X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and documents. Therefore all metadata elements that might carry medical or social information MUST be omitted. classCode Classification R Patient summary LOINC code ("57833-6"). As classification scheme "urn:oid:2.16.840.1.113883.6.1" MUST be used eventCodeList Classification O ClassficationScheme: urn:uuid:2c6b8cb7-8b2a- 4051-b291-b1ae6a575ef4 NodeRepresentation="ATC-code code" Valuelist/Value=2.16.840.1.113883.6.73 Name="ATC-code Display Name" MAY be omitted by the service provider (only in the case that the product does not have an ATC- code) and MAY be ignored by the service consumer. NCPeH_Components_Specifications_v5.0.0 Page 44 of 84  eventCodeList Classification R ClassficationScheme: urn:uuid:2c6b8cb7-8b2a- 4051-b291-b1ae6a575ef4 • code: urn:ihe:iti:xdw:2011:eventCode:open codingScheme: 1.3.6.1.4.1.19376.1.2.3 • code: urn:ihe:iti:xdw:2011:eventCode:closed codingScheme: 1.3.6.1.4.1.19376.1.2.3 If the ePrescription is not dispensable the eventCode "Closed" MUST be used. Otherwise the eventCode "Open" MUST be used. MAY be ignored by the service consumer. Therefore measures to disallow the prescription of Non-dispensable products must be in place if the list contains these non-dispensable products. author Classification X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and documents. Therefore all metadata elements that might carry medical or social information MUST be omitted. confidentialityCode Classification R MUST be provided for XCF compatibility but MAY be ignored by the service consumer. Value SHOULD be set to "N", as long as the Minimal formatCode Classification R MUST MetadatabeProfile "urn:epSOS:ep:pre:2010" is not pub- lished. for eHealth DSI pivot CDA and "urn:ihe:iti:xds-sd:pdf:2008" for eHealth DSI source coded PDF (see [CDA templates]). healthcareFacilityTypeCode Classification R MUST be provided for XCF compatibility and correct addressing. Value MUST be set to ISO 3166-1 alpha-2 country code of the addressed PN. practiceSettingCode Classification R MUST be provided for XCF compatibility. Value MUST be set to "Not Used" in order to protect private patient information. XDSDocumentEntry.uniqueId ExternalIdentifier R MUST hold the OID of the document. The document unique id value MUST be the same as the value of the document’s <ClinicalDocument/id> CDA header element. XDSDocumentEntry.patientId ExternalIdentifier R MUST hold the patient identifier. The service consumer MUST verify that this id matches the patient Id that was discovered by the eHealth DSI Identification Service. Table 4: eHealth DSI ePrescription Metadata Other metadata than the ones listed above MUST NOT be provided by the service provider. Multiple ePrescriptions (with up to two encodings) MAY be available per patient. An ebRIM association MUST be used for declaring the eHealth DSI pivot coded document as a transformation of the source coded document. As classification scheme urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3 MUST be used per IHE-XCF. "eHealth DSI pivot" is defined as the only code value for this eHealth DSI valid transformation. <rim:Association id="id of the association" associationType="urn:ihe:iti:2007:AssociationType:XFRM" sourceObject="UUID of the source coded document" targetObject="UUID of the eHealth DSI pivot document" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"> <rim:Classification id="id of the classification" classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3" classifiedObject="id of the association" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" nodeRepresentation="epSOS pivot"> NCPeH_Components_Specifications_v5.0.0 Page 45 of 84 <rim:Name> <rim:LocalizedString value="Translation into eHealth DSI pivot format"/> </rim:Name> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI translation types</rim:Value> </rim:ValueList> </rim:Slot> <rim:name> <rim:LocalizedString value="Translation into eHealth DSI pivot format" /> </rim:Name> </rim:Classification> </rim:Association> If a warning is to be transmitted to the HP (see section 3.1.4) the ebXML Registry Error mechanism MUST be used with a syntax as defined in section 3.43.5 of [IHE ITI TF-2b]. The following table lists the eHealth DSI defined warning codes: Warning Condition and Response eHealth DSI Warning Code Target Severity Status Message (errorCode (codeContext attribute) attribute) If no format qualifier is given: PartialSuccess Rendering incomplete 4101 ID of the Not all of the requested provided encodings are provided (e.g. ePrescription due to inability to transcode a document that certain national code). is missing (ERROR) alternative encodings If eHealth DSI pivot CDA PartialSuccess Collection incomplete 4102 None format is requested: NCP-A cannot provide the minimum dataset for all its registered ePrescriptions. The HP MAY request the source coded PDF. (ERROR) The HP MUST consider Success Source coded document 2102 IDs of the additionally the source coded must be considered affected document because it MAY documents contain information that is not included in the eHealth DSI pivot CDA (e.g. because field were nullified due to missing code mappings) (WARNING) The prescribed medication has Success Dependencies not checked 2104 None not been checked for interde pendencies with the patient’s cur rent medication (e.g. because of country A legal restrictions). (WARNING) The prescription is available Success No reimbursement 2105 IDs of the for dispensation but not valid affected for reimbursement. ePrescription (WARNING) s 3.4.1.5 Response Message (No ePrescriptions Provided) If the eHealth DSI Order Service provider is unable to respond with the patient’s NCPeH_Components_Specifications_v5.0.0 Page 46 of 84 ePrescription data in the requested encoding it MUST respond with a ListResponse message that only contains a <RetrieveDocumentSetResponse/RegistryResponse> element. For a full list of error messages defined for IHE X* see table 4.1-11 in [IHE ITI TF-3]. The following table lists the additional, eHealth DSI-specific response status types and error/warning/info codes to be used within the <RegistryErrorList> element. Condition and Severity Response Message Code Action to be taken Status The patient has not given Failure No Consent 4701 The HP SHOULD ask the patient to consent to the requested give consent to the requested service service. in country B. If the patient gives consent, the consent MUST be transmitted to country-A by using the respective operation of the eHealth DSI consent service. If such consent giving procedure is accepted by country A, HP SHOULD re-issue the request for medical data. Country A requests a higher Failure Weak 4702 If possible, the HP SHOULD log in authentication trust level than Authenticati again with a stronger mechansims (e.g. assigned to the HP (e.g. on smartcard) and re-issue the request with password-based login is not the respective identity assertion. accepted for the requested operation). Either the security policy of Failure Insufficient 4703 If the HP can switch to another country A or a privacy policy of Rights (approriate) role, he SHOULD do so the patient (that was given in and re-issue the request. country A) does not allow the requested operation to be performed by the HP. There is no ePrescription data Success No Data 1101 - registered for the given patient (INFO) None of the required encodings Failure Transcoding The service provider MUST write an 4203 can be provided, e.g. due to Error error log entry acc. to its respective transcoding errors. (ERROR) policies. The ePrescription registry is Failure Registry 4103 not accessible (ERROR) Failure There is ePrescription data Failure Data Access 4104 The service consumer MAY re-issue registered for the patient but the Failure the request. service provider is unable to access it (ERROR) The service provider is unable Failure Unknown 4204 The service consumer MAY re-issue to evaluate the given argument Filter the request using another filter values (ERROR) expression. 3.4.1.6 Example Response Message In this section three possible response messages to the previously sketched request message are shown. The first example response message covers the case where a single ePrescription is discovered and provided as both eHealth DSI pivot and source PDF encoding. MTOM optimization is not shown as this is a wire-format only transformation. As the eHealth DSI Order Service list() response message is very similar to the eHealth DSI Patient Service list() response message (see section 3.3.1.6 for an example) only an excerpt is shown. NCPeH_Components_Specifications_v5.0.0 Page 47 of 84  <soapenc:Envelope> <soapenv:Header>....</soapenv:Header> <soapenv:Body> <query:AdhocQueryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> <rim:RegistryObjectList> <!—eHealth DSI source coded CDA wrapped PDF ePrescription document --> <rimext:ExtrinsicObject id="urn:uuid:cf614a65-d214-4b0d-b4b8-a0be3888f847" lid="urn:uuid:cf614a65-d214-4b0d- b4b8-a0be3888f847" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"> <!-- metadata missing here (see Patient Service example) --> <!-- Document contents, before MTOM optimization --> <rimext:Document >UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</rimext:Document> </rimext:ExtrinsicObject> <!—eHealth DSI source coded CDA Pivot ePrescription document --> <rimext:ExtrinsicObject id="urn:uuid:eec764cf-9fe5-4101-8e86-33a13fb06e4a" lid="urn:uuid:eec764cf-9fe5-4101- 8e86-33a13fb06e4a" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"> <!-- metadata missing here (see Patient Service example) --> <!-- Document contents, before MTOM optimization --> <rimext:Document >UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</rimext:Document> </rimext:ExtrinsicObject> <rim:Association id="urn:uuid:b4fc4809-0096-4b76-a7b1-3135ac5e5614" lid="urn:uuid:b4fc4809-0096-4b76-a7b1- 3135ac5e5614" associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:XFRM" sourceObject="urn:uuid:eec764cf-9fe5-4101-8e86-33a13fb06e4a" targetObject="urn:uuid:cf614a65-d214-4b0d- b4b8-a0be3888f847" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"> <rim:Classification id="urn:uuid:969d2f2b-5f5a-4c24-af0a-d07d16ddaeb9" classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3" classifiedObject="urn:uuid:b4fc4809-0096-4b76-a7b1-3135ac5e5614" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" nodeRepresentation="epSOS pivot"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI translation types</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Translation into eHealth DSI pivot format"/> </rim:Name> </rim:Classification> </rim:Association> </rim:RegistryObjectList> </query:AdhocQueryResponse> </soapenv:Body> </soapenc:Envelope> The second example response message shows the case where two ePrescriptions are discovered. The first one is provided as eHealth DSI pivot and source PDF encoding. For the second one country-A is not able to transform an ePrescription to the eHealth DSI pivot format. Only the PDF encoding is provided and an information given, that eHealth DSI pivot transcoding failed for this ePrescription10. <soapenc:Envelope> <soapenv:Header>....</soapenv:Header> <soapenv:Body> <query:AdhocQueryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:PartialSuccess"> <rs:RegistryErrorList> <rs:RegistryError severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error" errorCode="2104" codeContext="Rendering incomplete"/ location="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016"> </rs:RegistryErrorList> <rim:RegistryObjectList> <!-- ePrecription 1: eHealth DSI source coded CDA wrapped PDF --> <rimext:ExtrinsicObject id="urn:uuid:cf614a65-d214-4b0d-b4b8-a0be3888f847" lid="urn:uuid:cf614a65-d214-4b0d- 10 It’s up to country A to decide on how to act in case of a failed eHealth DSI pivot translation. This example covers the case where country A transmits the source coded document only. This may e.g. make sense in cases where both country A and B share a common language. NCPeH_Components_Specifications_v5.0.0 Page 48 of 84  b4b8-a0be3888f847" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"> <!-- metadata and contents missing here (see Patient Service example) --> </rimext:ExtrinsicObject> <!-- ePrecription 1: eHealth DSI source coded CDA Pivot document --> <rimext:ExtrinsicObject id="urn:uuid:eec764cf-9fe5-4101-8e86-33a13fb06e4a" lid="urn:uuid:eec764cf-9fe5-4101- 8e86-33a13fb06e4a" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"> <!-- metadata and content missing here (see Patient Service example) --> </rimext:ExtrinsicObject> <!-- ePrecription 2: eHealth DSI source coded CDA wrapped PDF document --> <rimext:ExtrinsicObject id="urn:uuid:a1c7a9ac-83aa-4eaf-b5e3-d355b57a5016" lid="urn:uuid:a1c7a9ac-83aa-4eaf- b5e3-d355b57a5016" objectType="urn:uuid:7edca82f-054d-47f2-a032-9b2a5b5186c1" status="urn:oasis:names:tc:ebxml-regrep:StatusType:Approved" mimeType="text/xml"> <!-- metadata missing here (see Patient Service example) --> <!-- Document contents, before MTOM optimization --> <rimext:Document >UjBsR09EbGhjZ0dTQUxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</rimext:Document> </rimext:ExtrinsicObject> <!-- Association for ePrescription 1; for ePrescription 2 no association is defined because only one encoding is provided --> <rim:Association id="urn:uuid:b4fc4809-0096-4b76-a7b1-3135ac5e5614" lid="urn:uuid:b4fc4809-0096-4b76-a7b1- 3135ac5e5614" associationType="urn:oasis:names:tc:ebxml-regrep:AssociationType:XFRM" sourceObject="urn:uuid:eec764cf-9fe5-4101-8e86-33a13fb06e4a" targetObject="urn:uuid:cf614a65-d214-4b0d- b4b8-a0be3888f847" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"> <rim:Classification id="urn:uuid:969d2f2b-5f5a-4c24-af0a-d07d16ddaeb9" classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3" classifiedObject="urn:uuid:b4fc4809-0096-4b76-a7b1-3135ac5e5614" objectType="urn:oasis:names:tc:ebxml- regrep:ObjectType:RegistryObject:Classification" nodeRepresentation="epSOS pivot"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI translation types</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Translation into eHealth DSI pivot format"/> </rim:Name> </rim:Classification> </rim:Association> </rim:RegistryObjectList> </query:AdhocQueryResponse> </soapenv:Body> </soapenv:Envelope> 3.4.2 Security Audit Considerations The service consumer MUST write an audit trail entry according to the HP Assurance Audit Schema. The service provider MUST write an audit trail entry according to the Patient Privacy Audit Schema. The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X). eHealth DSI Instance Opt. Description Event R Audited event Requesting Point of Care R/X HCPO that issued the original request. This category MUST be filled by the service consumer. It MUST NOT be provided by the service provider. Human Requestor R HP that triggered the request Source Gateway R Service consumer node address at the country of Care Target Gateway R Service provider node address at the country of the patient’s affiliation Audit Source R Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants Patient R Patient Event Target R Subject to the Query NCPeH_Components_Specifications_v5.0.0 Page 49 of 84  Error Message O Only used in case that the request handling was not completed successfully For the Event Target Category the following fields MUST be provided: Field Name Opt. Value Constraints ParticipantObjectTypeCode R MUST be "2" (System Object) ParticipantObjectTypeCodeRole R MUST be "24" (Query) ParticipantObjectIDTypeCode R MUST be "10" (Search Criteria) ParticipantObjectID R MUST be string-encoded UUIDs of the returned documents 3.4.3 Protocol Requirements The eHealth DSI Order Service List() request and response messages will be transmitted using synchronous Web Services Exchange, according to the requirements specified in section 4.3 of this document. Port types and bindings MUST be used as defined in the WSDL given in section 6.4.2 of this document. Acc. to this the eHealth DSI Order Service List() operation’s request and response data MUST be contained within the message body as follows: eHealth DSI Order Service Message Body List request CrossGatewayQueryRetrieve_Message (see section 6.4.2) List response CrossGatewayQueryRetrieveResponse_Message (see section 6.4.2) The request message MUST be protected by the service consumer (NCP-B) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. The response message MUST be protected by the service provider (NCP-A) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. 3.5 eHealth DSI Dispensation Service The eHealth DSI Dispensation Service is used to share an identified patient’s eDispensation data between the patient’s country of affiliation and the country of care. Both countries are represented by their respective NCPs. Figure 11: Dispensation Service Interface The implementation of the eHealth DSI Dispensation Service is based on the following standards: - ebRIM: OASIS/ebXML Registry Information Model v3.0 [OASIS ebRIM 3.0] - ebRS: OASIS/ebXML Registry Services Specifications v3.0 [OASIS ebRS 3.0] - MTOM: SOAP Message Transmission Optimization Mechanism [W3C MTOM] - XOP: XML-binary Optimized Packaging [W3C XOP] NCPeH_Components_Specifications_v5.0.0 Page 50 of 84  and is compliant with the IHE profiles: - XDR: IHE Cross-Enterprise Reliable Exchange [IHE ITI TF-1] [IHE ITI TF-2b] For discovery and localisation of the eHealth DSI Dispensation Service instance that is responsible for providing access to the identified patient’s data see section 2.1.4 of this document. 3.5.1 Initialize() Operation The eHealth DSI Dispensation Service initialize() operation is implemented by the IHE Provide And Register DocumentSet transaction (ITI-41) as described in [IHE XDR]. 3.5.1.1 Request Message The initialize() request is initiated by an HP in the country of care for handing over dispensation notifications to the patient’s country of affiliation. Each dispensation notification consists of an eHealth DSI pivot coded eDispensation document acc. to [CDA templates] and the source coded document that encodes the same information without semantic mapping. An initialize() request MAY contain multiple eHealth DSI coded and source coded documents. The eHealth DSI Dispensation Service InitializeRequest message is a specialisation of the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE XDR]. The fields defined for the ProvideAndRegisterDocumentSetRequest message MUST be used as follows: Element Name eHealth DSI Usage Convention lcm:SubmitObjectsRequest Container that can be used to provide the metadata for the transmitted documents, the submission set and the associations between documents (see below). rim:RegistryObjectList Container that contains (pointers to) all eDispensation documents rim:ExtrinsicObject For each eDispensation document a single extrinsic object MUST be defined. There MUST be a 1:1 id-correspondence between <rim:ExtrinsicObject> elements and <ihe:Document> elements. For a list of further metadata to be provided with an eDispensation document see the table below. rimext:Document base64 encoded data for the eDispensation documents being submitted to the service provider. The <rimext:Document/> element also includes the document id attribute (rimext:Document/@id) of type xsd:anyURI to match the document ExtrinsicObject id in the metadata and providing the necessary linkage. The base64 encoded document content MAY be encrypted. How encryption is applied and how the encryption key is negotiated should be subject to an additional specification on advanced security safeguards. rim:Association For each pair of eHealth DSI coded and source coded documents an ebRIM association MUST be defined (see below for details on the encoding). The service consumer SHOULD embrace the provided documents as a single IHE XDS submission set acc. to [IHE ITI TF-2a]. The service consumer SHOULD ignore this grouping and MUST ignore all associations between documents and submission sets. The service consumer MUST NOT process any metadata assigned to the submission set, it MUST solely rely on the document metadata and contents. For each eDispensation document (either eHealth DSI coded or source coded) the NCPeH_Components_Specifications_v5.0.0 Page 51 of 84 following set of metadata MUST be provided: Slot Name Binding Slot Value id Attribute Identifer of the document. This identifier MUST be the same for <rim:ExtrinsicObject/@id> and <ihe:Document/@id>. mimeType Attribute MUST be "text/xml" objectType Attribute MUST be set acc. to section 4.3.1.2 of [IHE IT TF 3] status Attribute MUST be "urn:oasis:names:tc:ebxml- regrep:StatusType:Approved" creationTime rim:Slot MUST be given for XDR compatibility. MAY be ignored by the service provider. languageCode rim:Slot MUST be given for XDR compatibility. MAY be ignored by the service provider. sourcePatientID rim:Slot MUST be of the same value as $XDSDocumentEntryPatientId (see below) healthcareFacilityTypeCode classification MUST be provided for XCF compatibility and correct addressing. Value MUST be set to ISO 3166-1 alpha-2 country code of the addressed PN. practiceSettingCode classification MUST be provided for XDR compatibility but MAY be ignored by the service consumer. Value MUST be set to "Not Used". confidentialityCode classification MUST be provided for XDR compatibility but MAY be ignored by the service consumer. Value SHOULD be set to "N", as long as the Minimal Metadata Profile is not published. XDSDocumentClassCode classification eDispensation LOINC code ("60593-1")11 coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/Code-Scheme. As classification scheme 2.16.840.1.113883.6.1 MUST be used. XDSDocumentFormatCode classification Format qualifier as defined in [CDA templates]; $XDSDocumentEntryPatientId External identifier Equals to the patient identifier that was provided by the eHealth DSI Identification Service (encoded as HL7 v3 II data type) $XDSDocumentUniqueId External identifier MUST refer to the OID of the CDA document that is included within the <ihe:Document> element. Other metadata than the ones listed above SHOULD NOT be provided by the service provider 12. If given they MUST be ignored by the service consumer. An ebRIM association MUST be used for declaring the eHealth DSI pivot coded eDispensation document as a transformation of the source coded eDispensation document. 11 This code is a dummy that will be used for the intial NCP integration tests until a eDispensation LOINC code is approved. 12 Document linkage information (e.g. a reference to the ePrescription that is affected by the dispensation) MUST be included with the document (see [CDA templates]) and MUST NOT be part of the message metadata. NCPeH_Components_Specifications_v5.0.0 Page 52 of 84 As classification scheme urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3 MUST be used per IHE-XCA. Currently "eHealth DSI pivot" is defined as the only valid transformation: <rim:Association id="id of the association" associationType="urn:ihe:iti:2007:AssociationType:XFRM" sourceObject="UUID of the source coded document" targetObject="UUID of the eHealth DSI pivot document" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification"> <rim:Classification id="id of the classification" classificationScheme="urn:uuid:abd807a3-4432-4053-87b4-fd82c643d1f3" classifiedObject="id of the association" objectType="urn:oasis:names:tc:ebxml-regrep:ObjectType:RegistryObject:Classification" nodeRepresentation="epSOS pivot"> <rim:Slot name="codingScheme"> <rim:ValueList> <rim:Value>eHealth DSI translation types</rim:Value> </rim:ValueList> </rim:Slot> <rim:Name> <rim:LocalizedString value="Translation into eHealth DSI pivot format"/> </rim:Name> </rim:Classification> </rim:Association> 3.5.1.2 Expected Actions The eHealth DSI Dispensation Service provider shall respond to an InitializeRequest message with the InitializeResponse message containing a success indicator. The eHealth DSI Dispensation Service provider MUST verify that the requesting service user has sufficient rights to submit an eDispensation for the identified patient. It MUST verify that the eDispensation matches with an ePrescription that was issued for the identified patient. In case of an error that relates to the transmission of the request or the processing of the eHealth DSI security token, the eHealth DSI Dispensation Service provider MUST respond with a fault message according to section 4.4 of this document. 3.5.1.3 Response Message (Full Success Scenario) If the eHealth DSI Dispensation Service provider is able to decode the received message and to properly process all transmitted eDispensations it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml- regrep:ResponseStatusType:Success" If the service provider wants to respond with further information on the processing of the transmitted data or with a non-critical warning it SHOULD include an additional <RegistryErrorList> element. The severity MUST be set to "urn:oasis:names:tc:ebxml- regrep:ErrorSeverityType:Warning": <rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> <rs:RegistryErrorList> <rsRegistryError severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Warning" errorCode="...." codeContext="Processing deferred" location="" /> </rs:RegisryErrorList> </rs:RegistryResponse> The following warning messages and codes are defined: Condition and Severity Message Code Action to be taken eDisensations were received but not Processing deferred 2201 None processed 3.5.1.4 Response Message (Failure or Partial Failure Scenario) If the eHealth DSI Dispensation Service provider is able to decode the received message but the processing of one or more dispensations failed, it responds with an ebXML NCPeH_Components_Specifications_v5.0.0 Page 53 of 84 Registry Response that contains a respective status indicator (see below). The response MUST contain a RegistryErrorList element that indicates the failure condition. If none of the eDispensations was processed succesfully, the response status MUST be set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure". If at least one eDispensation was processed successfully, the response status MUST be set to "urn:ihe:iti:2007:ResponseStatusType:PartialSuccess". A failure location MUST be provided if the error does not apply to all provided eDispensation documents. It MUST NOT be given if the error applies to all provided documents. The severity of each registry error message MUST be set to "urn:oasis:names:tc:ebxml- regrep:ErrorSeverityType:Error". Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. Apart from the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for eHealth DSI: Condition and Severity Location Message Code Action to be taken No matching ePrescription OID of the No match 4105 HP-B (or NCP-B depending on was found eDispensation the concrete implementation) (ERROR) document that SHOULD check the document caused the error. IDs and re-issue the request. ePrescription has already OID of the Invalid 4106 HP-B SHOULD again query for been dispensed (ERROR) eDispensation Dispensation the list of available ePrescription. document that caused the error. Country A requests a higher - Weak 4702 If possible, the HP SHOULD log authen- tication trust level Authentication in again with a stronge than assigned to the HP mechanism (e.g. smartcard) and (e.g. password-based login re-issue the request with the is not accepted for the respective identity assertion. requested operation). (ERROR) The eDispensation service OID of the No Signature 4704 If possible, NCP-B SHOULD re- provider only accepts eDispensation issue the request with the data dispensation data that is document that signed by an HP. digitally signed by an HP. caused the error. (ERROR) The service consumer did OID of the Original data 4107 The eHealth DSI pivot coded not pro- vide the source eHealth DSI missing document MUST NOT be coded PDF document for an coded processed by the service eDispensation (ERROR) eDispensation provider. The service consumer that in not MUST re-transmit the additionally dispensation with both provided as encodings. source coded The service consumer did OID document of Pivot data 4108 The source coded document not provide the eHealth DSI the source coded missing MUST NOT be processed by the pivot coded document for eDispensation service provider. The service an eDispensation (ERROR) that in not consumer MUST retransmit the additionally dispensation with both encodings. provided as eHealth DSI pivot coded document NCPeH_Components_Specifications_v5.0.0 Page 54 of 84 3.5.1.5 Example Response Message The following example shows a possible positive resonse to the request given in section 3.5.1.2: <?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?> <env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"> <env:Header> <Action xmlns="http://www.w3.org/2005/08/addressing">urn:ihe:iti:2007:ProvideAndRegisterDocumentSet- bResponse</Action> <MessageID xmlns="http://www.w3.org/2005/08/addressing">uuid:98f4bf0c-f21a-48bc-8518- 958c9d9dc4c11</MessageID> <RelatesTo xmlns="http://www.w3.org/2005/08/addressing">uuid:98f4bf0c-f21a-48bc-8518- 958c9d9dc4c1</RelatesTo> </env:Header> <env:Body> <RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0"/> </env:Body> </env:Envelope> The following example shows a possible negative response to the request given in section 3.5.1.2: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns=...> <soapenv:Header>...</soapenv:header> <soapenv:Body> <rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure"> <rs:RegistryErrorList> <rs:RegistryError severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error" errorCode="...." codeContext="No Match" location="1.42.20100103225206.3.3" /> </rs:RegistryErrorList> </rs:RegistryResponse> </soapenv:Body> </soapenv:Envelope> 3.5.1.6 Security Audit Considerations The service consumer MUST write an audit trail entry according to the HP Assurance Audit Schema. The service provider MUST write an audit trail entry according to the Patient Privacy Audit Schema. The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X). eHealth DSI Instance Opt. Description Event R Audited event Requesting Point of Care R/X HCPO that issued the original request. This category MUST be filled by the service consumer. It MUST NOT be provided by the service provider. Human Requestor R HP that triggered the request Source Gateway R Service consumer node address at the country of Care Target Gateway R Service provider node address at the country of the patient’s affiliation Audit Source R Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants Patient R Patient NCPeH_Components_Specifications_v5.0.0 Page 55 of 84  Event Target R References to the provided dispensation documents (see below) Error Message O Only used in case that the request handling was not completed successfully For the Event Target Category the following fields MUST be provided: Field Name Opt. Value Constraints ParticipantObjectTypeCode R MUST be "2" (System Object) ParticipantObjectTypeCodeRole R MUST be "4" (Resource) ParticipantObjectIDTypeCode R MUST be "12" (URI) ParticipantObjectID R MUST be string-encoded UUIDs of the provided documents 3.5.2 Discard() Operation The eHealth DSI Dispensation Service discard() operation can be used to deprecate a previously transmitted eDispensation. The eHealth DSI Dispensation Service initialize() operation is implemented by the IHE Provide And Register DocumentSet transaction (ITI-41) as described in [IHE XDR].. 3.5.2.1 Request Message The eHealth DSI Dispensation Service discard() request is initiated by an HP in the country of care (country B) for deleting a previously transmitted eDispensation document at the patient’s country of affiliation (country A). The eHealth DSI Dispensation Service Discard message is a specialisation of the IHE Provide And Register DocumentSet transaction (ITI-41) request message as profiled in [IHE XDR]. The fields defined for the ProvideAndRegisterDocumentSetRequest message MUST be used as follow: Element Name eHealth DSI Usage Convention lcm:SubmitObjectsRequest Container that can be used to provide the metadata for the transmitted discarded document, the submission set and the associations between documents (see below). rim:RegistryObjectList Container that contains (pointers to) the eDispensation discarded document rim:ExtrinsicObject For each eDispensation document a single extrinsic object MUST be defined. There MUST be a 1:1 id-correspondence between <rim:ExtrinsicObject> elements and <ihe:Document> elements. For a list of further metadata to be provided with an eDispensation discarded document see the table below. rimext:Document base64 encoded data for the eDispensation documents being submitted to the service provider. The <rimext:Document/> element also includes the document id attribute (rimext:Document/@id) of type xsd:anyURI to match the document ExtrinsicObject id in the metadata and providing the necessary linkage. rim:Association For each pair of eHealth DSI coded and source coded documents an ebRIM association MUST be defined (see below for details on the encoding). For each eDispensation discarded document (either eHealth DSI coded or source coded) the following set of metadata MUST be provided: Slot Name Binding Slot Value NCPeH_Components_Specifications_v5.0.0 Page 56 of 84  id Attribute Identifer of the document. This identifier MUST be the same for <rim:ExtrinsicObject/@id> and <ihe:Document/@id>. mimeType Attribute MUST be "text/xml" objectType Attribute MUST be set acc. to section 4.3.1.2 of [IHE IT TF 3] status Attribute MUST be "urn:oasis:names:tc:ebxml- regrep:StatusType:Approved" creationTime rim:Slot MUST be given for XDR compatibility. MAY be ignored by the service provider. languageCode rim:Slot MUST be given for XDR compatibility. MAY be ignored by the service provider. sourcePatientID rim:Slot MUST be of the same value as $XDSDocumentEntryPatientId (see below) healthcareFacilityTypeCode classification MUST be provided for XCF compatibility and correct addressing. Value MUST be set to ISO 3166-1 alpha-2 country code of the addressed PN. practiceSettingCode classification MUST be provided for XDR compatibility but MAY be ignored by the service consumer. Value MUST be set to "Not Used". confidentialityCode classification MUST be provided for XDR compatibility but MAY be ignored by the service consumer. Value SHOULD be set to "N", as long as the Minimal Metadata Profile is not published. XDSDocumentClassCode classification eDispensation Discard code ("DISCARD-60593- 1") coded according to specification in ITI TF-2a: 3.18.4.1.2.3.4 Coding of Code/Code-Scheme. As classification scheme 2.16.840.1.113883.6.1 MUST be used even if no official LOINC code exists currently for this type of document (eDispensation Discard). XDSDocumentFormatCode classification Format qualifier as defined in [CDA templates]; $XDSDocumentEntryPatientId External identifier Equals to the patient identifier that was provided by the eHealth DSI Identification Service (encoded as HL7 v3 II data type) $XDSDocumentUniqueId External identifier MUST refer to the OID of the CDA document that is included within the <ihe:Document> element. 3.5.2.2 Expected Actions The eHealth DSI Dispensation Service provider shall discard all registry objects and documents as identified in the request. It shall respond to a DiscardRequest message with a registry response message containing a success indicator. The eHealth DSI Dispensation Service provider MUST verify that the requesting service user has sufficient rights to request a discard eDispensation operation for the identified patient. It MUST verify that the eDispensation was issued by the same HCPO that now NCPeH_Components_Specifications_v5.0.0 Page 57 of 84 wants to discard it. In case of an error that relates to the transmission of the request or the processing of the eHealth DSI security token, the eHealth DSI Dispensation Service provider MUST respond with a fault message according to section 4.4 of this document. 3.5.2.3 Response Message (Full Success Scenario) If the eHealth DSI Dispensation Service provider is able to decode the received dispensation document IDs and to properly process the request, it responds with an ebXML Registry Response with its status set to "urn:oasis:names:tc:ebxml- regrep:ResponseStatusType:Success" <rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> … </rs:RegistryResponse> 3.5.2.4 Response Message (Failure or Partial Failure Success Scenario) If the eHealth DSI Dispensation Service provider is able to decode the received dispensation document IDs but the deprecating of the dispensations failed, it responds with an ebXML Registry Response that contains a respective status indicator (see below). The response MUST contain a RegistryErrorList element that indicates the failure condition. If none of the eDispensations was deprecated successfully, the response status MUST be set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure". If at least one eDispensation was deprecated successfully, the response status MUST be set to "urn:ihe:iti:2007:ResponseStatusType:PartialSuccess". A failure location MUST be provided if the error does not apply to all to-be-deprecated eDispensation documents. It MUST NOT be given if the error applies to all documents that are to be deprecated. The severity of each registry error message MUST be set to "urn:oasis:names:tc:ebxml- regrep:ErrorSeverityType:Error". Multiple registry error messages MAY be included within a single <rs:RegistryErrorList> element. In extension to the XDS-b error messages defined in Table 4.1-11 of [IHE ITI TF-3] the following error codes are defined for eHealth DSI: Condition Location Message Code Action to be taken No matching OID of the No match 4105 The HP SHOULD check eDispensation was found document that the OID of the document could not be found and re-issue the request 4703 Request is rejected because OID of the Insufficient Patient SHOULD ensure the issuing HCPO of the document that rights that the discard request is discard request is not the caused the error issued by the same HCPO HCPO that provided the that did the dispensation. If eDispensation. the ePrescription was dispensed at another HCPO the patient MUST request for discarding at this HCPO. 2201 Request was accepted but - Processing No action needed. HP and will not be processed deferred patient MUST be aware that immediately the respective prescription cannot be dispensed again immediately. NCPeH_Components_Specifications_v5.0.0 Page 58 of 84 3.5.2.5 Response Message (Full Success Scenario) The following example shows a possible positive response to the request given in section 3.4.1.2: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns=...> <soapenv:Header>...</soapenv:Header> <soapenv:Body> <rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"> </rs:RegistryResponse> </soapenv:Body> </soapenv:Envelope> The following example shows a possible negative response to the request given in section 3.4.1.2: <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns=...> <soapenv:Header>...</soapenv:Header> <soapenv:Body> <rs:RegistryResponse status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Failure"> <rs:RegistryErrorList> <rs:RegistryError severity="urn:oasis:names:tc:ebxml-regrep:ErrorSeverityType:Error" errorCode="...." codeContext="No Match" location="1.42.20100103225206.3.3" /> </rs:RegistryErrorList> </rs:RegistryResponse> </soapenv:Body> </soapenv:Envelope> 3.5.2.6 Security Audit Considerations The service consumer MUST write an audit trail entry according to the HP Assurance Audit Schema. The service provider MUST write an audit trail entry according to the Patient Privacy Audit Schema. The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X). eHealth DSI Instance Opt. Description Event R Audited event Requesting Point of Care R/X HCPO that issued the original request. This category MUST be filled by the service consumer. It MUST NOT be provided by the service provider. Human Requestor R HP that triggered the request Source Gateway R Service consumer node address at the country of Care Target Gateway R Service provider node address at the country of the patient’s affiliation Audit Source R Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants Patient R Patient Event Target R Reference to the discarded document Error Message O Only used in case that the request handling was not completed successfully For the Event Target Category the following fields MUST be provided: NCPeH_Components_Specifications_v5.0.0 Page 59 of 84  Field Name Opt. Value Constraints ParticipantObjectTypeCode R MUST be "2" (System Object) ParticipantObjectTypeCodeRole R MUST be "4" (Resource) ParticipantObjectDataLifeCycle R MUST be "14" (logical deletion) ParticipantObjectIDTypeCode R MUST be "12" (URI) ParticipantObjectID R MUST be string-encoded UUIDs of the discarded documents 3.5.3 Protocol Requirements The eHealth DSI Dispensation Service request and response messages will be transmitted using synchronous Web Services Exchange, according to the requirements specified in section 4.3 of this document. Port types and bindings MUST be used as defined in the WSDLs given in sections 6.3 of this document. According to this the eHealth DSI Dispensation Service operations’ request and response data MUST be contained within the message body as follows: eHealth DSI Dispensation Service Message Body Put and Discard request ProvideAndRegisterDocumentSet-b_Message (see section 6.3) Put and Discard response ProvideAndRegisterDocumentSet-bResponse_Message (see section 6.4.3) eHealth DSI Dispensation Service request messages MUST be protected by the service consumer (NCP-B) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. eHealth DSI Dispensation Service response messages MUST be protected by the service provider (NCP-A) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. 3.6 eHealth DSI Original Clinical Document Service Figure 10 - OrCD Service Interface The eHealth DSI Original Clinical Document Service is used to share documents which faced no modification following its creation in the Country of Affiliation. Authorized Original Clinical Documents are:  Laboratory results  Hospital discharge reports  Medical imaging reports (with or without access to referenced images  Medical images The implementation of the eHealth DSI Dispensation Service is based on the following standards: NCPeH_Components_Specifications_v5.0.0 Page 60 of 84  - ebRIM: OASIS/ebXML Registry Information Model v3.0 [OASIS ebRIM 3.0] - ebRS: OASIS/ebXML Registry Services Specifications v3.013 [OASIS ebRS 3.0] - MTOM: SOAP Message Transmission Optimization Mechanism [W3C MTOM] - XOP: XML-binary Optimized Packaging [W3C XOP] and is compliant with the IHE profiles: - XDR: IHE Cross-Enterprise Reliable Exchange [IHE ITI TF-1] [IHE ITI TF-2b] For discovery and localisation of the Original Clinical Document Service instance that is responsible for providing access to the identified patient’s data see section 2.1.4 of this document. 3.6.1 List() Operation The eHealth DSI Original Clinical Document Service list() operation is implemented as IHE XCF Cross-Gateway Fetch transaction. It is fully compliant with the ebRS 3.0 standard. The eHealth DSI Patient Service list() operation includes the documents listed in the response meta-data, just like they would have been included in Cross- Gateway Fetch (SOAP 1.2 MTOP with XOP encoding attachments). 3.6.1.1 Request Message The list() request is initiated by an HP in the country of care for retrieving the original clinical document of an identified patient. The respective request message builds upon the IHE XCF Cross-Gateway Fetch request message. The <AdhocQueryRequest/> element that encapsulates the query parameters MUST be used as follows for eHealth DSI: Element Name eHealth DSI Usage Convention ResponseOption/@returnComposedObjects MUST be "true" ResponseOption/@returnType MUST be "LeafClassWithRepositoryItem" (XCF) AdhocQuery Container for holding the ebML stored query arguments. All arguments MUST be encoded as query slots (see table below). AdhocQuery@id MUST be "urn:uuid:f2072993-9478-41df-a603- 8f016706efe8" which indicates a Fetch (which is an adaption of the findDocuments Query as defined in ITI TF-2a:3.18.1) Only synchronous web services exchange MUST be used. The XDS Affinity Domain Option only applies to the national environment. Therefore it MUST NOT be used for NCP-2-NCP message exchange. Stored query argument slots MUST be defined for the patient identifier and the document class code. The document format code and the document type code MAY be given. Other argument slots than the ones listed below MUST be ignored by the service provider and SHOULD NOT be issued by the service consumer. 13 The integration of ebRS and MTOM as used by eHealth DSI is not compatible with the current version of OASIS ebRS. NCPeH_Components_Specifications_v5.0.0 Page 61 of 84  Slot Name Opt Slot Value $XDSDocumentEntryPatientId R Equals to the patient identifier that was provided by the eHealth DSI Identification Service (encoded as HL7 v3 II data type) $XDSDocumentEntryStatus R Only approved documents MUST be returned: 'urn:oasis:names:tc:ebxml-regrep: StatusType:Approved' $XDSDocumentEntryClassCode R A LOINC code for the defined Original Clinical Documents must be used:  laboratory results – '11502-2'  hospital discharge reports – '34105-7'  medical imaging reports (with or without access to referenced images) – '18748-4'  medical images – 'x-clinical-image' As classification scheme 2.16.840.1.113883.6.1 MUST be used: e.g. for a laboratory result: '11502-2^^2.16.840.1.113883.6.1' $XDSDocumentEntryTypeCode O A LOINC code for the defined Original Clinical Documents must be used:  laboratory results – '11502-2'  hospital discharge reports – '34105-7'  medical imaging reports (with or without access to referenced images) – '18748-4'  medical images – 'x-clinical-image' As classification scheme 2.16.840.1.113883.6.1 MUST be used: e.g. for a laboratory result: '11502-2^^2.16.840.1.113883.6.1' $XDSDocumentEntryFormatCode O Format qualifier; see table below for details on applying these codes to the retrieval of a patient’s original clinical documents. Only encodings of the original clinical documents that comply to the requested format code will be returned by the service provider. If this stored query slot is omitted the service provider MUST deliver all available encodings14. For the document format only the format codes listed in the following table MUST be used. Document Format Format Code Document content eHealth DSI Original Clinical urn:eHDSI:orcd:pdf:2021 CDA-enveloped PDF/A encoding of Document CDA document the original document without any format semantic transformation as source coded PDF with a CDA header per IHE XDS-SD. NCPeH_Components_Specifications_v5.0.0 Page 62 of 84  eHealth DSI Original Clinical urn:eHDSI:orcd:png:2021 Original Clinical document in PDF Document PNG document format. format eHealth DSI Original Clinical urn:eHDSI:orcd:jpeg:2021 Original Clinical document in JPEG Document JPEG document format. format 3.6.1.2 Example Request Message The following excerpt from an eHealth DSI Original Clinical Document Service list() request message shows a cross-NCP query request that contains argument slots for retrieving the laboratory report original clinical documents (LOINC code 11502-2) of an identified patient (patient identifier 90378912821). In this example the service consumer does not specify the requested encoding. Therefore the service provider MUST deliver all available encodings (e.g. CDA-enveloped PDF document). <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" ... > <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:query="urn:oasis:names:tc:ebxml- regrep:xsd:query:3.0" xmlns:rim="urn:oasis:names:tc:ebxml-regrep:xsd:rim:3.0"> <soapenv:Header /> <soapenv:Body> <query:AdhocQueryRequest> <query:ResponseOption returnComposedObjects="true" returnType="LeafClassWithRepositoryItem" /> <rim:AdhocQuery id="urn:uuid:14d4debf-8f97-4251-9a74-a90016b0af0d"> <rim:Slot name="$XDSDocumentEntryPatientId"> <rim:ValueList> <rim:Value>'90378912821^^^&amp;1.3.6.1.4.1.21367.2005.3.7&amp;ISO'</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryStatus"> <rim:ValueList> <rim:Value>('urn:oasis:names:tc:ebxml-regrep:StatusType:Approved')</rim:Value> </rim:ValueList> </rim:Slot> <rim:Slot name="$XDSDocumentEntryClassCode"> <rim:ValueList> <rim:Value>(11502-2^^2.16.840.1.113883.6.1')</rim:Value> </rim:ValueList> </rim:Slot> <!-- Include associations whose sourceObject and targeObject attributes reference ExtrinsicObjects returned – </rim:AdhocQuery> </query:AdhocQueryRequest> </soapenv:Body> </soapenv:Envelope> 3.6.1.3 Expected actions The eHealth DSI Original Clinical Document Service provider shall respond to a ListRequest message with the ListResponse message containing:  the identified patient’s original clinical documents together with a status notification (full success scenario, see section 3.3.1.4) or  an error message (no patient summary provided, see section 3.3.1.5). The eHealth DSI Original Clinical Document Service provider MUST verify that the requesting service user has sufficient rights to access the original clinical document of the identified patient. In case of an error that relates to the transmission of the request or the processing of the eHealth DSI security token, the eHealth DSI Original Clinical Document Service provider MUST respond with a fault message according to section 4.4 of this document. NCPeH_Components_Specifications_v5.0.0 Page 63 of 84 3.6.1.4 Response Message (Full Success Scenario) The eHealth DSI list() response contains all available original clinical documents available for the patient that correspond with the provided classCode. The respective message builds upon the IHE XCF Cross-Gateway Fetch response and Cross-Gateway Fetch Response messages. NCPeH_Components_Specifications_v5.0.0 Page 64 of 84 The fields defined for the eHealth DSI ListResponse message MUST be used as follows: Element Name eHealth DSI Usage Convention Query:AdhocQueryResponse Response message according to IHE XCA Cross-Gateway Access response message [IHE XCF] @status For the full success scenario the response status MUST be set to "urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success" or "urn:ihe:iti:2007:ResponseStatusType:PartialSuccess" (for details see table below) rs:RegistryErrorList In case that a warning is given by the service provider, this element holds the respective warning codes and messages. It must be used according to section 4.1.13 of [IHE ITI TF-3] rim:RegistryObjectList This element MUST be provided for the full success scenario. It MUST at least contain one child <rim:ExtrinsicObject/> element. rim:ExtrinsicObject For each instance of an original clinical document a <rim:ExtrinsicObject/> element MUST be provided. Each <rim:ExtrinsicObject/> element is described and classified by metadata according to Table 4 below. rimext:Document This element MUST appear as the last element child of an <rim:ExtrinsicObject/> element. It may appear zero or one times. This element contains the base 64 encoded content of the document. The document contents are associated with the DocumentEntry (ExtrinsicObject) metadata by the fact that it is nested inside it within the XML. The base64 encoded document content MAY be encrypted. How encryption is applied and how the encryption key is negotiated should be subject to an additional specification on advanced security safeguards. Each provided original clinical document MUST be further classified by metadata. The following table lists the usage conventions that MUST be followed for the eHealth DSI Patient Service response message. If not stated otherwise the classification schemes as defined in section 4.3.1.2 of [IHE ITI TF-3] MUST be used. If no restrictions on metadata values are given, the metadata elements MUST be used as per [IHE XCF]. 3.6.1.4.1 Common metadata elements Metadata (ebRIM names) Binding Opt. eHealth DSI usage convention status Attribute R MUST be "urn:oasis:names:tc:ebxml- regrep:StatusType:Approved" mimeType Attribute R MUST be "text/xml" for all original clinical documents, since they are all embedded in a CDA document. Name Main R Must be provided and contain the name of the document. Description Main O Can contain additional information about the document VersionInfo Main R MUST be "1" NCPeH_Components_Specifications_v5.0.0 Page 65 of 84  creationTime rim:Slot O MAY be omitted by the service provider and MAY be ignored by the service consumer. If given, the value MUST be encoded as HL7 v2 Date Time "YYYY[MM[DD[hh[mm[ss]]]]]" hash rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. languageCode rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. repositoryUniqueId rim:Slot O MAY be omitted by the service provider and MAY be processed by the service consumer in an IHE-compatible NI-scenario. serviceStartTime rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service serviceEndTime consumer. size rim:Slot O SHOULD be omitted by the service provider and MUST NOT be processed by the service consumer. sourcePatientId rim:Slot R MUST contain the same value as XDSDocumentEntry.PatientId (see below). sourcePatientInfo rim:Slot X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and documents. Therefore all metadata elements that might carry medical or social information MUST be omitted. classCode Classification R  laboratory results – '11502-2'  hospital discharge reports – '34105-7'  medical imaging reports (with or without access to referenced images) – '18748-4'  medical images – 'x-clinical-image' As classification scheme "urn:oid:2.16.840.1.113883.6.1" MUST be used typeCode Classification O  laboratory results – '11502-2'  hospital discharge reports – '34105-7'  medical imaging reports (with or without access to referenced images) – '18748-4'  medical images – 'x-clinical-image' As classification scheme "urn:oid:2.16.840.1.113883.6.1" MUST be used Could be used for more fine-grained description of the type of original coded element. author Classification X MUST NOT be used. Future versions of eHealth DSI MAY define different protection levels for metadata and documents. Therefore all metadata elements that might carry medical or social information MUST be omitted. NCPeH_Components_Specifications_v5.0.0 Page 66 of 84  confidentialityCode Classification R MUST be provided for XCF compatibility but MAY be ignored by the service consumer. Value SHOULD be set to "N", as long as the Minimal Metadata Profile is not published. formatCode Classification R MUST be “urn:eHDSI:orcd:pdf:2021" for CDA- enveloped PDF document. In the case the embedded document format is PNG or JPEG, the formatCode must be “urn:eHDSI:orcd:png:2021” or “urn:eHDSI:orcd:jpeg:2021” XDSDocumentEntry.uniqueId ExternalIdentifier R MUST hold the OID of the document. The document unique id value MUST be the same as the value of the document’s <ClinicalDocument/id> CDA header element. XDSDocumentEntry.patientId ExternalIdentifier R MUST hold the patient identifier. The service consumer MUST verify that this id matches the patient Id that was discovered by the eHealth DSI Identification Service. Table 1: eHealth DSI Original Clinical Document Common Metadata 3.6.1.4.2 Metadata elements specific to laboratory results Metadata (ebRIM names) Binding Opt. eHealth DSI usage convention Author/authorSpeciality Attribute O Can be provided by the service provider. If possible the specialty text must be provided. Table 2: eHealth DSI Original Clinical Document Laboratory Results Metadata 3.6.1.4.3 Metadata elements specific to hospital discharge reports Metadata (ebRIM names) Binding Opt. eHealth DSI usage convention Author/authorSpeciality Attribute O Can be provided by the service provider. If possible the specialty text must be provided. eventCodeList Classification O ClassficationScheme: urn:uuid:2c6b8cb7-8b2a- 4051-b291-b1ae6a575ef4 COULD be used to contain the reason of hospitalisation. If possible the reason of hospitalisation COULD be added in textual form. Table 3: eHealth DSI Original Clinical Document Hospital Discharge Reports Metadata 3.6.1.4.4 Metadata elements specific to medical imaging reports and medical images Metadata (ebRIM names) Binding Opt. eHealth DSI usage convention Author/authorSpeciality Attribute O Can be provided by the service provider. If possible the specialty text must be provided. NCPeH_Components_Specifications_v5.0.0 Page 67 of 84  eventCodeList Classification O ClassficationScheme: urn:uuid:2c6b8cb7-8b2a- 4051-b291-b1ae6a575ef4 COULD be used to contain the reason of hospitalisation. If possible the reason of hospitalisation COULD be added in textual form. author Classification O ClassficationScheme: urn:uuid:93606bcf-9494- 43ec-9b4e-a7748d1a838d COULD be used to contain the requester specialty. If possible the requester specialty COULD be added in textual form. Table 4: eHealth DSI Original Clinical Document Medical Imaging Reports and Medical Images Metadata Other metadata than the ones listed above SHOULD NOT be provided by the service provider and MUST NOT be processed by the service consumer. By definition, several original clinical documents can be provided per patient. If a warning is to be transmitted to the HP (see section 3.1.4) the ebXML Registry Error mechanism MUST be used with a syntax as defined in section 3.43.5 of [IHE ITI TF-2b]. As the location of the warning is implied, the respective location attribute SHOULD be empty. 3.6.1.5 Response Message (No original clinical documents provided) If the eHealth DSI Original Clinical Document Service provider is unable to respond with documents of the requested type, in the requested encoding it MUST respond with a ListResponse message that only contains a <AdhocQueryResponse/RegistryResponse> element. For a full list of error messages defined for IHE X* see table 4.1-11 in [IHE ITI TF-3]. The following table lists the additional, eHealth DSI-specific response status types and error/warning/info codes to be used within the <RegistryErrorList> element. Condition and Severity Response Message Code Action to be taken Status The patient has not given Failure No Consent 4701 The HP SHOULD ask the patient to consent to the requested give consent to the requested service service. in country B. If the patient gives consent, the consent MUST be transmitted to country-A by using the respective operation of the eHealth DSI consent service. If such consent giving procedure is accepted by country A, HP SHOULD re-issue the request for medical data. NCPeH_Components_Specifications_v5.0.0 Page 68 of 84  Country A requests a higher Failure Weak 4702 If possible, the HP SHOULD log in authentication trust level than Authentication again with a stronger mechanisms (e.g. assigned to the HP (e.g. smartcard) and re-issue the request with password-based login is not the respective identity assertion. accepted for the requested operation). Either the security policy of Failure Insufficient 4703 If the HP can switch to another country A or a privacy policy of Rights (approriate) role, he SHOULD do so the patient (that was given in and re-issue the request. country A) does not allow the requested operation to be performed by the HP. There is no original clinical Success No Data 1101 - data of the requested type registered for the given patient (INFO) The original clinical document Failure Registry 4103 registry is not accessible Failure (ERROR) There is original clinical data of Failure Data Access 4104 The service consumer MAY re-issue the requested type registered Failure the request. for the patient but the service provider is unable to access it (ERROR) The service provider is unable Failure Unknown 4204 The service consumer MAY re-issue to evaluate the given argument Filter the request using another filter values (ERROR) expression. 3.6.1.6 Example Response Message The following message is a possible response to the sample request message given in section 3.3.1.2. The patient’s country of affiliation responds with both encodings. No MTOM optimization has been done (since this is a wire-format only optimization). 3.6.2 Security Audit Considerations The service consumer MUST write an audit trail entry according to the HP Assurance Audit Schema. The service provider MUST write an audit trail entry according to the Patient Privacy Audit Schema. The following table defines which categories MUST be filled (R), which MAY be filled (O) and which categories MUST NOT be used (X). eHealth DSI Instance Opt. Description Event R Audited event Requesting Point of Care R/X HCPO that issued the original request. This category MUST be filled by the service consumer. It MUST NOT be provided by the service provider. Human Requestor R HP that triggered the request Source Gateway R Service consumer node address at the country of Care Target Gateway R Service provider node address at the country of the patient’s affiliation Audit Source R Legal entity that ensures the uniqueness of the identifiers that are used to identify active participants Patient R Patient NCPeH_Components_Specifications_v5.0.0 Page 69 of 84  Event Target R Subject to the Query Error Message O Only used in case that the request handling was not completed successfully For the Event Target Category the following fields MUST be provided: Field Name Opt. Value Constraints ParticipantObjectTypeCode R MUST be "2" (System Object) ParticipantObjectTypeCodeRole R MUST be "24" (Query) ParticipantObjectIDTypeCode R MUST be "10" (Search Criteria) ParticipantObjectID R MUST be string-encoded UUIDs of the returned documents 3.6.3 Protocol Requirements The eHealth DSI Patient Service List() request and response messages will be transmitted using synchronous Web Services Exchange, according to the requirements specified in section 4.3 of this document. Port types and bindings MUST be used as defined in the WSDL given in section 6.4.2 of this document. Acc. to this the eHealth DSI Patient Service List() operation’s request and response data MUST be contained within the message body as follows: eHealth DSI OrCD Service Message Body List request CrossGatewayQueryRetrieve_Message (see section 6.4.2) List response CrossGatewayQueryRetrieveResponse_Message (see section 6.4.2) The request message MUST be protected by the service consumer (NCP-B) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. The response message MUST be protected by the service provider (NCP-A) according to the eHealth DSI message security considerations as defined in section 4.3.5.2 of this document. 4 eHealth DSI Communication and Messaging Infrastructure eHealth DSI service providers and consumers use the eHealth DSI messaging infrastructure to exchange request and response messages among each other. The message infrastructure builds upon the eHealth DSI communication infrastructure that connects the eHealth DSI network of trusted nodes (Figure 13). Figure 13: eHealth DSI Trusted Nodes and Messaging Infrastructure The eHealth DSI trusted node infrastructure implements the core eHealth DSI security NCPeH_Components_Specifications_v5.0.0 Page 70 of 84 services that ensure the confidentiality of medical data transmission and the availability and authenticity of eHealth DSI services:  physical private network (Testa NG),  message encryption (TLS) and integrity protection, and  mutual NCP authentication. The eHealth DSI messaging infrastructure provides mechanisms for the implementation of the derived eHealth DSI security services (e. g. non-repudiation and access control) and for the standardised enveloping of data and documents:  transmission of authenticated HP attributes,  common message format, and  signature on message elements for auditing and brokering of document authenticity claims. It must be noted that only NCPs acting as eHealth DSI service providers and consumers are part of the eHealth DSI trusted node infrastructure as specified in this document. Points of Care within country B or national data registries/repositories in country A have to be connected to the eHealth DSI trusted nodes by means that respect the eHealth DSI end-to-end privacy, security and data protection requirements. See [Section I - Security Policies] and [Security Services Specification] for details. 4.1 Audit Trail Implementation The mutual trust between a service consumer and a service provider is based on a mutually trusted, secure channel between the underlying network nodes. The establishment of mutual trust between nodes is performed by:  IPSec [RFC 4301]  Transport Layer Security v1.2 [RFC 5246]  IHE Audit Trail and Node Authentication [IHE ITI TF-2a] 4.1.1 TLS Configuration All network nodes running eHealth DSI service consumers or service providers MUST be implemenented as IHE Secure Node actors acc. to the IHE ATNA profile. The establishment of mutual trust and the setup of the secure transport layer channel between two eHealth DSI nodes are always initiated by a service consumer that connects to a service provider. The messages for the establishment of the basic transport layer secure channel correspond to the TLS handshake protocol as profiled in the IHE ATNA Integration profile (transaction ITI-19 as specified in section 3.19 of [IHE ITI TF 2a]). With respect to the ITI-19 transaction specification the following constraints and extensions apply:  Algorithms and key lengths MUST be used acc. to [Cryptographic Algorithms].  The node certificates MUST comply with the eHealth DSI Node Authentication Certificate Profile  [X.509 Certificate Profiles]  The issuing CA and all components and services for managing the lifecycle of the eHealth DSI Node Authentication Certificates must comply with the respective eHealth DSI security policies (see [Security Services Specification]). 4.2 Time Synchronisation Time synchronisation within the network of eHealth DSI gateways is performed by:  Network Time Protocol (Version3) [RFC 1305] as described in the  IHE Consistent Time Integration Profile [IHE ITI TF-2a] NCPeH_Components_Specifications_v5.0.0 Page 71 of 84 Stratum 2 time servers (Consistent Time Mediators) SHOULD by operated by NCPs. All services that rely on consistent time within the eHealth DSI Circle of Trust MUST be operated on a node that acts as a stratum 3 time server (Consistent Time Consumer). This in particular holds for  services that apply or verify digital signatures on messages, medical data or assertions,  services that contribute to the security audit trail. eHealth DSI time synchronisation for Consistent Time Consumers is handled by respective mechanisms of the underlying operating systems. The messages exchanged correspond to the NTP transactions described in detail in RFC 1305 and http://www.ntp.org. The underlying network protocol is UDP (port 123). Authentication MAY be enabled with the ntp authenticate command Consistent Time servers that represent a Stratum n+1 server SHOULD have a configuration with a default polling interval of 4096 seconds at a minimum in order to synchronize the eHealth DSI reference time to all nodes. Following time servers SHOULD only configure a polling interval of 65536 seconds. Each Consistent Time Mediator SHOULD accept a maximum clock skew of 256 seconds. With respect to lower the system resources (due to incoming requests) of the Consistent Time Source, Consistent Time Mediators SHOULD peer themselves. 4.3 eHealth DSI Common Message Format The eHealth DSI Common Message Format defines the structure and characteristics of the messages exchanged through eHealth DSI and establishes the preconditions for successful communication. The eHealth DSI Common Message Format describes only the structure of messages as they flow between service consumers and service providers. Messages within NCP's or national infrastructures may use any format desired, and need to be translated to the eHealth DSI Common Message Format before transmission to another NCP. 4.3.1 Transport Layer Profile All messages MUST be sent over HTTP 1.1 connections that are layered on top of the eHealth DSI trusted node infrastructure (see section 4.1). 4.3.2 Message Layer Profile The eHealth DSI Common Message Format is a SOAP 1.2 [W3C SOAP 1.2] message contained as the body of an HTPP 1.1 [RFC 2616] message. All messages MUST be SOAP Envelopes with an XML payload in the SOAP Body. Optional binary data MUST be carried as Base 64 encoded octets within the XML payload if not otherwise stated for the respective operations. Request messages MUST be sent using an HTTP POST, response messages are carried over the backchannel, i.e. the HTTP response. The encoding of the containing XML document MUST be set to UTF-815. All eHealth DSI SOAP messages MUST comply with the WS-I Basic Profile 1.116 [WSI BP 1.1]. All eHealth DSI SOAP messages MUST comply with the WS-I Basic Security Profile 1.1 [WSI SBP 1.1]. 15 UTF-8 is more efficient than UTF-16 for European languages. Older encodings such as ISO-8859-x do not cover all languages in a single encoding, and will only pose interoperability problems. UTF-8 is the default in XML, and coverage is a requirement of the XML specification. 16 While WSI Basic profile 1.1 does not formally support SOAP 1.2, it takes into consideration SOAP 1.2 by having requirements which are specifically for compatibility with SOAP 1.2. IHE and eHealth DSI plan to consider adoption of WS-I BP 2.0 [WSI BP 2.0] as soon as it is approved by WSI. NCPeH_Components_Specifications_v5.0.0 Page 72 of 84 4.3.3 XML Message Schema Format All eHealth DSI SOAP message MUST be described in a WSDL 1.1 [W3C WSDL 1.1] Service Description. All WSDL type definitions MUST be in XML Schema format. One Schema must be provided for the request message, and one for the response message. For better maintainability, an XML Schema import or include statement in the WSDL file SHOULD be used, so the XML Schema can be maintained and reused as a separate entity. If the XML Schema is small, and reuse is not expected, the entire Schema MAY be specified in the WSDL types section (especially in the case of RPC-style transactions where one or a few parameters of rather simple types are used). 4.3.4 SOAP Binding For all messages a SOAP 1.2 HTTP Binding MUST be provided in the WSDL. All SOAP Bindings in the WSDL MUST specify style="document". All SOAP Bindings in the WSDL MUST specify use="literal". The naming of the messages MUST be as defined for the used standard. The "soapenv:mustUnderstand="1"" attribute MUST be set as defined for the used standard. 4.3.5 Embedding of Security Token Each SOAP message MUST include a <wsse:Security> section within the SOAP header. 4.3.5.1 SAML Assertions Request messages are safeguarded by up to two SAML assertions that attest the authenticity of the user and the existence of a treatment relationship (See chapter 2 on which assertions are required for each operation). SAML assertions are contained within the <wsse:Security> section of the SOAP header. The HP Identity Assertion always takes the role of a Supporting Token. The saml:Advice element MUST be used to define the linkage between the two assertions (see [SAML Profile]). Both assertions MUST have been issued for the same subject. The relying party MUST verify the correct linkage of the SAML assertions and the match of the <Subject> elements’ contents. 4.3.5.2 Message Signature To preserve the integrity and authenticity of a message and to attest the NCP origin of the message, elements of each message MAY be signed by the protection token. If WS SecurityPolicy is used, a signed elements assertion MUST be used to refer to the message parts to be signed 17. The following table defines which token MUST be used as protection token and which elements of the message MUST be covered by the signature. Request Message Response Message Protection Token X.509 Token of NCP-B X.509 Token of NCP-A Signed Elements /Envelope/Body /Envelope/Body /Envelope/Header/Security/Assertion Signatures MUST be placed within a XML-Signature compliant <ds:Signature/> element inside the SOAP security header. The recommendations given in section 8 of [OASIS WS- Security 1.1] SHOULD be considered. In addition the following constraints apply: 17 Only in cases where the framework does not allow for multiple XPath expressions, a signed parts assertion SHOULD be used. NCPeH_Components_Specifications_v5.0.0 Page 73 of 84  Signature Parameter Usage Convention CanonicalizationMethod SHOULD be "http://www.w3.org/2001/10/xml-exc-c14n#" Transformation Exclusive XML canonicalization SHOULD be used (http://www.w3.org/2001/10/xml-exc- c14n#, acc. [W3C XMLDSig] and [W3C XML-EXC 1.0]). As inclusive namespaces other prefixes than the ones defined in section 3.1.6 of this document MUST NOT be used. SignatureMethod The signature method MUST comply with the eHealth DSI recommendations on algorithms and key lengths (see [Cryptographic Algorithms]). For signing message elements the signature method http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 SHALL be used. DigestMethod The hash algorithm MUST comply with the eHealth DSI recommendations on algorithms and key lengths (see [Cryptographic Algorithms]). For signing message elements the digest method  http://www.w3.org/2001/04/xmlenc#sha256 SHALL be used. KeyInfo This element MUST contain a wsse:SecurityTokenReference element which references the protection token. 4.3.6 Processing of SOAP Messages A sending service consumer SHOULD add SOAP Message Headers in the order in which the receiving service provider is expected to process them. A receiving service provider MUST not rely on a specific order of SOAP Message Headers for correct processing. A receiving service provider MAY rely on a specific order of SOAP Message Headers for faster processing. 4.4 Exception Handling In general eHealth DSI distinguishes between four coarse grained failure situations that MAY require an exchange of respective fault messages between NCPs: - Communication failures: The message cannot be delivered to the designated service; e.g. because the establishment of a secure communication link failed or a link is broken. - eHealth DSI Message encoding and consistency failures: The message was received but it cannot be processed; e.g. because the security token is broken or the message does not comply with the eHealth DSI message encoding and security rules - Message processing failures: The message was decoded but it cannot be processed; e.g. because of security/privacy reasons or because the request does not match with the states of the affected security and business objects - Document encoding failures: The message can be processed but the requested document cannot be completely encoded as specified in [CDA templates]. General system failures are handled basd on their implication (e.g. if a message cannot be delivered due to a buffer error, the communication failure mechansim is used to propagate the error; if the same failure occurs during message processing, the message processing failure mechanism is used). NCPeH_Components_Specifications_v5.0.0 Page 74 of 84 In the following sections it is defined, how failures of the first three kinds are handled by eHealth DSI. Failures of the fourth kind are handled within the documents (e.g. by nullifying fields or using specific error codes; see [CDA templates]). 4.4.1 Communication Failures Communication failures are raised by the existing mechanisms of the communication and messaging protocols. They are handled on the layer where they occurred. eHealth DSI does not define new error codes for these kinds of failures and eHealth DSI does not define any requirements for raising and processing these errors that are beyond the presetting of the respective standards. This includes that errors of this kind can occur at both communicating gateways and MAY require action to be taken by both gateways. In case of a communication failure an audit trail entry MUST be written at NCP-B: eHealth DSI Instance Opt. Description Event R Service that was to be called Requesting Point of Care R HCPO that issued the original request. Human Requestor R HP that triggered the request Source Gateway R Service consumer node address at the country of Care Target Gateway R Service provider node that did not respond to the request Audit Source X - Patient R Patient Event Target X - Error Message R Error data as provided by the layer that detected the communication failure 4.4.2 Encoding and Consistency Failures Encoding and consistency problems are detected at the protocol terminator or other eHealth DSI-side internal components at the service providing NCP. Errors that origin in an improper encoding of the message (envelope, header) or in an inaccurate use of security objects are covered by the SOAP error mechanism. 4.4.2.1 SOAP Error Profile Information on faults that occurred during the processing of a request are placed into a SOAP response message body as SOAP 1.2 faults. The respective data type MUST be instantiated as defined in [W3C SOAP 1.2]. eHealth DSI specific error information is encoded with the following elements: Element name Format Opt. Content Code/Subcode/Value QName R eHealth DSI error code; see tables below for the defined values Reason/Text QName R Description of the error (by default the error code is used as the error description; nevertheless a NCP implementation MAY provide the error condition (see tables below) or even more detailed information on the reason of the failure in this element) NCPeH_Components_Specifications_v5.0.0 Page 75 of 84  Node URI O URI of the system component that caused the failure or (URI encoded) OID of the object that caused the error. The semantics of this entry MUST be determinable by the error code. By default this element holds the URI of the Service Provider where the error was detected. Table 11: Usage conventions for SOAP faults Further details on the error MAY be given in a <detail/> element. The receiver of the fault message MUST NOT process the <detail/> element but SHOULD dump its contents into the respective field of the audit trail entry. 4.4.2.2 General Message Handling Errors General message handling faults are detected upon receipt of a message. Usually they are not specific for a certain transaction and usually origin in weaknesses related to the implementation, configuration and operation of the eHealth DSI NCP. The following table lists all general message handling errors. These errors MUST be handled acc. to the eHealth DSI SOAP error profile (see section 4.4.2.1). Condition Code Subcode Action to be taken The service provider is not able to Receiver Busy Both NCPs MUST write an audit fulfil the request due to an internal trail entry. The service requestor problem. SHOULD send the request again. The service provider cannot write an Receiver Audit Log The service consumer MUST audit trail entry. Failure write an audit trail entry. The service provider MUST write a log entry to the systems log. The system administrator MUST process this failure because it indicates a mis-configuration or software error. 4.4.2.3 SOAP Message Encoding and Addressing Errors Message encoding and addressing faults are detected upon receipt of a message or at the protocol terminator. Usually they are not specific for a certain transaction and usually origin in weaknesses related to the implementation, configuration and operation of the eHealth DSI NCP. The following table lists all message encoding and addressing errors. These errors MUST be handled acc. to the eHealth DSI SOAP error profile (see section 4.4.2.1). Condition Code Subcode Action to be taken The protocol terminator cannot decode MustUnderstand or Decoding No audit trails are written. The the message because of a schema DataEncodingUnknow Failure service consumer MUST write a violation in the SOAP envelope n (depending on the log entry to the systems log. The source of the error) system administrator MUST process this failure because it indicates a mis-configuration or software error. NCPeH_Components_Specifications_v5.0.0 Page 76 of 84  The protocol terminator cannot DataEncodingUnknown Unknown No audit trails are written. The validate a message because of an Schema service consumer MUST write a unknown namespace or schema log entry to the systems log. The system administrator MUST process this failure because it indicates a mis-configuration or software error. The protocol terminator cannot process MustUnderstand or Unknown No audit trails are written. The the message because it does not know DataEncodingUnknow Transactio service consumer MUST write a or not support the requested service. n (depending on the n log entry to the systems log. The source of the error) system administrator MUST process this failure because it indicates a mis-configuration or software error. The protocol terminator rejects the MustUnderstand or Version No audit trails are written. The message because of a ver- sion DataEncodingUnknow Mismatch service consumer MUST write a mismatch (e. g. service consumer uses n (depending on the log entry to the systems log. The deprecated ver- sion of the spec) source of the error) system administrator MUST process this failure because it indicates a mis-configuration or software error. 4.4.2.4 Security Header Encoding and Consistency Errors Security header encoding and consistency errors are detected by the security manager component. Usually they are not specific for a certain transaction and usually origin in weaknesses related to the implementation, configuration and operation of the eHealth DSI NCP. The following table lists all security header related errors. These errors MUST be handled acc. to the eHealth DSI SOAP error profile (see section 4.4.2.1). Condition Code Subcode Action to be taken The provided HP Identity Assertion Sender HP Missing Both service consumer and does not contain all of the required Attributes service provider MUST write an attributes. audit trail entry. The service consumer SHOULD request a new authentication of the HP. The provided HP Identity Assertion Sender Invalid Both service consumer and is not valid or timed out. Security service provider MUST write an Token audit trail entry. The service consumer SHOULD request a new HP authentication. The patient identifier is not valid. Sender Unknown Both service consumer and Patient service provider MUST write an audit trail entry. The HP at the country of care SHOULD identify the patient again, establish a new security context and retry the request. NCPeH_Components_Specifications_v5.0.0 Page 77 of 84  An attesting (message) signature Sender or Receiver Invalid Both service consumer and cannot be verified. (depending on the NCP service provider MUST write an source of the failure) Signature audit trail entry. The service provider MUST write a log entry to the systems log. The system administrator MUST process this failure because it indicates a mis- configuration or software error. The use of SHA-1 as a digesting Sender or Receiver Weak Both service consumer and method is not allowed. (depending on the Digest service provider MUST write an source of the failure) audit trail entry. The service provider MUST write a log entry to the systems log. The service consumer SHOULD re-issue the request using SHA-2 for digesting (message signature and assertion signatures). The service provider SHOULD use the same digesting method for message signatures as the service consumer. The requestor provided a Confirmation Sender Weak Both service consumer and Assertion which is not accepted by Authorisa service provider MUST write an the service provider. tion audit trail entry. The HP SHOULD trigger the issuance of a new TRC assertion by NCP-B and re-issue the request. 4.4.2.5 Audit Trail Considerations In case of a general message handling error, NCP-B MUST write a full audit trail including an error section as defined in chapter 4.4.3. NCP-A MUST fill all audit trail information that could be decoded from the request message. If the requested operation cannot be decoded the Event Identification section of the HP Assurance Audit Schema MUST be used as follows: Field Name Value Constraints EventID MUST be set to EV( EHDSI-00, "unknown", unknown ) EventActionCode MUST be set to E (execute). EventDateTime Time of the occurrence of the failure EventOutcomeIndicator Acc. RFC 3881. MUST be "4" for temporal or recoverable failures and "8" for permanent failures. If the HP identity cannot be decoded from the HP Identity Assertion, the Human Requestor section of the HP Assurance Audit Schema MUST be used as follows: Field Name Value Constraints UserID Subject and issuer MUST be set to "unknown". UserName MUST be set to "unknown" UserIsRequestor "true" RoleIDCode MUST be omitted. NCPeH_Components_Specifications_v5.0.0 Page 78 of 84 If the patient identity cannot be decoded from the request, the Patient section of the HP Assurance Audit Schema MUST be used as follows: Field Name Value Constraints ParticipantObjectTypeCode MUST be "1" (Person) ParticipantObjectTypeCodeRole MUST be "1" (Patient) ParticipantObjectIDTypeCode EV( 2, RFC-3881, "Patient Number" ) ParticipantObjectID MUST be "unknown" 5 eHealth DSI Profiles on Assertions and Certificates eHealth DSI security mechanisms build upon SAML assertions and digital certificates as core security objects. This chapter provides the respective eHealth DSI security object profiles on SAML and X.509. 5.1 Cryptographic keys and Algorithms All cryptographic keys and algorithms used for eHealth DSI and its implementations MUST fulfil at least the requirements of [ECRYPT-II D.SPA.20] for Level-5 (Legacy Standard) security. This corresponds to 96-bit security (symmetric equivalent). For more information on cryptographic keys and algorithms, please check [Cryptographic Algorithms]. 5.2 HP Identity Assertion The HP Identity Assertion is a profiled SAML v2.0 assertion. It has Sender-Vouches configured as the confirmation method. For more information on HP Identity Assertion, please check [SAML Profile]. 5.3 Treatment Relationship Confirmation Assertion The Confirmation Assertion is a profiled SAML v2.0 assertion. It attests the existence of a treatment relationship between a patient and a HCPO and provides information about the context of a certain treatment scenario. For more information on Confirmation Assertion, please check [SAML Profile]. 5.4 eHealth DSI Certificate Profiles The following sections define how to set up eHealth DSI compliant X.509 certificates. All certificates issued by a CA that are used for eHealth DSI are compliant X.509 certificates. For more information on X.509 certificates, please check [X.509 Certificate Profiles]. 6 Appendix 6.1 Coding Conventions (Normative) 6.1.1 Country Codes Fields carrying country code values MUST be coded in accordance with [ISO 3166- 1] Alpha 2 codes. NCPeH_Components_Specifications_v5.0.0 Page 79 of 84  Country Code (normative) BE BG CZ DK DE EE IE GR ES FR HR IT CY LV LT LU HU MT NL AT PL PT RO SL SK FI SE The following exceptions apply: - For Greece the country codes "GR" and "EL" are allowed. 6.2 eHealth DSI Identifiers (Normative) 6.2.1 Uniform Resource Names (URNs) The following URNs are defined: NCPeH_Components_Specifications_v5.0.0 Page 80 of 84  URN Description urn:epsos:names:wp3.4:subject:healthcare-facility-type Signals that a SAML attribute refers to the kind of the healthcare facility assigned to the subject. See [SAML Profile] for details. urn:epsos:names:wp3.4:subject:clinical-speciality Signals that a SAML attribute refers to the kind of the clinical speciality of the subject. See [SAML Profile] for details. urn:epsos:names:wp3.4:subject:on-behalf-of Signals that a SAML attribute refers to the person who authorized the subject's access to eHealth DSI services. See [SAML Profile] for details. 6.2.2 eHealth DSI OIDS The following OIDs are defined: OID Type Values / Description 1.3.6.1.4.1.12559.11.10.1.3.2.2.1 Code list {"AdditionalDemographicsRequested", "DemographicsQueryNotAllowed", "EHICDataRequested", "InsufficientRights", "PrivacyViolation", AnswerNotAvailable", PolicyViolation", "PatientAuthenticationRequired" } 1.3.6.1.4.1.12559.11.10.1.3.2.2.2 Code list {"Hospital", "Resident Physician", "Pharmacy", "Other" } 1.3.6.1.4.1.12559.11.10.1.3.2.3.1 Code list { "eHDSI pivot" } 1.3.6.1.4.1.12559.11.10.1.3.2.4.1 Coded values 1: Opt-In Policy 2: Opt-Out Policy 6.2.3 eHealth DSI CDA Documents and Codes eHealth DSI Consumer Display Name Coding Scheme Node Representation Document Patient Summary Patient Summary 2.16.840.1.113883.6.1 60591-5 eDispensation eDispensation 2.16.840.1.113883.6.1 60593-1 ePrescription ePrescription 2.16.840.1.113883.6.1 57833-6 eDispensation Discard eDispensation Discard 2.16.840.1.113883.6.1 DISCARD-60593-1 6.3 WSDLs This section lists the WSDLs for the eHealth DSI messages. The schemas for the messages and contained data types are available at the [eHDSI Technical Guidelines]. 7 References 7.1 Normative References [BSI TR-3116] Bundesamt für Sicherheit in der Informationstechnik: BSI - Technische Richtlinie 03116 für die eCard-Projekte der Bundesregierung. Version 3.0. April 2009. NCPeH_Components_Specifications_v5.0.0 Page 81 of 84 [DICOM Sup95] Digital Imaging and Communications in Medicine (DI- COM): Supple- ment 95 – Audit Trail Messages. 18. June 2004. [ECRYPT-II D.SPA.20] Ecrypt-II NoE: ECRYPT2 Yearly Report on Algorithms and Keysizes. September 2012. http://www.ecrypt.eu.org/documents/D.SPA.20.pdf [ETSI TS 102 231] ETSI Technical Committee Electronic Signatures and Infrastructures (ESI), ETSI TS 102 231 Version 3.1.2 - Electronic Signatures and Infrastructures (ESI): Provision of harmonized Trust-service status Information, ETSI, 2009. [FNISA CryptMech] Secrétariat général de la défense nationale: Mécanismes cryptogra- phiques - Règles et recommandations concernant le choix et le di- mensionnement des mécanismes cryptographiques de niveau de ro- bustesse standard. Version 1.1. December 2006. [HITSP C80 2.0] Healthcare Information Technology Standard Panel : HITSP C80 - Clinical Document and Message Terminology Component v2.0. Ja- nuary 2010. http://www.hitsp.org/Handlers/HitspFileServer.aspx?File Guid=886331bd-2eba-4ded-a1ed-24b35ecebb6 [IHE ITI TF-1] IHE International: IHE IT Infrastructure (ITI) Technical Framework. Volume 1: Integration Profiles. August 2009 https://www.ihe.net/Technical_Framework/upload/IHE_IT I_TF_Rev9-0_Vol1_FT_2012-08-31.pdf [IHE ITI TF-2a] IHE International: IHE IT Infrastructure (ITI) Technical Framework. Volume 2a: Transactions. August 2009 https://www.ihe.net/Technical_Framework/upload/IHE_IT I_TF_Rev9-0_Vol2a_FT_2012-08-31.pdf [IHE ITI TF-2b] IHE International: IHE IT Infrastructure (ITI) Technical Framework. Volume 2b: Transactions. August 2009 https://www.ihe.net/Technical_Framework/upload/IHE_IT I_TF_Rev9-0_Vol2b_FT_2012-08-31.pdf [IHE ITI TF-3] IHE International: IHE IT Infrastructure (ITI) Technical Framework. Volume 3 – Document Content Profiles. October 2008 https://www.ihe.net/Technical_Framework/upload/IHE_IT I_TF_Rev9-0_Vol3_FT_2012-08-31.pdf [IHE PIX/PDQ v3] IHE International: Patient Identifier Cross-Reference (PIX) and Pa- tient Demographic Query (PDQ) HL7 v3. August 2009 NCPeH_Components_Specifications_v5.0.0 Page 82 of 84 [IHE XCPD] IHE International: Cross-Community Patient Discovery (XCPD). Au- gust 2009. [IHE XCF] IHE International: Cross-Community Fetch (XCF). August 2011 [IHE XUA++] IHE International: Cross-Enterprise User Assertion – Attribute Exten- sion. Revision 1.0. August 2010. [ISO OID] ISO/IEC 9834-1:2005: Procedures for the operation of OSI Registra- tion Authorities: General procedures and top arcs of the ASN.1 Ob- ject Identifier tree. [NIST SP800.57/1] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid (Eds.): NIST Special Publication 800-57: Recommendation for Key Management – Part 1: General. March 2007. [OASIS SAML 2.0] S. Cantor, J. Kemp, R. Philpott, and E. Maler, Assertions and Proto- cols for the OASIS Security Assertion Markup Language (SAML) V2.0, 2005. [OASIS WS-Security 1.1] OASIS Security TC: Web Services Security - SOAP Message Secu- rity 1.1 (WS-Security 2004). OASIS Standard Specification, February 2006. [RFC 1305] D. Mills: Network Time Protocol (Version 3) Specification, Implemen- tation and Analysis. March 1992. [RFC 2119] Bradner, S.: Key words for use in RFCs to Indicate Requirement Levels; Harvard University, Boston, Massachusetts, 1997. [RFC 2246] T. Dierks, C. Allen: The TLS Protocol. Version 1.0. January 1999. [RFC 2616] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee: Hypertext Transfer Protocol - HTTP/1.1. June 1999. [RFC 3881] Marshall, G.: Security Audit and Access Accountability Message XML Data Definitions for Healthcare Applications. Version 1.0. September 2004. [RFC 5246] T. Dierks, E. Rescorla: The Transport Layer Security (TLS) Protocol. Version 1.2. August 2008 [W3C SOAP 1.2] M. Gudgin et al: SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). W3C Recommendation. April 2007. http://www.w3.org/TR/soap12-part1/ NCPeH_Components_Specifications_v5.0.0 Page 83 of 84 [W3C WSDL 1.1] E. Christensen, F. Curbera, G. Meredith, S Weerawarana: Web Ser- vices Description Language (WSDL). Version 1.1. March 2001 [WSI BP 1.1] Web Services Interoperability Organization: WS-I Basic Profile. Ver- sion 1.1. August 2004. [WSI BP 2.0] Web Services Interoperability Organization: WS-I Basic Profile. Ver- sion 2.0. Working Group Draft. October 2007. [WSI SBP 1.1] Web Services Interoperability Organization: WS-I Basic Security Pro- file. Version 1.1. January 2010. [WS SecurityPolicy] A. Nadalin, et al.: WS-Trust. Version 1.3. March 2007. http://docs.oasis-open.org/ws-sx/ws-trust/200512/ws-trust- 1.3-os.pdf [XML-EXC 1.0] J. Boyer et al: Exclusive XML Canonicalization. Version 1.0. W3C Recommendation, July 2002. https://www.w3.org/TR/2002/REC-xml-exc-c14n- 0020718/ [W3C XMLDSig] F. Hirsch, P. Datta: XML Signature Best Practices. W3C Working Draft. Februray 2010. https://www.w3.org/TR/xmldsig-bestpractices/ NCPeH_Components_Specifications_v5.0.0 Page 84 of 84  PATIENT SUMMARY SERVICE Introduction A portal for cross-border Patient Summary (PS) exchange needs to be created. The portal is for national use and only in Estonian. The portal will be used only by doctors and the main workflow will be to identify a foreign person and view his / her Patient Summary. The primary purpose of electronic patient summary id to provide the healthcare professional (HP) with a data set of key health information at the point of care to deliver safe patient care during unscheduled care. The content of the PS is not the entire medical record, but the essential patient information to provide treatment. The portal is only used in desktop version. Main page without logging in The portal is only for logged in users. Therefore, only the login option is available on the front page of the portal. The doctor logs in Login is via Keycloak. In other words, the portal directs the user to Keycloak and this forwards to TARA, where authentication takes place. Keycloak and TARA are separate applications. After authentication, the user is authorized. This is done against the records of the Health Board. These are backend queries. In the design view, the user has a login button. The button directs it to other applications. When the user returns to the PS portal, the user is already authenticated and authorized. The portal displays possible countries If the user (doctor) is logged in, he/she will be taken to the front page of the logged in view. The user can:  See that he is logged in  Possibility to log out  Select the country whose patient is to be identified. By logging in, the portal offers possible countries whose patients can be identified. In the first stage, in addition to Estonia, the following countries will participate: Czech Republic, Portugal, Malta, Croatia, Luxembourg. It must be taken into account that all European countries can participate and the list of countries is inconclusive and increasing over time. The doctor identifies the patient Once the country is selected, the portal offers a different number of patient identification fields according to the selected country. For example, a Finnish patient can only be identified by personal identification code. For Austria, the patient is needed to identify the patient's ID, name, first name and date of birth. Fields can be mandatory or optional. Fields can have a required length (minimum and maximum length) or a required format. Examples: When starting the search, it is possible to mark the symbol "hädaolukord". This feature is indicated when the person is incapable of contact and failure to provide assistance endangers the person's life. If the patient is conscious, the purpose of use is “ravi”. When searching for a patient, usually only one patient comes up (but for some countries, depending on the search criteria, several patients may come up). Patients may not be found. An appropriate information will be given then. The doctor opens the Patient Summary If the patient is found, the user selects a specific patient and moves to the view of the patients “patient summary” (patient summary query is launched when the user clicks “vali”. The answer is a PS or an error message). The PS document display is already designed and cannot be changed/designed. The existing design opens in a portal window. When displaying the PS, it must be possible to see who is the subject and when the PS was created. It must also be possible to print the PS and open the original document. The original document is always in the patient's home language and in PDF format. The PS request may also give an error message or a warning message. In this case, the error code and descriptions are displayed. Possible error messages are: Condition and Severity Response Message Code Status The patient has not given consent to the requested Failure No Consent 4701 service. (ERROR) Country A requests a higher authentication trust Failure Weak 4702 level than assigned to the HP ( eg password-based Authentication login is not accepted for the requested operation). (ERROR) Either the security policy of the country A or a Failure Insufficient 4703 privacy policy of the patient (that was given in Rights country A) does not allow the requested operation to be performed by the HP (ERROR). No patient summary is registered for the given Success No Data 1102 patient. (WARNING) If PDF-coded patient summary is requested: Success Unsupported 4201 Country A does not provide the (optional) source Feature coded version of the patient summary (INFO)  The query argument slots used by the service Failure Unknown 4202 consumer are not supported by the service Signifier provider. (ERROR) The requested encoding cannot be provided due Failure Transcoding 4203 to a transcoding error. (ERROR) Error The service provider is un- able to evaluate the Failure Unknown Filter 4204 given argument values (ERROR). Other Test subjects  49406240016 Kati Piiriülene (27.a)  38507220018 Toomas Piiriülene (36.a)  49203030010 Mari Piiriülene-Läbu (29.a)  Hea koostööpartner! Tervise- ja Heaolu Infosüsteemide Keskus teeb Teile käesolevaga ettepaneku esitada pakkumus väikeostul „Turvatestimise ja testiraportite kontrollimine“. 1. Üldised nõuded 1.1. Hangitava töö sisu ja töö teostamise tingimused on kirjeldatud käesolevas pakkumuskutses ja lisades Tehniline kirjeldus (lisa 1), nõuded pakkuja meeskonnale (lisa 2) ning hankelepingu projektis (lisa 3). 1.2. Pakkumuse esitamisega kinnitab pakkuja, et nõustub üle võtma kõik hanke alusdokumentides kirjeldatud tingimused ja teostama hangitava töö hankija poolt kirjeldatud tingimustel. Alternatiivsete pakkumuste esitamine ei ole lubatav. 1.3. Pakkumuse esitamisega kinnitab pakkuja, et tal on kõik hankelepingu täitmiseks vajalikud intellektuaalse omandi õigused. 1.4. Esitatud pakkumus peab olema jõus minimaalselt 90 kalendripäeva. 1.5. Pakkumuse esitamisega kinnitab pakkuja, et tema osas puuduvad RHS § 95 lg 1 sätestatud kõrvaldamise alused. Kui hankijale saavad sellised kõrvaldamise alused teatavaks, on hankijal õigus lükata pakkumus tagasi ja mitte sõlmida sellise pakkujaga hankelepingut. 1.6. Vajadusel märgib pakkuja pakkumuse esitamisel, milline osa tema pakkumuses on ärisaladus. Kui pakkuja ei ole ärisaladust määranud, eeldab hankija, et pakkumuses ärisaladust ei sisaldu. 2. Vastavustingimused 2.1. Pakkumus tunnistatakse vastavaks, kui see on kooskõlas kõikide hankedokumentides esitatud tingimustega. Hankija võib vastavaks tunnistada pakkumuse, milles ei esine hankija jaoks olulisi sisulisi kõrvalekaldumisi hankedokumentides esitatud tingimustest. 2.2. Pakkumuse osana tuleb esitada: 2.2.1. Täidetud maksumusvorm (vt p 5); 2.2.2. Meeskonna andmed etteantud CV vormidel (vt lisa 2); 2.2.3. Lepingusse lisatavate kontaktide nimistu ja allkirjastaja informatsioon; 3. Pakkumuste hindamine 3.1. Hankija hindab kõiki vastavaks tunnistatud pakkumusi. 3.2. Edukaks tunnistatakse ja hankeleping sõlmitakse ühe madalaima kogumaksumusega pakkumuse esitajaga (vt p 5 maksumusvorm). 3.3. Võrdsete pakkumuste puhul eelistatakse pakkumust, mis on hankijale ajaliselt varem saabunud. 4. Töid teostava meeskonna andmed 4.1. Meeskonnale seatud tingimused on kirjeldatud lisatud dokumendis „Nõuded pakkuja meeskonnale“ (lisa 2). 4.2. Pakkuja esitab töid teostava meeskonna andmed etteantud CV vormidel ja andmekoosseisus, juhindudes lisas 2 toodud tingimustest. 4.3. Kui meeskonnale seatud tingimused ei ole täidetud või hankija ei suuda esitatud andmete alusel tingimustele vastamist üheselt tuvastada, on hankijal õigus tunnistada pakkumus mittevastavaks. 5. Maksumusvorm  Kogumaksumus sisaldab kõiki töid vastavalt tehnilises kirjelduses ja hankelepingu projektis sätestatule ning on hankijale lõplik. Kogumaksumus käibemaksuta Kogumaksumus koos käibemaksuga 6. Pakkumuste tagasi lükkamise tingimused ja menetluse kehtetuks tunnistamine 6.1. Hankija lükkab tagasi ja jätab hindamata pakkumuse(d): 6.1.1. mis ei vasta hankedokumentides esitatud ühele või mitmele tingimusele või pakkumusest või selgitustest ei ole võimalik üheselt tuvastada pakkumuse vastavust või pakkuja on esitanud tõele mittevastavaid andmeid; 6.1.2. mis ei ole esitatud tähtaegselt. 6.2. Hankija võib väikeostu menetluse kehtetuks tunnistada, kui: 6.2.1. hankemenetluse toimumise ajal on hankijale saanud teatavaks uued asjaolud, mis välistavad või muudavad hankemenetluse lõpule viimise hankedokumentides esitatud tingimustel ebaotstarbekaks; 6.2.2. pakkumuse(d) ületavad hankija rahalisi vahendeid hankelepingu täitmiseks; 6.2.3. kui selleks on muu põhjendatud vajadus. 7. Pakkumuse esitamine 7.1. Pakkumuse esitamise tähtaeg: 23.08.2021 kell 12:00. 7.2. Pakkumuse palume esitada eesti keeles e-posti aadressile [email protected]. 7.3. Hanke alusdokumentide, hankelepingu projekti ja nendega seonduva lisainfo saamiseks palume pöörduda enne pakkumuste esitamise tähtaega Tervise ja Heaolu Infosüsteemide Keskuse poole aadressil [email protected]. LISAD käesoleva pakkumusettepaneku juurde: 1. Tehniline kirjeldus koos lisadega 2. Nõuded pakkuja meeskonnale 3. Hankelepingu projekt  Tehniline kirjeldus Turvatestimine ja testiraportite kontrollimine 1 Lepingu ese .......................................................................................................................... 2 1.1 Testitava süsteemi kirjeldus .......................................................................................... 2 1.1.1 Teenuse eesmärk ja olemus ...................................................................................... 2 1.1.2 Teenuse kasutajad................................................................................................. 2 1.1.3 Arhitektuur................................................................................................................. 3 1.1.4 Funktsionaalsus ..................................................................................................... 4 1.1.5 Integratsioon ............................................................................................................. 4 1.1.6 Testimise skoop..................................................................................................... 4 1.1.7 Lisa dokumendid ................................................................................................... 4 2 Mõisted .................................................................................................................................5 3 Tähtajad ................................................................................................................................5 4 Töö teostamise nõuded .........................................................................................................5 4.1 Turvatestimine ...............................................................................................................5 4.2 Testiraportite kontrollimine ...........................................................................................5 4.3 Testiraporti koostamine ................................................................................................ 6 4.4 Aruande koostamine ..................................................................................................... 6 5 Tööde dokumenteerimine .................................................................................................... 6 1 1 Lepingu ese Lepingu esemeks on infosüsteemide käsitsi turvatestimine OWASP (Open Web Application Security Project) ASVS (Application Security Verification Standard Project) versiooni 4.0 või kõrgem tase 2 ja tellija teiste lepingupartnerite poolt teostatud testiraportite kvaliteedi kontrollimine ning nende osas kirjaliku testiraporti ja aruande koostamine. 1.1 Testitava süsteemi kirjeldus 2017. aastal alustasid Euroopa riigid (sh Eesti) projektiga, mille eesmärgiks on realiseerida Euroopas jätkusuutlik piiriülene terviseandmete vahetus. Eesmärk on realiseerida andmevahetus kahe teenusena: 1) Digiretseptide ja väljamüügi andmete edastamine, mis võimaldab patsiendil välja osta talle välja kirjutatud ravimid teises, teenusega kaetud riigi apteegis ning edastada väljamüügi info patsiendi koduriigi retseptikeskusesse. Apteekrile võimaldatakse teenusega retsept tõlgituna selle riigi keelde. 2) Patsiendi terviseandmete kokkuvõtete edastamine, mis võimaldab edastada patsiendi olulisemate meditsiiniliste andmete kokkuvõtte teise riigi tervishoiutöötajatele ning kuvada need andmed tervishoiutöötajatele kohalikku keelde tõlgituna, tagades seeläbi kvaliteetsem ja efektiivsem ravi (eriti erakorralises olukorras). Andmevahetus toimub Euroopa Komisjoni hallataval andmevahetusplatvormil OpenNCP (sh ka Eesti-Soome vaheliseks terviseandmete vahetamiseks kasutatakse seda platvormi mitte X-teed). 1.1.1 Teenuse eesmärk ja olemus 1.1.1.1 Andmevahetusteenuse eesmärk on võimaldada riik-B tervishoiutöötajal saada juhuvisiidi ajal tervishoiuteenust otsiva patsiendilt riigilt (riik-A) patsiendi terviseandmetest kokkuvõte. 1.1.1.2 Patsiendi terviseandmete kokkuvõtte sisu ei kata tervet patsiendi haiguslugu, vaid olulisemat teavet (kiir)abi osutamiseks (andmekoosseisud on kirjeldatud siin: https://www.riigiteataja.ee/akt/120112018003?leiaKehtiv). 1.1.1.3 Patsient esitab välisriigi terviseasutusse tulles oma pildiga dokumendi, millel on tema unikaalne isikukood või mingite täiendavate tunnuste kogum (nt. sünnikuupäev + kood). Tegevuseks volitatud tervishoiutöötaja informeerib patsiendi tema isikuandmete töötlemisest ning patsiendi nõusolekul sisestab need vajalikud andmed patsiendi kohta (mis on riigi-A poolt eelnevalt kindlaks määratud) ning saadab päringu riiki-A. Riik-A kontrollib päringut vastu võttes, kas selliste tunnustega patsient eksisteerib ning kas tal on olemas kehtiv nõusolek andmevahetuseks ning edastab vastuseks patsiendi üldandmed. Nende alusel on tervishoiuteenuse osutajal võimalik veenduda, et patsiendi dokumendi ja päringu vastuseks saadud andmed vastavad teineteisele. 1.1.1.4 Järgmise sammuna on tervishoiutöötajal võimalik pärida riigist-A patsiendi saadaolevate terviseandmete kokkuvõtet. Riik-A koostab vastavalt eHDSI nõuetele kokkuvõtte, mis edastatakse riiki-B ja kuvatakse omakorda tervishoiutöötajale. 1.1.2 Teenuse kasutajad 1.1.2.1 Teenuse lõppkasutajad on vastavalt https://www.riigiteataja.ee/akt/128122019014?leiaKehtiv kõik, kellel on tervise 2  infosüsteemi (TIS) andmetele juurdepääs võimaldatud (päringu tegemisel TIS kontrollib, kas nad on registreeritud kui tervishoiutöötajad TAM registris https://mveeb.sm.ee/Tervishoiutootajad/): 1.1.2.1.1 arst-resident eriarstiabi, üldarstiabi ja kiirabi osutamisel töötava eriarsti juhendamisel ja vastutusel, kellel on vähemalt viieaastane töökogemus juhendatava läbitavale praktilisele koolitusele vastavalt erialal; 1.1.2.1.2 arstiõppe üliõpilane, kes on läbinud õppekavas olevad 4 kursuse kohustuslikud ained, arsti juhendamisel ja vastutusel; 1.1.2.1.3 arst, hambaarst, õe ja ämmaemanda tööpraktikal viibija, kes on omandanud kvalifikatsiooni väljaspool Euroopa Majanduspiirkonna liikmesriiki või Šveitsi, arsti, hambaarsti, õe või ämmaemanda juhendamisel ja vastutusel. 1.1.2.2 Tervishoiuteenusel osalejateks vastavalt kutse- või erialade pädevusele võivad spetsialisti või tehnikuna tervishoiuteenuse osutamisel osaleda järgmised isikud: 1.1.2.2.1 füsioterapeut; 1.1.2.2.2 tegevusterapeut; 1.1.2.2.3 kliiniline psühholoog; 1.1.2.2.4 radioloogiatehnik; 1.1.2.2.5 kliiniline logopeed; 1.1.2.2.6 optometrist. 1.1.3 Arhitektuur 1.1.3.1 Osapooled Eestis: 1.1.3.1.1 Tervise ja Heaolu Infosüsteemide Keskus (kogu teenuse toimimine, TARA); 1.1.3.1.2 Sotsiaalministeerium (sh piiriülese juhtrühm); 1.1.3.1.3 Ravimiamet (ravimiregister, ravimikäitlejate register) – võimaldab kasutada teenuses riigis müügiloaga ravimite registrit; 1.1.3.1.4 Terviseamet (tervishoiutöötajad) – võimaldab autentida piiriülest andmevahetusteenust kasutada soovivat arsti või õde vastavalt tema koodile; 1.1.3.1.5 Riigi Infosüsteemi Amet – teenuses kasutatakse olemasolevat X-tee andmevahetuskihti, samuti pakub RIA kogu võrguteenust st laivõrgu ja TESTA võrgu teenust; 1.1.3.1.6 Haigekassa – Eestis vastutav retseptikeskuse arenduse ja halduse eest, võimaldab Eesti digiretseptide andmete edastamise teise riiki; 1.1.3.1.7 SK ID Solutions AS – sertifitseerimisteenus. 3 Joonis 1. Arhitektuur 1.1.4 Funktsionaalsus 1.1.4.1 Veebirakenduse PIPA skoop on pärida patsienti (kellel on antud nõusolek piiriüleseks andmevahetuseks) ja vaadata leitud patsiendi terviseandmete kokkuvõtte dokumenti (Eesti kui riik B). 1.1.4.2 Lisaks saab kontrollida seda, et patsient on lubanud piiriülese andmevahetust. 1.1.4.3 Veebirakendus PIPA sisaldavad funktsioonid on kirjeldatud dokumendis PS portal scope en.docx. 1.1.5 Integratsioon 1.1.5.1 Tervishoiuasutus (TTO) autentimine ja autoriseerimine (SK Solustions) ja Terviseameti registritest tegevuslubade ja tervishoiutöötajate kontroll. 1.1.5.2 Lisaks patsiendi nõusoleku kontroll (dokument UC143 Tahteavalduse koostamine seoses terviseandmete juurdepääsu muutmisega.doc). 1.1.6 Testimise skoop 1.1.6.1 Testimisel on veebirakenduse PIPA funktsionaalsus (vt. 1.1.4) ja integratsioon (vt. 1.1.5). 1.1.6.2 Testandmed on loodud Eesti patsientidele (info on dokumendis PS portal scope en.docx). 1.1.6.3 Dokumentatsioonile ja kasutusjuhtudele antakse ligipääs (viimased kasutuslood on arendajal pooleli ja saadab need meile peale puhkust augusti alguses). 1.1.6.4 Testkeskkonna rakenduse PIPA logidele võimaldatakse ligipääs. 1.1.7 Lisa dokumendid 1.1.7.1 eHDSI Requirements Catalogue – ainult Patsient Summary (lühend PS) - https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/1.+eHDSI+Requirements+C atalogue . 4  1.1.7.2 System Architecture Specification – ainult Patsient Summary (lühend PS) – System Architecture Specification_V2.1.0.pdf. 1.1.7.3 NCPeH Components Specification – eHDSI_NCPeH_Components_Specifications_V5.0.0.RC_TC.docx. 1.1.7.4 PIPA UI disaini prototüüp – PIPA UI disaini prototüüb.zip. 2 Mõisted 2.1 Testiraport – sisaldab turvatestimise tulemust ja koostamise nõuded vt. 5.1. 2.2 Aruanne – sisaldab tellija lepingupartnerite testiraportite kvaliteedi kontrolli ülevaatust ja koostamise nõuded vt. 5.2. 3 Tähtajad 3.1 Turvatestimisega alustab täitja lepingu jõustumisel. Testiraport tuleb tellijale esitada lepingu sõlmimisest alates 3 nädala jooksul. 3.2 Testraportid kontrollimiseks edastab tellija täitjale pärast täitja testraporti kättesaamist. Testraportite kontrollimise aruanne tuleb tellijale esitada testraportite saatmisest alates 2 nädala jooksul. 4 Töö teostamise nõuded 4.1 Turvatestimine 4.1.1 Selle hankelepingu alusel tellitakse turvatestimine. Testitava toote/lahenduse omapärad ei pruugi automaatsete vahenditega testimisel tõepäraseid tulemusi anda ja töö eesmärgiks on käsitsi turvatestimine. 4.1.2 Metoodilise turvatestimise käigus tuleb hinnata kõiki potentsiaalseid turvavigu ja need tuleb aruandes detailselt välja tuua koos võimalike lahenduste ja soovitustega. 4.1.3 Metoodiline turvatestimise kontrollimine peab olema tehtud hankelepingu ajal kehtiva OWASP ASVS versioon 4.0 või kõrgem tase 2 verifikatsiooninõuete käsitsi turvatestimise kontrollimise verifikatsiooninõuetele testimise metoodika alusel. 4.1.4 Tööde käigus tuleb täitjal kontrollida, et testitava rakenduste võimalike haavatavuste kaudu ei ole võimalik juurde pääseda andmetele, mis asuvad väljaspool testitava rakenduse funktsionaalsust. 4.1.5 Turvatestimine hõlmab ka kasutajate horisontaalset ja vertikaalset õiguste ületamise turvatestimise kontrollimist. 4.1.6 Täitja annab kriitilistest vigadest või vigadest, mille parandamine on keskmisest ajamahukam, teada jooksvalt turvatestimise käigus, kasutades selleks krüpteeritud turvalist andmekandjat või suhtluskanalit. 4.1.7 Turvatestimine viiakse läbi tellija testkeskkonnas. Vajadusel luuakse tellija ja täitja süsteemide vahel turvatud kanal infosüsteemidele ligipääsemiseks. 4.1.8 Turvatestimise läbiviimiseks peab täitja esitama IP aadressid, millelt hakatakse turvatestimist kontrollima. Tellija avab ligipääsud vastavalt IP aadressidelt testitavatele süsteemidele ning teeb vajadusel vajalikud testkasutajad. 4.2 Testiraportite kontrollimine 4.2.1 Selle hankelepingu alusel tellitakse testiraportite kontrollimine. Testitava toote/lahenduse omapärad ei pruugi automaatsete vahenditega testimisel tõepäraseid tulemusi anda ja töö eesmärgiks on käsitsi testiraporti kontrollimine. Käsitsi testiraportite kontrollimise all peab tellija silmas, et täitja tutvub talle kontrollimiseks saadetud raportitega ja analüüsib neid, võrdleb enda leitud tulemustega ja toob välja, mis on 5  põhilised erisused ja/või puudujäägid ning mis oli positiivne. Täitja võib eeltoodule lisaks märkida olulised asjaolud, mis talle kontrollimise käigus tähelepanu äratavad. 4.2.2 Kontrolli on vaja teostada tellija kahe (2) lepingupartneri poolt teostatud testiraportite kvaliteedile. 4.3 Testiraporti koostamine 4.3.1 Turvatestimise lõppedes edastab täitja testitavate toodete/lahenduste testiraporti tellijale krüpteeritud kujul. 4.4 Aruande koostamine 4.4.1 Testiraportite kvaliteedi kontrolli lõppedes edastab täitja testitavate toodete/lahenduste aruande tellijale krüpteeritud kujul. 5 Tööde dokumenteerimine 5.1 Käsitsi turvatestimise järel peab täitja üle andma turvatestimise raporti, mis peab sisaldama järgnevat infot: 5.1.1 millist testitava toote/lahenduse osa/komponenti ja millise tehnilise nõude vastu testiti; 5.1.2 kuidas testitava toote/lahenduse osa/komponenti testiti, millist tehnilist nõuet testiti ja kuidas tuvastatud potentsiaalset turvaviga saab reprodutseerida; 5.1.3 mis tulemus saadi, hinnata tuleb kõiki potentsiaalseid turvavigasid ja määrata veale kriitilisus; 5.1.4 detailselt potentsiaalseid turvavigu ning välja tuua võimalike lahenduste ja soovitustega parandusettepanekud. 5.2 Käsitsi testiraportite kontrollimise järel peab täitja üle andma aruande, mis peab sisaldama järgnevat infot: 5.2.1 Hinnang kahele testiraportile, kas nendes on arvestatud kõiki turvatestimise nõudeid punktides 4.1.2, 4.1.3, 4.1.4 ja 4.1.5. 5.2.2 Hinnang kahele testiraportile, kas nendes on täidetud testiraporti dokumenteerimise nõudeid 5.1.1, 5.1.2, 5.1.3 ja 5.1.4. 5.2.3 Lisa info hinnangule, mida ei saa välja tuua nõuetes 5.2.1 ja 5.2.2. 5.2.4 Aruandes peavad olema mõlema kontrollimiseks saadetud testiraportite kvaliteedi kontrolli kohta käiv info eristatav üksteisest ja täidetud peavad olema nõuded 5.2.1, 5.2.2 ja 5.2.3. 6  PROJEKT HANKELEPING nr..... Tervise ja Heaolu Infosüsteemide Keskus (edaspidi tellija), registrikood 70009770, aadress Uus- Tatari 25, 10134 Tallinn, keda esindab põhimääruse alusel direktor Katrin Reinhold ja ________, (edaspidi täitja), registrikood______, aadress______, keda esindab ______, edaspidi koos või eraldi nimetatud ka pool või pooled, sõlmisid tellija läbiviidud väikeostu „Turvatestimise ja testiraportite kontrollimine“ käesoleva hankelepingu (edaspidi leping) alljärgnevas: 1. Lepingu eesmärk ja ese 1.1. Tellija poolt korraldatud väikeostu „Turvatestimise ja testiraportite kontrollimine“ alusel sõlmitud lepingu eesmärk on infosüsteemide käsitsi turvatestimise OWASP (Open Web Application Security Project) ASVS (Application Security Verification Standard Project) versiooni 4.0 või kõrgem tase 2 ja testiraportite (kahe pakkuja testiraportid) üle kontrollimine. 1.2. Lepingu esemeks on turvatestimise ja testiraportite kontrollimise teenus (edaspidi teenus). Teenuse kirjeldus, lepingu täitmise tingimused, teenuse tulem ja konkreetsed realiseerimistähtajad on sätestatud tehnilises kirjelduses. 1.3. Leping jõustub sõlmimisel ja kehtib kuni poolte poolt oma kohustuste täitmiseni. 2. Üldtingimused 2.1. Lepingu juurde kuuluvateks lahutamatuteks osadeks loetakse kõik lisad ja väikeostu alusdokumendid ning täitja esitatud pakkumus ja pooltevahelised kirjalikud teated, mida lepingu lisadena eraldi ei allkirjastata. 2.2. Lepingu täitmisel lähtutakse lepingu ja selle juurde kuuluvate lahutamatute osade tingimustest. 2.3. Pooled teevad lepingu täitmiseks ja lepingu eesmärkide saavutamiseks koostööd. Pooled kohustuvad tegema kõik vajalikud pingutused, et täita leping õigeaegselt ja vastavalt kokkulepetele. 2.4. Pooled võivad kokkuleppel kaasata lepingu täitmise kvaliteedi või teenuse vastuvõtmise hindamiseks mõlema poole poolt aktsepteeritud sõltumatu eksperdi või audiitori. Kui tellija hinnang teenuse kvaliteedile või teenuse vastuvõtmisele osutub ekspertiisi tulemusel põhjendamatuks, hüvitab tellija ekspertiisikulud. Kui ekspertiis kinnitab tellija hinnangut kvaliteedile või teenuse vastuvõtmisele, jäävad ekspertiisikulud täitja kanda. 2.5. Täitja kohustub osutama teenust kvaliteetselt ning vastavalt valdkonna headele tavadele ja praktikale. Tellija eeldab, et täitja on valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda lepingu funktsionaalsete ja mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Sellest tulenevalt laieneb täitjale ka selliste 1  teenuse osutamise kohustus, mida ei ole lepingus kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad lepinguga seotud teenuse hulka. Nimetatud teenuse osutamine ei kuulu eraldi tasustamisele ning täitja osutab kirjeldatud teenuse lepingu täitmise raames. 2.6. Kui lepingu täitmisel tekivad täitja ja tellija vahel erimeelsused, lähtutakse lepingu eesmärkidest tellija seisukohalt. 2.7. Poolel on õigus teha teisele poolele ettepanekuid lepingu täitmise kvaliteedi tõstmiseks. Kui pool on esitanud teisele poolele lepingu täitmisega seotud küsimuses päringu, on pool kohustatud sellele sisuliselt reageerima (asjakohast tagasisidet andma) võimalikult kiiresti, kuid hiljemalt 3 tööpäeva jooksul, v.a juhul kui pöördumine nõuab täiendavat analüüsi või info süstematiseerimist. 2.8. Pooltel on kohustus osa võtta töökoosolekutest lepingu täitmise käigus tekkinud probleemide lahendamiseks ja infovahetuseks tellija juures kohapeal või virtuaalselt. Töökoosolekutel osalemist tellija ei tasusta, v.a juhul, kui lepingus on kokku lepitud teisiti. 2.9. Lepingu täitmise keel on eesti keel, muuhulgas on see ka lepingu sõlmimise, töökoosolekute jm suhtluse ning teenuse dokumenteerimise keel. 2.10. Nõuded dokumentatsioonile tulenevad tehnilisest kirjeldusest ja tellija poolt kodulehel avaldatud vastavatest nõuetest.1 3. Poolte õigused ja kohustused 3.1. Täitja kohustub: 3.1.1. osutama teenust lepingus kokkulepitud tingimustel ja ulatuses, sh tagama teenuse õigeaegse alustamise, osutamise, valmimise ja tellijale üleandmise; 3.1.2. tagama lepingu täitmiseks vajalike ressursside olemasolu, sh tagama lepingu täitmise kõrge professionaalse taseme ning vajaliku tehnoloogia ja metoodikate väga hea tundmise ning osutatud teenuse dokumenteerimise vastavalt tellija suunistele, samuti omama lepingu täitmiseks sobivaid keskkondi, koos kõige sinna juurde kuuluvaga, sh kasutatava tarkvara litsentsid, või kasutama tellija olemasolevaid jagatud keskkondi; 3.1.3. tegema koostööd kolmandate osapooltega pidades silmas tellija vajadusi (nt äritellijaga, teiste tellija arenduspartneritega jne); 3.1.4. teavitama viivitamatult tellijat lepingu täitmist takistavatest asjaoludest, mis segavad lepingus toodud teenuse osutamist ja tähtaegadest kinnipidamist või püstitatud eesmärgi saavutamist; 3.1.5. andma selgitusi ja konsultatsioone osutatud teenuse kohta; 3.1.6. juhinduma tellija suunistest lepingu eesmärkide saavutamisel, pöördudes selleks vajadusel tellija poole; 3.1.7. lepingu täitmise käigus tuvastatud vastuolu korral teavitab täitja vastuolu esinemisest tellijale viivitamatult; 3.1.8. osutama tellijale osutatud teenuse osas tuge, sh pakkuma konsultatsiooni kuni garantiiaja lõpuni; 3.1.9. täitma kõiki tellija juures kehtivaid ja õigusaktidest tulenevaid andmekaitsealaseid ja andmete turvalisust puudutavaid eeskirju, kui need on täitjale teatavaks tehtud; 3.1.10. osutama teenust kuni kokku lepitud tulemi üleandmise ja vastuvõtmiseni oma ressursside arvel, kui pooled ei ole kokku leppinud teisiti; 1 https://www.tehik.ee/meist/meistnouded-arendustele/ 2  3.1.11. teostama tööd kvaliteetselt ning vastavalt valdkonna headele tavadele ja praktikale. Tellija eeldab, et täitja on valdkonna professionaal, kes saab aru ning võtab teadlikult enda kanda lepingu funktsionaalsete ja mittefunktsionaalsete nõuete täidetavuse ja tulemuse saavutatavuse riski. Sellest tulenevalt laieneb täitjale ka selliste tööde tegemise kohustus, mida ei ole lepingus kokku lepitud, kuid mis oma olemusest lähtuvalt kuuluvad lepinguga seotud tööde hulka. Nimetatud tööde tegemine ei kuulu eraldi tasustamisele ning täitja teostab kirjeldatud tööd lepingu täitmise raames. 3.1.12. teavitama kirjalikku taasesitamist võimaldavas vormis oma mistahes huvist, mis võib põhjustada lepingu täitmisel huvide konflikti tekkimist. 3.2. Täitjal on õigus: 3.2.1. saada lepingu täitmise eest lepingus kokkulepitud ulatuses ja korras tasu; 3.2.2. kasutada lepingu täitmisel alltöövõtjaid, kooskõlastades alltöövõtjate kasutamise eelnevalt tellijaga. Alltöövõtjate tegevuse ja tegevusetuse eest vastutab tellija ees täitja; 3.2.3. anda arve esitamise õiguse üle kolmandale isikule lepingu muudatust sõlmimata, kui ta on tellijale esitanud sellekohase teate. 3.3. Tellija kohustub: 3.3.1. tasuma täitjale lepingu täitmise eest lepingus kokkulepitud ulatuses ja korras; 3.3.2. tagama täitjale ligipääsu (sh kaugjuurdepääsu) lepingu täitmiseks oluliste tellija hallatavate keskkondade olemasolu ja toimimise; 3.3.3. võtma aktiga vastu täitja poolt üle antud puudusteta teenuse mõistliku aja jooksul; 3.3.4. teavitama täitjale üle antud teenuses esinevatest puudustest ja andma puuduste kõrvaldamiseks mõistliku täiendava tähtaja, kui tähtaeg ei tulene muudest kokkulepetest. 3.4. Tellijal on õigus: 3.4.1. kontrollida jooksvalt lepingu täitmist ja anda täitjale selleks suuniseid või nõuda täitjalt sellekohast informatsiooni; 3.4.2. keelduda osaliselt või täielikult tasu maksmisest, kui täitja ei teostanud nõuetekohaselt teenust kokku lepitud tähtajaks ja täitja poolne rikkumine ei ole objektiivselt põhjendatud (nt on tegemist objektiivse põhjendusega, kui lepingu täitmine on viibinud tellija või kolmanda osapoole tegevuse tõttu); 3.4.3. kaasata lepingu täitmiseks tellija poolel kolmandaid osapooli, nt teisi riigiasutusi. Kolmanda osapoole kaasamine tellija poolt ei ole käsitletav lepingu muutmisena riigihangete seaduse mõttes. 4. Teenuse osutamise, tulemi üleandmise ja vastuvõtmise kord 4.1. Täitja annab teenuse tulemi üle kahes osas vastavalt lisas 1 sätestatud tähtaegadele. Tulemina antakse üle nõuetekohane dokumentatsioon, intellektuaalomandi õigused ja muu lepingus kokkulepitu. 4.2. Teenuse tulemid ja vajadusel teenuse teostamise käik dokumenteeritakse ning hallatakse tellija dokumendihalduskeskkonnas ja/ või koodihalduskeskkonnas (näiteks Confluence, GitLab, SVN). 4.3. Täitja annab tulemi üle omalt poolt allkirjastatud aktiga. 4.4. Tellija võtab teenuse vastu akti allkirjastamisega pärast tulemi kvaliteedi kontrollimist. 4.5. Teenus loetakse nõuetekohaselt teostatuks, kui teenus vastab lepingule ja teenus on aktiga tellija poolt vastu võetud. 3  4.6. Tellija võib teenuse vastu võtta, kui teenuses esineb üksikuid ja tellija jaoks väheolulisi pisivigasid, mis fikseeritakse aktis. Tellija poolne pisivigadega teenuse vastuvõtmine ei vabasta täitjat kohustusest vead kõrvaldada ning üle anda vigadeta teenust. Tellijal määrab mõistliku tähtaja pisivigade parandamiseks. 4.7. Tellijal on õigus keelduda teenuse vastuvõtmisest kui teenus ei vasta esitatud nõuetele. 4.8. Kui tellija esitab vastuväited teenusele, peab täitja teenuse parandama tellija poolt määratud mõistliku tähtaja jooksul. Kui täitja ei ole tellija antud tähtaja jooksul kõrvaldanud avastatud vigu, võib tellija teenuse ise parandada või lasta seda teha kolmandatel isikutel ja nõuda täitjalt selleks tehtud mõistlike kulutuste hüvitamist. 5. Täitja meeskond 5.1. Lepingu täitmisel osalevad pakkumuses esitatud meeskonnaliikmed, v.a juhul, kui täitjast mittesõltuval asjaolul ei ole seda võimalik teha ja meeskonnaliige on asendatud tellija kirjalikku taasesitamist võimaldaval nõusolekul uue, hanke tingimustele vastava meeskonnaliikmega. 5.2. Kui ilmneb vajadus vahetada meeskonnaliige, kelle kogemusi hankemenetluse käigus hinnati, asendatakse isik samaväärse meeskonnaliikmega tellija kirjalikku taasesitamist võimaldava nõusoleku saamisel. Kui hankemenetluses ei hinnatud meeskonnaliikmeid, võib meeskonnaliikme asendada isikuga, kes vastab hanke tingimustele, saades selleks tellijalt kirjalikku taasesitamist võimaldava nõusoleku. 5.3. Täitja asendab tellija nõudmisel ja määratud tähtajaks meeskonnaliikme, kui isik osutub tellija põhjendatud arvamuse kohaselt lepingujärgsete ülesannete täitmiseks ebakompetentseks või ebasobivaks või kui tema lepingujärgsete ülesannete täitmine kahjustab pidevalt lepingu täitmist. Täitja kannab kõik asendusega kaasnevad kulud. 5.4. Täitja võib tellija kirjalikku taasesitamist võimaldaval nõusolekul kaasata täiendavaid meeskonnaliikmeid, kui riigihankes pakkumusega esitatud meeskonnaliikmed on tellitud teenuse täitmisega hõivatud. Täiendavalt kaasatud meeskonnaliikmed peavad vastama rollile seatud hanketingimustele. 5.5. Täitja garanteerib riigihankes isikuliselt mitte välja toodud meeskonnaliikmete olemasolu ja vastavuse riigihankes nõutud kvalifikatsioonile/varasemale töökogemusele ning esitab teenuse osutajad nimeliselt lepingu sõlmimisel. 6. Lepingu hind 6.1. Tellija tasub lepingu alusel tellitud teenuse eest kokku ühes osas _____ (maksumus sõnadega) eurot käibemaksuta. 6.2. Teenus antakse üle järgmistes etappides: 6.2.1. turvatestimine; 6.2.2. testimisraportite kontrollimise aruanne. 6.3. Täitjal on õigus esitada e-arve pärast mõlema teenuse aktiga vastu võtmist. Arvel tuleb märkida riigihanke nimetus, lepingu number ning kontaktisiku andmed. 6.4. Arve tasumiseks annab täitja minimaalselt tähtaja 21 kalendripäeva alates arve laekumisest. 4 7. Intellektuaalomand 7.1. Täitja kinnitab lepingu allkirjastamisega, et talle kuuluvad lepingu täitmiseks vajalikud autoriõigused, litsentsid ja muud intellektuaalse omandi õigused, mis on vajalikud lepingu järgsete teenuse osutamiseks ja õiguste loovutamiseks tellijale ning nende suhtes ei ole õigusi ega nõudeid kolmandatel isikutel. 7.2. Tasu intellektuaalse omandi varaliste õiguste loovutamise ja litsentsi andmise eest sisaldub lepingu hinnas. 7.3. Täitja loovutab tellijale lepingu täitmise käigus loodud kõik mistahes vormis teenuse osad, mis puutuvad teenuse osutamisse, kõik autori varalised õigused ning annab lihtlitsentsi autori isiklikele õigustele koos all-litsentsi andmise õigusega kogu autoriõiguste kehtivuse ajaks ilma geograafiliste piiranguteta teenuse üleandmise hetkest, loobudes sellega lepingu alusel üle antud originaalteoste osas õiguste kasutamisest. 7.4. Täitja tagab, et isiklikud õigused on ilma täitja nõusolekuta teostatavad muuhulgas järgnevas ulatuses: 7.4.1. tellijal on õigus teenuse tulemit kasutada mis tahes eesmärgil ja viisil; 7.4.2. tellijal või tellija tellimusel kolmandatel isikutel on õigus teha üle antud teenuse tulemis muudatusi ning neid täiendada; 7.4.3. tellijal või tellija tellimusel kolmandatel isikutel on õigus osutatud teenust muuta või teenusele lisada tellija või kolmandate isikute poolt loodud teenuse tulemit; 7.4.4. teenuse üleandmisega tellijale kinnitab täitja, et teenuse tulem on üldsusele avaldamiseks valmis. 7.5. Täitja tagab tellijale kõik vajalikud õigused lepingu täitmise käigus loodavate teenuse kontrollimiseks ka ajal, mil teenus on vastuvõtutestimiseks üle antud, kuid ei ole veel tellija poolt aktiga vastu võetud. 7.6. Täitja on kohustatud tagama intellektuaalse omandi õiguste (eeskätt autoriõiguste) olemasolu ja kehtivuse, samuti nende ülemineku tellijale viisil, mis võimaldab tellijal lepingu lõppedes üle võtta täitja funktsioonid. 7.7. Täitja kohustub lahendama kõikvõimalikud lepingujärgsete teenusega seotud intellektuaalse omandi õigustest tekkivad vaidlused kolmandate isikute või oma töötajate või koostööpartneritega. 7.8. Kõik tellijale kaasnevad otsesed ja kaudsed kahjud, mis tulenevad sellest, et kolmandal isikul on või väidetavalt on varalisi või mittevaralisi intellektuaalsest omandist tulenevaid õigusi lepingu alusel üle antavate intellektuaalse omandi objektide suhtes, kannab täitja. 7.9. Selles alapeatükis kirjeldatud õigused ja litsentsid loetakse tellijale lõplikult üle läinuks pärast teenuse vastuvõtmist. 8. Vastutus 8.1. Pool vastutab oma lepingulise kohustuse rikkumise eest, välja arvatud juhul, kui rikkumine on vabandatav vääramatu jõu või muu objektiivse asjaolu tõttu. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 8.2. Pool vastutab oma lepingulise kohustuse rikkumise eest, mis tuleneb tema poolt lepingu täitmisse kaasatud isikute tegevusest. 8.3. Pool ei vastuta lepinguliste kohustuste rikkumise eest, mis tulenes teise poole kohustuste rikkumisest või kolmandate isikute tegevusest või tegemata jätmistest. Kui tellija viivitab 5  omapoolsete kohustuste täitmisega ja nende kohustuste mittetähtaegne täitmine ei võimalda täitjal omapoolseid kohustusi tähtaegselt täita, pikendatakse teenuse üleandmise tähtaega vastava aja võrra. Nimetatud asjaolu esinemist peab tõendama pool, kes sellele tugineda soovib. 8.4. Kohustuse rikkumisel on teisel poolel õigus kasutada kõiki seadusest või lepingust tulenevaid õiguskaitsevahendeid vastavalt võlaõigusseadusele. 8.5. Poolte rahaline koguvastutus on piiratud lepingu kogumaksumusega, kuid see piirang ei kehti süülisel rikkumisel, sh süülisel rikkumisel seoses intellektuaalomandiõiguse või andmekaitsealaste kohustustega. 8.6. Tasu maksmisega viivitamisel on täitjal õigus nõuda viivist võlaõigusseaduses sätestatud määras konkreetse teenuse eest maksmisele kuuluvast tasust iga tasumisega viivitatud kalendripäeva eest. Viivise maksimaalne määr on 25% konkreetsete teenuse eest tasumisele kuuluvast kogusummast. Viivise nõue tuleb esitada allkirjastatult. 8.7. Täitja poolse lepinguliste kohustuste rikkumisena käsitletakse eeskätt olukorda, kus üle antud teenus ei vasta osaliselt või täielikult lepingu tingimustele või esineb muid täitja poolseid lepingu rikkumisi. 8.8. Kui täitja rikub lepingulist kohustust, on tellijal õigus nõuda leppetrahvi tasumist, mille suuruseks on 200 eurot iga rikkumises oldud kalendripäeva eest, kuid mitte rohkem kui 25% lepingu kogumaksumusest. Kui lepingu täitmine on kokku lepitud etappide kaupa, siis mitte rohkem kui 25% etapi kogumaksumusest. 8.9. Juhul kui täitja poolsetest viivitustest tingitult ei ole teenuse tulemi kasutuselevõtt enam realistlik või vajalik, on tellijal õigus lepingust taganeda vastavalt võlaõigusseaduse § 116 lõikele 1 ning täitja on kohustatud tegema juba makstud osa eest tellijale tagasimakse. 8.10. Lepingu olulise rikkumise korral on tellijal õigus esitada täitjale leppetrahvi nõue 10 000 eurot iga rikkumise eest. Täitja poolse olulise lepingu rikkumise korral ei pea tellija määrama täitjale lepingu täitmiseks võlaõigusseaduse §-s 114 nimetatud täiendavat tähtaega ning tellijal on muu hulgas õigus leping üles öelda või lepingust taganeda. 8.11. Oluliseks rikkumiseks loevad pooled lisaks võlaõigusseaduses sätestatule muuhulgas: 8.11.1. mõjuva põhjuseta teenuse vastu võtmata jätmine või täitmisele mitte asumine; 8.11.2. valeinfo esitamine; 8.11.3. lepingu täitmiseks vajalike õiguste (sealhulgas load, litsentsid, intellektuaalse omandi õigused) puudumine; 8.11.4. intellektuaalse omandi õiguste ja nende kasutamise tingimuste rikkumine; 8.11.5. korduv (vähemalt kahel korral) meeskonnaliikme asendamine isikuga, kes ei vasta kokku lepitud nõuetele või meeskonnaliikme asendamine ilma tellija eelneva vähemalt kirjalikku taasesitamist võimaldavas vormis antud nõusolekuta; 8.11.6. konfidentsiaalsuskohustuse rikkumine; 8.11.7. lepingujärgsete kohustuste korduvat (vähemalt kahel korral) täitmata jätmist; 8.11.8. tähtaegselt lepingu täitmata jätmist selliselt, et tehnilises kirjelduses sätestatud eesmärgi täitmine ei ole enam tähtaegselt realistik ja/või täitja poolse tegevuse või tegevusetuse tõttu ei ole võimalik enam kasutada lepingu rahastamiseks ettenähtud vahendeid; 8.11.9. lepingujärgsete kohustuste üleandmine kolmandale isikule ilma tellija digiallkirjastatud nõusolekuta. 6  8.12. Teenuse vastuvõtmine tellija poolt ei vabasta ega vähenda täitja vastutust lepingu rikkumise eest. 8.13. Kui täitja ei täida lepingut nõuetekohaselt ja selle alusel teeb rakendusasutus toetuse vähendamise või tagasinõude otsuse, on tellijal õigus täitjalt tagasi nõuda mitteabikõlbulikud kulud tagasimakse nõude ulatuses. 8.14. Leppetrahvi nõude kohustub tellija esitama mõistliku aja jooksul, kuid mitte hiljem kui 3 kuu jooksul alates päevast, mil tellija sai teadlikuks leppetrahvi nõude aluseks olevast asjaolust. Leppetrahvi nõude vaidlustamine ei vabasta täitjat selle maksmise kohustusest enne vastava kohtuotsuse jõustumist. 8.15. Täitja on kohustatud leppetrahvi tasuma 2 nädala jooksul alates tellija poolt vastava nõude esitamisest, kui leppetrahvi nõudes ei ole määratud teisiti. 8.16. Tellijal on õigus tasaarvestada leppetrahvi summa täitjale lepingu täitmise eest tasumisele kuuluvate maksetega. Tasaarvestamise korral ei rakendata leppetrahvi tasumise kohustust. 9. Konfidentsiaalsuskohustus 9.1. Pooled kohustuvad vastastikku hoidma salajas ja mitte avaldama kolmandatele isikutele ükskõik missugust konfidentsiaalseks peetavat informatsiooni, mis on saadud teiselt poolelt lepingu alusel tellitud teenuse osutamise käigus või muul viisil või juhuslikult. 9.2. Täitja peab võtma kasutusele isikuandmete ja tellija infosüsteemide kaitseks organisatsioonilisi, füüsilisi ja infotehnilisi turvameetmeid, lähtudes muuhulgas kehtivatest õigusaktidest. Täitja ei tohi töödelda arenduskeskkondades reaalseid ja isikustatud andmeid. 9.3. Juhul, kui lepingu täitmise raames osutub vajalikuks isikuandmete töötlemine, lepivad pooled isikuandmete töötlemise tingimused kokku, juhindudes isikuandmete kaitse üldmääruse2 artiklis 28 kirjeldatust. 9.4. Konfidentsiaalse informatsiooni all mõistavad pooled igasugust informatsiooni (sh ärisaladusi, isikuandmeid, lepingute andmeid, infosüsteeme, turvasüsteemide kirjeldusi, riistvara ja tarkvara kirjeldusi, pakkumuse kirjeldusi, kasutatavaid tehnoloogiaid, spetsifikatsioone jms), mis on saadud seoses lepingu täitmisega ja mille sattumine kolmandate isikute kätte võib pooltele põhjustada turvariske või majanduslikku kahju või kolmandate isikute (eelkõige tellija klientide) eraelu puutumatuse rikkumist. Kahtluse korral eeldatakse informatsiooni konfidentsiaalsust. 9.5. Konfidentsiaalne informatsioon ei hõlma endas informatsiooni, mille avalikustamise kohustus tuleneb õigusaktidest või mille avalikustamiseks pooled on andnud nõusoleku. 9.6. Pooled võivad edastada konfidentsiaalset informatsiooni ainult nendele isikutele, kes on tellitud teenuse osutamisega otseselt seotud. Täitja kohustub tagama, et isikud, keda ta oma kohustuste täitmisel kasutab, oleksid konfidentsiaalsuse kohustusest teadlikud ning nõudma nimetatud isikutelt selle kohustuse tingimusteta ja tähtajatut täitmist. Vastutus konfidentsiaalsuskohustuste täitmise eest lasub täitjal. 9.7. Pooled ei kasuta lepingu täitmisel neile teatavaks saanud konfidentsiaalset informatsiooni oma huvides ega muul eesmärgil, kui tellitud teenuse osutamiseks. 2 Euroopa Parlamendi ja Nõukogu määrus nr (EL) 2016/679. 7 9.8. Konfidentsiaalsuskohustuse rikkumise korral kohustub täitja hüvitama kõik kahjud, mis sellise rikkumise tagajärjel tellijale või kolmandale isikule tekkisid, sõltumata sellest, kas rikkumine pandi toime lepingu kehtivuse ajal või lepinguliste kohustuste lõppemise järgselt. 9.9. Täitja on teadlik, et leping ja kokkulepped on avalikud, v.a osades, mis on avaliku teabe seadusest tulenevatel alustel määratud asutusesiseseks kasutamiseks või märgitud täitja poolt ärisaladuseks. 9.10. Konfidentsiaalsuskohustus kehtib tähtajatult. 10. Lepingu kehtivus 10.1. Leping jõustub sõlmimisel. 10.2. Lepingut muudetakse poolte vahelise kirjaliku kokkuleppega lepinguga samas vormis, arvestades riigihangete seaduses toodut. 10.3. Kui mõni lepingu tingimus peaks osutuma osaliselt või täielikult kehtetuks või täitmisele mittepööratavaks, ei mõjuta see teiste lepingu tingimuste kehtivust ning lepingu ülejäänud tingimused jäävad kehtima ja täitmisele pööratavaks. Sel juhul võimalusel asendatakse kehtetu või täitmisele mittepööratav tingimus õiguslikult kehtiva tingimusega, mis on sisult võimalikult lähedane poolte kavatsustele ja kehtetu tingimuse majanduslikule mõjule. 10.4. Tellija võib lepingu igal ajal sõltumata põhjusest lõpetada, teatades sellest kirjalikku taasesitamist võimaldavas vormis ette 30 päeva. Lepingu lõpetamine vabastab pooled käesoleva lepinguga sätestatud kohustuste täitmisest. 10.5. Tellijal on õigus leping ühepoolselt etteteatamistähtaega järgimata üles öelda või sellest taganeda, kui täitja on oluliselt lepingut rikkunud või juhul, kui täitja: 10.5.1. suhtes on algatatud pankrotimenetlus; 10.5.2. pankrot on välja kuulutatud; 10.5.3. täitja varad arestitakse; 10.5.4. täitja finantsseisund halveneb tellija põhjendatud hinnangul oluliselt ja see muudab lepingu nõuetekohase täitmise vähetõenäoliseks. 10.6. Lepingu lõppemisel mistahes alusel ja põhjusel on täitja kohustatud tellijale üle andma kogu teenusega seotud informatsiooni ja dokumentatsioon (nii digitaalselt kui paberkandjal, samuti informatsiooni, mida ei ole salvestatud eelnimetatud infokandjatele). Üleantav info ja dokumentatsioon peab olema süstematiseeritud. Täitja on kohustatud andma ammendavad selgitused eelkirjeldatud informatsiooni haldamise ja kasutamise kohta, tehes seda tellija nõudmisel kirjalikult. 11. Teadete edastamine ja kontaktisikud 11.1. Teadete edastamine toimub üldjuhul e-posti teel, lähtudes kodukorra tingimustest selle olemasolul. E-posti teel, sh digitaalselt allkirjastatud dokumentide, saatmise korral loetakse teade kättesaaduks kohale jõudmise teates märgitud kellaajal või e-kirjas näidatud saatmise kellaajal. 11.2. Juhul, kui teate edastamisel on olulised õiguslikud tagajärjed, peab teade olema edastatud digiallkirjastatult poole allkirjaõigusliku isiku poolt. Informatiivset teadet võib edastada ka telefoni teel. Informatiivseks loetakse teade, millega ei kaasne õiguslikke tagajärgi. 8  11.3. Kirjalik teade loetakse poole poolt kättesaaduks, kui see on üle antud allkirja vastu või kui teade on saadetud postiasutuse poolt tähitud kirjaga poole poolt teatatud aadressil ja postitamisest on möödunud 5 kalendripäeva. 11.4. Tellija kontaktisik(ud) on: …. …, telefon …., e-post: …. või tema asendaja; 11.5. Täitja kontaktisik(ud) on: …, …., telefon … e-post: …. või tema asendaja; 11.6. Kontaktisikute pädevuses on anda teisele poolele vajaliku informatsiooni ja juhiseid oma pädevuse piires, anda nõusolek meeskonnaliikme vahetamiseks, kontrollida teostatud lepingu kvaliteeti, anda lepingu ese üle ja võtta vastu ning allkirjastada akt. 11.7. Kontaktisiku muutumisest teavitab pool kirjalikult teist poolt viivitamatult. 12. Lõppsätted 12.1. Täitjal puudub volitus tegeleda lepingu raames avalike suhetega ning anda teateid Lepinguga seotud vaidlused, mida pooled ei ole suutnud läbirääkimiste teel lahendada, antakse lahendamiseks Harju Maakohtule. 12.2. Lepingule kohaldub Eesti õigus. 12.3. Lepinguga reguleerimata küsimustes või olukorras, kus mõni lepingu säte on vastuolus seadusega, lähtutakse Eesti Vabariigis kehtivast seadusandlusest. 13. Lisad (ei allkirjastata) 13.1. Lisa 1 – Tehniline kirjeldus ja selle lisad; 13.2. Lisa 2 - Üleandmise-vastuvõtmise akt; 13.3. Lisa 3 – Pakkumus. 14. Poolte allkirjad Tellija Täitja /allkirjastatud digitaalselt/ /allkirjastatud digitaalselt/ 9