Functional requirements for non- repudiation in eHealth domain For potential eHealth dispute resolution we need the following (among possible other data): – Query contents Like patient identity traits in XCPD Like id of the document requested in XCA Includes document and its metadata in XDR – Response contents Patient demographical data in XCPD Document metadata or full document in XCA OK/Error in XDR (and in fact also in XCPD and XCA) – When this happened and who were involved HCP Patient NCPs

What is in the non-rep token? From ISO , Non-Repudiation of Origin token (NROT), and assumptions for its implementation in OpenNCP: – Identifier of the non-rep policy – assume constant – Flag indicating the non-rep of the origin – assume constant – Identifier of the originator – assume HCID of the originating NCP – Identifier of the recipient – assume HCID of the target NCP – Timestamp – assume generated by the originating NCP – Optional additional info such as message id, signature and hash algorithm ids, certificates – assume not needed, as it is included in XML Digital Signature. – Message itself (like query or response data, including possible documents) or its hash – assume this is the message itself, with possible documents, as message contents is needed for dispute resolution – The signature on everything listed above – assume this is an enveloped XML Digital Signature. Data missing from the current implementation is bolded. The timestamp is present, but not precise enough (only date). The contents of the token must be stored by the NCP or NI for dispute resolution

Response Query Current implementation, Patient Identification (XCPD) NCP BNCP A HCP ID assertion Query data Patient id, name, etc. Basic ATNA audit data HCP ID assertion Signed data in italics

Response Query Implementation with Non-rep BB, Patient Identification (XCPD) NCP BNCP A HCP ID assertion Query data Patient id, name, etc. ATNA audit incl. assertions Non-rep token B Non-rep token A Full query and full response Signed data in italics ATNA audit incl. assertions

Response Query Current implementation, Document retrieve (XCA) NCP BNCP A HCP ID assertion Document ID, reg. ID, HCID Document metadata Basic ATNA audit data HCP ID assertion TRC assertion Basic ATNA audit data HCP ID assertion TRC assertion Document Signed data in italics

Response Query Implementation with Non-rep BB, Document retrieve (XCA) NCP BNCP A HCP ID assertion Document ID, reg. ID, HCID Document metadata TRC assertion Document Non-rep token B Non-rep token A Full query and full response Signed data in italics ATNA audit incl. assertions

Disclaimer to the previous images Only Non-Repudiation of Origin (NRO) is covered. – However, in synchronous communication the NRO token of the response may be considered for Non- Repudiation of Delivery (NRD), as the response includes the query ID and other data (but not in XDR). – Might as well include the full NRD token in the response for stronger non-repudiation of delivery.

What if… As most of the data required by the non-rep token is already included in the messages exchanged by the NCP, Could we add any missing data in the messages and sign the messages (XML Digital Signature)? Then we need to store full messages on the evidence log (in NCP if legally possible or in NI) Perhaps this is too simple? – Might as well skip ETSI REM – Might as well skip XACML policies – Might as well skip ATNA extensions – But still it seems to fulfil the functional requirements

Need to better understand what is brought by these standards ETSI REM helps us to be politically closer to other eSENS use cases. Techically: – Other eSENS use cases use asynchronous communication, in which ETSI REM protocol is suitable (but not suitable as a communication type/protocol in eHealth). – Is OpenNCP planned to be used for implementing other eSENS use cases? Does it need to support asynchronous communication and full ETSI REM? – ETSI REM has an extensible schema for writing evidence data. We might or might not use it. Using only the schema defined in REM without any other REM functionality does not bring OpenNCP much closer to eSENS – what should be done to make this happen?

Need to better understand what is brought by these standards Support for XACML policies makes it possible to define different processing rules for different NCPs – Currently no XACML policy engine is implemented in OpenNCP, this was discussed last in winter – No clear PEP PIP PDP PAP services, though implementation of the assertion validator is a separate module (Java API). – Implementing a full XACML policy engine is a considerable effort for OpenNCP. – Most of the policy rules are mandated by epSOS. There is support for certain variation country-by-country (DefaultPolicyManager provided by OpenNCP, may be overridden in each country). – Do we define a standard non-rep policy for eHealth or do we need to support varying policies?

Need to better understand what is brought by these standards IHE ATNA extensions: need to better understand what they are. – IHE ATNA has progressed since OpenNCP implementation, new version of the standard needs to be accommodated? – Are there any extensions related to the non-rep solution? If there are, need to understand their function.

Some other stupid questions If the target of CEF is to establish a common message exchange infrastructure, do we need to define a common set of rules, protocols, and a common implementation? – Like Estonian X-Road – Or Microsoft BizTalk but without a central server – Or any other ESB-type solution Communicatoin protocols vary by domains, do we define a common message exchange protocol instead of, or in addition to, or on top of them? Is OpenNCP thought as a start of the European ”information backbone”? It only supports eHealth and synchronous communication at the moment.