Cahier des charges technique General Requirements Document Heiko Zimmermann. Cahier des charges technique

Transcription

1 Cahier des charges technique Version

2 Name Organisation For validation For comment For info Cahier des charges technique CR SANTEC Project CARA/LABO Work Package CARA : WP13 Cahier des charges technique LABO : WP5 - Cahier des charges technique Project Manager CARA Andreas Jahnen [email protected] LABO Stefan Benzschawel [email protected] Author [email protected] List of Dissemination Carlo Back Direction de la Santé [email protected] X Natasha Jerusalem Direction de la Santé [email protected] X René KRIPPES Direction de la Santé [email protected] X Jean-Charles Dron Health Management Solutions [email protected] X Stefan Benzschawel CRP Henri Tudor [email protected] X Dr. Cédric Pruski CRP Henri Tudor [email protected] X Hanan Bouzid CRP Henri Tudor [email protected] X Claude Poupart CRP Henri Tudor [email protected] X Guido Bosch CRP Henri Tudor [email protected] X Cahier_des_charges_Technique_General_v1.0.docx2/158 Version 1.0,

3 Goal of the Document This document describes how third-party systems could interact with the esanté platform for sharing and distributing medical reports. The technical interface of the Connector-API is described here, which is based on the work done during the CARA and LABO Use Case and Cahier de charges fonctionnel analysis. Therefore the essential functional requirements and Use Cases are translated into technical requirements and interface definitions. This document does not describe the technical details and detailed implementation of the esanté platform, but the functions defined here are using the core esanté platform functions. State of the Document The information contained in this document is based on the functional specification from the Cahier des charges fonctionnel and the former workpackages of CARA and LABO, and the work done for the esanté platform as described in the WP7 of the esanté project. Change History Version Date Author Modification HZI Initial draft HZI HZI HZI Corrections in Chapter 5.3d Extension and corrections after review from René Krippes, Chapters about security and optional transactions added Extensions and splitting of the document, after second review from René Krippes and Jean-Charles Dron HZI Changes and additions after document review from René Krippes and Jean-Charles Dron HZI Small changes Chapter 5.4s, 7.1b and Glossary, after review from René Krippes and Jean-Charles Dron Cahier_des_charges_Technique_General_v1.0.docx3/158 Version 1.0,

4 Table of Contents 1 Introduction Functional Architecture Core platform access Connector API architectural considerations Core platform function layer overview Actors Core functions overview FU-CORE-1: Provide and Register Document Set FU-CORE-2: Register Document Set FU-CORE-3: Registry Stored Query FU-CORE-4: Retrieve Document Set FU-CORE-5: Register Notification FU-CORE-6: Unregister Notification FU-CORE-7: Update Documentset Connector-API and platform security requirements Connector-API functional level specification Data types Exceptions Document formats and requirements a XDSSubmissionSet Attributes b XDSDocumentEntry Attributes c XDS metadata and CDA R2 document header element mapping d Platform document states and transitions e Requirements for the usage of the entryuuid parameter as a transactionid f Unique document identifiers General Connector-API interface a Connector-API functions overview b Connector-API functions detailed description c FU-CON-1: SubmitDocumentsXDR d FU-CON-2: SubmitDocumentsXDS e FU-CON-3: SubmitAddendumXDR f FU-CON-4: SubmitAddendumXDS g FU-CON-5: CancelDocument h FU-CON-6: ReplaceDocumentXDR i FU-CON-7: ReplaceDocumentXDS j Principles for the usage of the Data Consumer functions for document query and retrieval k FU-CON-8: QueryDocumentsXDR l FU-CON-9: QueryDocumentsXDS m FU-CON-10: RetrieveDocumentsXDR n FU-CON-11: RetrieveDocumentsXDS o FU-CON-12: SubmitReferralXDS p FU-CON-13: QueryReferralXDS q FU-CON-14: QueryDocumentReaders r FU-CON-15: UnblockDocuments s FU-CON-16: QueryProvidedDocuments Required extensions for the CARA interface Cahier_des_charges_Technique_General_v1.0.docx4/158 Version 1.0,

5 6.1 Document formats a CDA radiology report b Key Object Selection Documents (DICOM KOS Documents) CARA related Data Provider functions a FU-CARA-1: SubmitRadiologyReport&ImagesXDR b FU-CARA-2: SubmitRadiologyReport&ImagesXDS c FU-CARA-3: SubmitAddendumReport&ImagesXDR d FU-CARA-4: SubmitAddendumReport&ImagesXDS e Other CARA Data Provider related functions CARA related Data Consumer functions Required extensions for the LABO interface LABO related Data Provider functions a FU-LABO-1: SubmitLaboratoryReportsXDR b FU-LABO-2: SubmitLaboratoryReportsXDS c Other LABO Data Provider related functions LABO related Data Consumer functions Required extensions concerning the IHE profiles Messageid as part of the metadata for Submission- and DocumentEntrySet Patient access blocking and the unblocking code Referral code Abnormal results flag Security related enhancements Conclusion References to other documents Glossary of terms Appendix A: FU-CARA-XX: SubmitAppointmentInfoXDS (optional) Appendix B: CDA R2 document format for the appointment document Cahier_des_charges_Technique_General_v1.0.docx5/158 Version 1.0,

6 1 Introduction As a technical specification this document is based on the requirements identified during the work for the Use Case analysis and functional specification. The technical basis for the development of this specification is the core functionality of the esanté platform, which is based on common IHE profiles like XDS.b and XDS-I.b. The platform is not described in detail in this document, but the functions which are needed for this specification are briefly described in a separate chapter. This specification defines the functional level between the systems of Data Providers (doctors, hospitals,...), Data Consumers (doctors, hospitals, patients,...) and the esanté platform. This functional level, hereinafter called "Connector-API", provides a layer to access the platform functionality from systems which are not able to communicate with the platform by using the core platform functionality directly. We start the specification with a description about the functional architecture and its different layers. Then a briefly introduction of the required core platform functions follows. After that we will describe in detail the possible realization for the Connector-API layer, respecting the specifications done in the Cahier de charges fonctionnels and the terms and conditions of the technical environment (XDS, XDS-I). Cahier_des_charges_Technique_General_v1.0.docx6/158 Version 1.0,

7 Connector-API Cahier des charges technique 2 Functional Architecture The functions described as part of the Cahier des charges fonctionnel, are the main functions which are part of this technical description. Those reside at the Connector-API layer shown in the picture below. Data Consumer Direct access Security/Monitoring functions Web-Service API Data Consumer functions Web-Service API Web-Server https Data Consumer esanté core platform Web-Service API Administrative functions Web-Service API Data Provider functions HL7 Gateway Comserver PACS Direct access HIS/RIS Data Provider Data Provider In the picture above a functional architecture overview is shown. In the center of the image the esanté internal functions are grouped as the esanté core platform layer. Some of these functions are exposed to Web-Service interfaces and are accessible from the outside. The core platform functions could be logically grouped into Data Consumer- and Data Provider functions which are Cahier_des_charges_Technique_General_v1.0.docx7/158 Version 1.0,

8 shown in the picture as the lightly red segments. This is just a logical level and does not add further functionalities. To access the functions of the Data Provider- and Data Consumer layer, different implementations are supported. Applications could access the Web-Service API layer directly or by using the intermediate layer of the Connector-API (shown by the dark green semi-circle). The lighter green semi-circle on the right side shows some possibilities to access the functional layer, e.g. a Web-Server could be used to provide access by deploying an Applet to the client, this is convenient for Data Consumer clients which are using the Web Viewer or for health professionals which are using a patient management system without esanté integration. Healthcare Data Provider e.g. institutions/hospitals could use a Gateway to connect to the platform or could access the Data Provider functions of the system directly, if they are supported by their application. The main difference is that using the interface functions of the Connector-API, a less set of parameters must be provided during the function call, because most of the parameters which are needed to call the general functions of the platform are provided by the API or could be extracted out of the CDA R2 document header. Therefore the Data Provider must ensure that the mandatory parameters could be extracted out of the CDA document. This leads to the implication that those function calls must be made by providing unencrypted CDA documents, which raises no security issues as long as the processing is done inside the institution. When using the esanté Web-Service API functions, the Data Provider must provide these parameters as part of the function call (e.g. as elements of an XML). At this time the document must be encrypted, the platform functions are not able to extract metadata from the document itself. Cahier_des_charges_Technique_General_v1.0.docx8/158 Version 1.0,

9 2.1 Core platform access In cases where third-party applications want to directly access the core esanté platform functionalities, they have to implement the required mechanisms which are covered by the Connector-API. Because the requirements of the platform to ensure data integrity and security are different to those specified with the IHE profiles for XDS.b/XDS-I.b, it is not sufficient for implementers to be compliant to those IHE profiles. Instead the vendors must implement the additional functionality which is specified as API calls between the Connector-API and the core system components. So therefore a good starting point to measure the possible implementation effort to implement a direct core platform access, is to take a look at the transactions between the Connector-API and core system components, as shown in the functional level specification in chapter 5 and the sequence diagrams of these functions. Certificate Authority Health Professional Register Check CRL STS Security Token Service Validate National Register Authenticate Validate TTP Authorization token PACS EAI De-Identify messageid HIS/RIS Hospital Provide and register document response Document Repository response messageid Registry Service pseudonym Register document Cahier_des_charges_Technique_General_v1.0.docx9/158 Version 1.0,

10 2.2 Connector API architectural considerations The Connector-API bridges the logical gap between the current software systems of the healthcare providers and the esanté platform. The API provides an easier interface to the backend esanté core platform functionalities and hides most of the complex transactions and workflows, including security related functionality. For common healthcare IT infrastructures e.g. in hospitals, the usage of the Connector-API interface will be easier to provide and maintain, than to force their software vendors to implement a core platform access. Also out of software quality assurance reasons and possible software releases which should be independent of the software lifecycle of the primary installed healthcare IT systems, the usage of the Connector- API should be preferred. Certificate Authority Health Professional Register Check CRL STS Security Token Service Validate National Register Authenticate Validate TTP Authorization token PACS HIS/RIS Hospital EAI Connector-API response Document Repository De-Identify messageid response messageid Registry Service pseudonym Provide and register document Register document The API functionality described in this document could be integrated directly into third-party software systems or be used in a standalone environment e.g. a Gateway or Connector server which could provide the access to the esanté platform in hospitals or as part of Viewer applications e.g. Applets for doctors. The Connector-API does provide the connectivity, visualization or processing of the documents has to be implemented by the Data Consumer applications themselves. Cahier_des_charges_Technique_General_v1.0.docx10/158 Version 1.0,

11 Healthcare application Security/Monitoring functions Web-Service API Data Consumer functions Web-Service API Connector-API Data Consumer esanté core platform Web-Service API Administrative functions Web-Service API Data Provider functions Connector-API calls Connector EAI PACS Data Provider Hospital HIS/RIS The Connector-API provides an easier interface to the backend esanté core platform functionalities and hides most of the complex transactions and workflows, including security related functionality. For common healthcare IT infrastructures e.g. in hospitals, the usage of the Connector-API interface will be easier to provide and maintain, than to force their software vendors to implement a core platform access. Also out of software quality assurance reasons and possible software releases which should be independent of the software lifecycle of the primary installed healthcare IT systems, the usage of the Connector-API should be preferred. Cahier_des_charges_Technique_General_v1.0.docx11/158 Version 1.0,

12 3 Core platform function layer overview The core functions are provided as part of the esanté platform. In this chapter we will describe some of the functions in short, before going into details about the Data Provider and Data Consumer Connector-API functional layer in the next chapter. These core platform functions are more general than the main functions of the Connector-API. Since the core platform functionality will be based on the definition of the IHE-XDS.b profile (with enhancements), the detailed specification of these transactions could be found as part of the IHE specifications, see 10 References to other documents. In addition to the profile above, the platform should support from the beginning on update functionalities for metadata as defined in the XDS Metadata Update profile. Although the core functionalities are already part of the ebxml specification, which is the specification XDS relies on, metadata update in IHE is still in trial implementation state. 3.1 Actors The actors listed in the table below are common actors which are used also in the description of the Connector-API main functions. ID Actor Description Example A1 Data Provider This actor is able to create documents in a way that they are compliant to the platform document format definitions, with the aim to share the document. treatment. A2 A3 A4 A5 Data Consumer Document Administrator Document Registry Document Repository This actor is able to work with documents got from the platform and is able to understand the platforms document format definition. This actor is able to update/delete documents or document metadata. This actor is providing services for the registration/query/retrieval of document metadata. This actor is responsible for storing the documents physically. A6 Subscriber This actor can be grouped with Data Consumer or Data Provider actor, for their Healthcare professional emitting patient care report related to a patients Healthcare professional retrieving patient care report for further patient treatment. Role which could be grouped with Data Provider or Data Consumer Actors for the execution of updates of Document related metadata. The Document Registry contains metadata and references of the documents stored in the Repositories. The Data Provider provides the medical document together with metadata to the Document Repository using the ProvideAndRegisterDocume ntset transaction. A Data Consumer e.g. the Patient wants to get Cahier_des_charges_Technique_General_v1.0.docx12/158 Version 1.0,

13 subscription to get notified about the occurrence of different events. notified if new documents are provided in his health record. 3.2 Core functions overview This is an overview of the core functions which will be required by the Connector-API main functions. Apart of the functions listed below, there are more functions of the core platform which we will not take into account in this document. ID: Name: Description: FU-CORE-1 FU-CORE-2 FU-CORE-3 FU-CORE-4 ProvideAndRegister Document Set (See 3.3) RegisterDocumentSet (See 3.4) RegistryStoredQuery (See 3.5) RetrieveDocumentSet (See 3.6) This function must be used to store documents (e.g. laboratory or radiology reports, imagemanifest files) inside the esanté platform. This function is called by the Document Repository actor to register document metadata at the Document Registry. This function can be used to search for and retrieve metadata of document entries from the Document Registry. This function can be used to retrieve the documents from the repository. FU-CORE-5 FU-CORE-6 FU-CORE-7 RegisterNotification (See 3.7) UnregisterNotification (See 3.8) UpdateDocumentSet (See 3.9) This function can be used to register for notification events. This function could be used to unregister from the event notification. This function enables the possibility to update attributes of the metadata of entries in the Document Registry. At the following chapters we will describe the core platform functions listed above, in more detail. Cahier_des_charges_Technique_General_v1.0.docx13/158 Version 1.0,

14 3.3 FU-CORE-1: Provide and Register Document Set ID: FU-CORE-1 Name: ProvideAndRegisterDocumentSet References: Short Description: Actors ITI-41 (Provide and Register Document Set-b), RAD-68 (Provide and Register Imaging Document Set-b), ebxml SubmitObjectsRequest This function must be used to store documents (e.g. medical reports, labreports, radiology reports, image-manifest files) inside the esanté platform. The function is also used to submit addendum or replacements of documents. Data Provider, Document Repository Input: Output: Comment: XML Structure (based on ebxml) with elements: - Metadata for data provider description - Metadata for the submission (incl. References and folder definitions) - Metadata for each document - Documents to upload (e.g. reports, images, manifest-files) The operation of transmitting and storing the documents inside the esanté platform is atomic. If an error occurs which prevents the storage of a single document, the whole transaction must be cancelled. Success Failure The Data Provider will get a XML response which signals that the operation has succeeded The Data Provider will get a detailed error message in XML format Input and Output data are in XML format which is exactly defined by XSD files. Details about the structure, the possible data types and optional/mandatory elements are specified as part of the IHE radiology profile. Error or success response XML messages are defined in XSD schema files too. This function is derived from the ITI-41 and RAD-68 functions from IHE and combines their functionality, because they differ only slightly about the content types. Cahier_des_charges_Technique_General_v1.0.docx14/158 Version 1.0,

15 3.4 FU-CORE-2: Register Document Set ID: FU-CORE-2 Name: RegisterDocumentSet References: Short Description: Actors ITI-42 (Register Document Set - b), ebxml SubmitObjectsRequest This function is called between the two actors Document Registry and Document Repository during the execution of the Provide and Register Document Set ( 3.3) function. The aim is to register the metadata of the stored document. Document Registry, Document Repository Input: Output: Comment: XML Structure (based on ebxml) with elements: - Metadata about the data provider - Metadata for each document incl. the repository storage location - Metadata for the submission (incl. References and folder definitions) The transaction of storing the reference information inside the Document Registry is atomic. If an error occurs which prevents the system from storing this metadata, the whole transaction must be cancelled. Success Failure The caller will get a XML response which signals that the operation has succeeded The caller will get a detailed error message in XML format This function is used only inside the platform and is not accessible by thirdparty clients. The function call is embedded in the same transaction as the Provide and Register Document Set ( 3.3), so if an error occurs during the execution of this function, the whole transaction will fail. Cahier_des_charges_Technique_General_v1.0.docx15/158 Version 1.0,

16 3.5 FU-CORE-3: Registry Stored Query ID: FU-CORE-3 Name: RegistryStoredQuery References: Short Description: Actors ITI-18 (Registry stored query) This function can be used to search for and retrieve metadata of document entries from the Document Registry, to support the retrieval of the Documents from the Repository later on. Data Consumer, Document Registry Input: Output: Comment: XML Structure (based on ebxml) with elements: - Reference (UUID) to a pre-defined query which is stored inside the Registry - Values for the query parameters The result of a Registry Stored Query contains a result state and if no error occurs, a list of metadata from documents which are the result set of the query. Success Failure The call will get a XML response document with the results from the query. This result set could contain zero or more metadata elements. That means the function could have been processed successfully even if no result value was found. A failure message is returned if an error has occurred during this transaction. The error message is returned as part of the XML response, no possible search results are returned. The queries which could be called are pre-defined inside the Document Registry. This prevents the system from executing insecure, unknown or corrupt queries against the Registry to attack the system. Partial Success is another output state which is mentioned in the specs for the Stored Query Response. This response could return metadata and RegistryErrors which are classified as warnings or one severity error. This return state has to be discussed, maybe we should be more rigorous and just emit the success and failure return state. Cahier_des_charges_Technique_General_v1.0.docx16/158 Version 1.0,

17 3.6 FU-CORE-4: Retrieve Document Set Function for the retrieval of documents from the Document Repository. This does not cover the retrieval of imaging document sets for example for the radiology domain. For the radiology domain, the Document Repository could deliver the DICOM KOS manifest file for the Data Consumer, but to retrieve the high-res significant images the Image Data Consumer (a grouped Data Consumer) must implement this functionality e.g. to perform a WADO access. Those functions are not considered here. ID: FU-CORE-4 Name: RetrieveDocumentSet References: Short Description: Actors ITI-43 (Retrieve Document Set) This function can be used to retrieve the documents from the repository. Data Consumer, Document Repository Input: Output: Comment: XML Structure (based on ebxml) with elements (the data are part of the query result FU-CORE-3) : - One or more document request elements, each contains: o A reference to the repository (RepositoryUniqueID) where to retrieve the document from o A reference to a document (Unique identifier of the document) Additional payload could be necessary containing security related content (Public-Key Certificate) to ensure end-to-end security (see 8.5). As a result an ebxml structure is returned which contains sections for each document and document content which was requested. If one document could not be delivered an appropriate error message will be provided. Success Partial Success Error This state of the response is send to the client when all documents requested could be retrieved. If not all documents could be retrieved. The response message contains also warnings or error messages for the documents which could not be retrieved. If no documents could be retrieved. The appropriate error messages are part of the response too. Partial success is allowed when trying to retrieve documents from the Document Repository. Each Repository must record information about the successful request for the retrieval of documents by the Data Consumers. These information must be provided for the Registry to later-on allow queries about the consumers of the documents. Cahier_des_charges_Technique_General_v1.0.docx17/158 Version 1.0,

18 3.7 FU-CORE-5: Register Notification ID: FU-CORE-5 Name: RegisterNotification References: Short Description: Actors ITI-52 The caller (e.g. Data Consumer, Subscriber) can register himself to get notified about different events which occur at the Document Registry (e.g. new document registration, document state change,...) Data Consumer (Subscriber), Document Registry Input: Output: Comment: XML Structure (based on ebxml) with elements: - Subscriber identification - Address of the notification recipient/consumer where to emit the notification - Filter expression with different attributes to define for which notifications to be registered - Optionally a termination time, when the subscription should end The transaction result will be returned as an XML Structure (based on ebxml). Success Error The caller will get a response xml message which signals that the operation was successful, a unique subscription id which belongs to this subscription transaction will also be part of the response. The caller will get a detailed error message as XML response and the subscription transaction failed. At the esanté platform the Document Registry is the actor which is the source of events which belongs to changes of document metadata. After successful processing of this Register Notification transaction, the subscriber will receive a confirmation with a link inside. By following this link the subscriber is identified and accepted to receive the notifications at this address. Detailed specification of the workflow inside the Register Notification transaction will be described in the technical specification of the platform. Cahier_des_charges_Technique_General_v1.0.docx18/158 Version 1.0,

19 3.8 FU-CORE-6: Unregister Notification ID: FU-CORE-6 Name: UnregisterNotification References: Short Description: Actors Related to ITI-52 The caller wants no longer to be notified if certain events occur. Therefore the notification recipient will be unregistered. Data Consumer (Subscriber), Document Registry Input: Output: Comment: XML Structure (based on ebxml) with elements: - Identifier of this subscription - Subscriber identification (must match to the stored entry related to this subscription) The transaction result will be returned as an XML Structure (based on ebxml). Success Error The caller will get a response which signals that the operation has succeeded and no further event notifications will be sent to him. The caller will get a detailed error message, the transaction has failed and the subscription hasn t been cancelled. At the esanté platform the Document Registry is the actor which is the source of events which belongs to changes of document metadata. After successful processing of this Unregister Notification transaction, the subscriber will receive a confirmation with a link inside. By following this link the subscriber is identified and accepted to be deleted from the notifications list for this address. Detailed specification of the workflow inside the Unregister Notification transaction will be described in the technical specification of the platform. Cahier_des_charges_Technique_General_v1.0.docx19/158 Version 1.0,

20 3.9 FU-CORE-7: Update Documentset ID: FU-CORE-7 Name: UpdateDocumentSet References: Short Description: Actors Related to ITI-57 The caller (e.g. Data Provider) can update document metadata stored in the Document Registry, if he has the appropriate security rights. This function enables the possibility to update attributes for DocumentEntry and Folder objects, submit new Association objects and changes of the availabilitystatus for DocumentEntry, Folder and Association objects. Data Provider, Document Registry, Document Administrator Input: Output: Comment: XML Structure (based on ebxml) with elements: - Metadata for the submission containing information about the objects (DocumentEntries, Folders, Associations) and states which have to be changed The transaction of updating the information inside the Document Registry is atomic. If an error occurs which prevents the system from storing this meta changes, the whole transaction must be cancelled. Success Failure The caller will get a XML response which signals that the operation has succeeded The caller will get a detailed error message in XML format The underlying IHE transaction of the XDS Metadata Update profile introduces a new actor called Document Administrator which will be the actor which is able to invoke metadata update transactions. This actor should in our case be grouped with the Document Provider or Document Consumer dependent on the set of changes which would be allowed for these actors. The Update Documentset function will be used inside for example when calling the CancelDocument ( 5.4g) API function for changing the DocumentEntry.availabilityStatus to deprecated. Cahier_des_charges_Technique_General_v1.0.docx20/158 Version 1.0,

21 4 Connector-API and platform security requirements The security considerations and requirements introduced in this document are based on the work done in the esanté WP7 about the Architecture of the platform. This document describes those parts of the security concept which are required for the usage of the Connector-API, but does not describe the whole security concept of the platform as in WP7. Further changes and extensions cannot be avoided, especially in relation to a gradually realization of the esanté platform. Each system component of the core esanté platform and each instance of the Connector-API must have a validated certificate. This certificate will be used for the mutual certificate authentication and for the establishment of secure node to node communication, e.g. using HTTPS, between the communication peers of the platform, as defined also in the IHE ATNA 1 profile. So these certificates are mainly used to support the transport level security. The certificate of the Connector-API will also be used to sign the SubmissionSet before the transmission to the other platform servers. This provides the ability at platform level to check that the data which are submitted have not been changed on the way through the network and different servers. Medical documents e.g. laboratory or radiology reports as CDA R2 documents, which are created at Data Providers side, should be electronically signed by the Provider himself, using a wellknown and qualified certificate. If the document has a valid signature, the Connector-API could check the signature during the validation process and ensure that the document has not been illegally corrupted. This is the way we describe the process during our functional descriptions of this technical specification. Therefore we assume that the Data Provider s software will be able to create electronic signatures for documents. As long as this functionality is not provided by the third-party applications, an alternative way would be the creation of the electronic signature of the documents inside the Connector-API. Although this will not be a big challenge for the implementation of the Connector-API, it could have a recognizable impact on the non-repudiation of the validity of the document content. Because even if the transport level between the Data Provider s software and the Connector-API has been secured, there will be no possibility to check that the document hasn t been changed during the creation and the submission. Medical documents are stored encrypted at the esanté platform. The Connector-API covers that part of encryption of the documents. Therefore it requests a validated Public-Key Certificate from the TTP system component, which must be signed by using official certificates. The Public- Key part of the certificate will be used to encrypt the documents before they are submitted to the platform. First the documents will be symmetrically encrypted by the Connector-API and this symmetric key will then be encrypted with the public-key gathered from the TTP. If later-on a Data Consumer wants to retrieve a document, he should provide a Public-Key Certificate with the retrieve transaction. As long as the Data Consumer s third-party application is not capable of this, the Connector-API creates an ad-hoc Public-Key Certificate and provides this with the requestcall for the documents to the Repository. The platform core services use the functionality of the TTP to re-encrypt the symmetric key of the document encryption with the Public-Key of the Connector-API. The Connector-API, which is located as part of a software at Data Consumer s institution, will be able to decrypt the documents and provide it for the Data Consumer s application. If the Data Consumer s application itself has its own Public-Key Certificate created, 1 ATNA: Audit-Trail and node authentication Cahier_des_charges_Technique_General_v1.0.docx21/158 Version 1.0,

22 then the decrypt process will be part of the Data Consumer s application. This re-keying and the encryption/decryption using ad-hoc generated Public/Private Keypairs, allows the usage of an Signature PKI for the secure exchange of the documents, as described in the platform architecture document (WP7). Two main types of consent are checked during the processing of the transactions. For XDS transactions first the patient s consent for sharing documents using the electronic health record is checked. If the patient hasn t given his consent for that, his documents could only be transmitted using XDR reliable transmission. The second type of consent checks the access rights of users for stored objects (e.g. documents, folders, ) at the platform. Therefore during the transaction processing the platform-services calls the checkaccessconsent function to perform the necessary access security checks. Cahier_des_charges_Technique_General_v1.0.docx22/158 Version 1.0,

23 5 Connector-API functional level specification In this chapter we will describe on a technical level the functionality which was introduced as part of the Cahier de charges fonctionnel. We describe the functions of the outer interface (as Connector-API functions), which could be used/called by third-party applications by hospitals or patient management systems of doctors. 5.1 Data types In the description of the main functions for the interface we reference different data types which we will now describe in detail. Typename Fields (if record type) Description ConsumerRec e.g. Data Consumer identification InstitutionID Name and surname CNS-number (UCM code, or a new health-professionalid which will be defined on national level) Matricule (e.g. citizen id) 2 Medical specialty Address (opt.) Date -- Date in format YYYYMMDD DocumentRef -- Reference to the document e.g. a local file URL from where the document could be retrieved. PatientRec ProviderRec e.g. LocalPatientID Surname Lastname Birthdate Matricule (e.g. citizen id) SSN (social security number) Address (opt.)... e.g. InstitutionID Name and surname Individual CNS-number for healthcare professionals(formerly UCM code) Or another health professional ID (not yet defined) Record-type contains field-set with demographic data to identify the patient. This will be needed during the de-identification process with the TTP. Provider identification 2 Or if available an other national unique individual identifier or Patient Identifier List as defined in HL7 Cahier_des_charges_Technique_General_v1.0.docx23/158 Version 1.0,

24 Matricule (to decide) ID number for institution (to confirm how this point will be handled: CNS number by service, OID,.) Medical specialty Address (opt.) QryParamList -- List of key/value pairs which is used to set the parameters for a registry stored query RecipientRec Unique recipient identifying address related to User of the system Recipient record for identification of the intended recipients for the XDR transmission. String -- Set of characters, supported characterset UTF-8/16 UNIQUEID -- String based type which could contain OID as unique identifier (see 5.3f) UUID -- Globally unique identifier conformant to RFC4122 e.g. urn:uuid:10b545ea- 725c-446d-9b95-8aeb444eddf3 Cahier_des_charges_Technique_General_v1.0.docx24/158 Version 1.0,

25 5.2 Exceptions During the processing of the functions e.g. during the validation process of parameters, some exceptions could occur. In this table we list the main important exceptions which could occur. Other exceptions, e.g. runtime exceptions which could occur during the connection establishment are not listed here. The table below shows the different kinds of exceptions that could be raised, each Exception when thrown by the application should contain more detailed information about the cause. Exception Description CertificateException Could occur if a Certificate could not be retrieved or if the Certificate retrieved is not valid due to invalid formats, invalidation or revocation. The message part of this exception will contain the detailed cause. CreateKeyPairException Could occur if the Connector-API is not able to create a publicprivate keypair out of several reasons. Details will be described in the message part of the exception. CreateSignatureException Could occur if problems arise during the creation of an electronic signature e.g. when signing a SubmissionSet. CreateQueryXmlException This Exception could occur during the creation of the XML structure for querying the Document Registry. CreateRetrievalXmlException This Exception could occur during the creation of the XML structure for the retrieval of documents from the Document Repository. CreateSubmissionsetException Could occur during the creation of the SubmissionSet, when creating the ebxml structure. DecryptionException Could occur during the decryption of the documents (report, manifest files) which should be provided for the Document Consumer. EncryptionException Could occur during the encryption of the documents (report, manifest files) which should be provided for the intended recipients or shared using the platform. FolderNotFoundException Occurs if a folder which was requested could not be found, e.g. when searching for a users InBox folder. InvalidIdentifierException Could occur if the format of an unique identifier for the UNIQUEID datatype is not valid. IdentityMatchException Could occur if a patient identification could not be matched to a pseudonym, the reason e.g. inadequate demographic data, must be described as part of the exception message. InvalidLengthException Could occur during the validation of character datatypes like string, before the persistent storage of the value inside a database field. InvalidSignatureException Is raised if the signature isn t valid, out of different reasons e.g. Certificate was revoked already. InvalidURLException Is raised when a given URL is not valid and the file linked to this URL couldn t be retrieved. InvalidUuidExeption Is raised if a given Uuid is not valid or in an unexpected format. Cahier_des_charges_Technique_General_v1.0.docx25/158 Version 1.0,

26 NoConsentException NoSignatureFoundException ParameterBindingException ParameterException PatientIdentException UnknownConsumerException UnknownProviderException UnknownRecipientException UnresolvedUuidException Could occur if an access to patient related data or the access to a patient shared health record is not allowed out of missing patient consent. Also if a patient hasn t given his/her consent for sharing his medical data using an electronic health record. The exception must contain the detailed exception reason as message. Is raised if the CDA R2 document doesn t contain or reference a digital signature. Could occur if expected/mandatory parameters could not be bound to the registry stored query e.g. when a mandatory parameter is missing or has a wrong type. Could occur if expected/mandatory parameters could not be retrieved / extracted e.g. when parameters should be read from CDA R2 Header. Could occur if the patient identification could not be processed by using the given parameters for the PatientRec type. Also if a patient s identity could not be determined when calling the Patient Register. Could occur if the consumer information as value of a ConsumerRec is not known or doesn t correspond to the caller of the function. Could occur if the provider information as value of a ProviderRec is not known or doesn t correspond to the caller of the function. Could occur if an intended recipient for a reliable transmission is not known or identifiable. Exception message contains details, e.g. the recipients which could not be determined. Could occur if the Document Registry/Document Repository is not able to locate a DocumentEntry/SubmissionSet or Association with the given UUID. Beside of the Exceptions listed above, several other Errors could occur during the processing of the transactions. Some of them are specified and could be found as part of the IHE specification of the IHE IT Infrastructure (ITI) Technical Framework Volume I-III. The description of all the detailed error messages emitted by the different components of the system will be listed as part of the specifications of the system components 3. 3 This will be part of the Workpackages for the esanté 2 project Cahier_des_charges_Technique_General_v1.0.docx26/158 Version 1.0,

27 5.3 Document formats and requirements When sharing documents with the esanté platform some requirements are necessary for the file formats and the metadata which should be provided. For example laboratory- and radiology reports should be provided as CDA R2 documents, references for the high-resolution significant images should be included as part of a DICOM KOS manifest file. The submission transactions of the platform e.g. the Provide and Register Document Set (See FU-CORE-1) transaction require metadata which must be provided by the Connector-API. The Connector-API could get this metadata by parameters of the functions, by extracting from the documents or by configuration of the Connector-API runtime. The set of metadata attributes which are defined in the specifications of IHE XDS.b and XDS-I.b do not let much space for custom extensions out of interoperability reasons, although the underlying ebxml standard is capable of dealing with custom metadata extensions. This must be considered e.g. when we try to distinguish between XDS and XDR transmission on the level of the core platform functions or when we try to implement the blocking/unblocking-mechanism with unblocking code for document access. We will start with a description of the required attributes which are part of the XDSSubmissionSet and the XDSDocumentEntrySet needed by the platform core functions. After that we describe the requirements about the file formats and which data could be extracted to provide values for the required attributes. 5.3a XDSSubmissionSet Attributes In the following list we introduce the subset of the attributes for the XDSSubmissionSet metadata which are necessary for the communication with the esanté platform 4. Values for this attributes must be provided when the XDSSubmissionSet is used with the esanté platform transaction. When a Data Provider directly accesses the esanté platform functions, these parameters have to be provided by the Data Provider. By using the Connector-API functions, the connector is responsible to provide or extract the missing parameter values out of the CDA document header (see 5.3c). Attributename Occurance Valuetype Description author Required if known Structure with strings for authorperson, authorinstitution, authorrole, authorspeciality contenttypecode Required Code as a string. The set of codes must belong to a vocabulary defined for this Affinity Domain. contenttypecode displayname Required Human-readable string representation of contenttypecode, from a Should contain information about the institution and the initiator of this transaction. Code to specify the type of clinical activity that resulted for the creation of this SubmissionSet. Human-readable name for the contenttypecode, 4 The complete list of submission set metadata attributes is specified in Chapter 4.1 of the IHE Technical Framework Volume 3 (ITI TF- 3) Cahier_des_charges_Technique_General_v1.0.docx27/158 Version 1.0,

28 vocabulary defined for this Affinity Domain. which could be used to display in applications. entryuuid 5 Required UUID Intended to use as a Document Registry management identifier. This identifier has to be provided by the DataProvider but should not be used as an external reference outside of the Registry. intendedrecipient Optional Value list with strings to address the recipients. The identification of the recipients could be realized dependent on the rules of the Affinity Domain. 6 This parameter contains the list of the recipients in case of an XDR transmission. patientid Required String The patient identifier which uniquely identifies the patient. 7 All new documents or associations used inside this SubmissionSet must be related to this patient. sourceid Required OID In terms of XDS this parameter should be used to store an identifier for a Document Source instance. 8 submissiontime Required HL7 V2 Date Time type. Time must be given for Coordinated Universal Time (UTC) 9. Format regular expression: YYYY[MM[DD[hh[mm[ss]]]]] Creation time of this SubmissionSet for registration with the Document Registry. uniqueid Required OID Globally unique identifier for this SubmissionSet instance. 5 See chapter 5.3e for more details 6 Instead of using strings containing institution name and oid together with name, lastname and title of the receiver (person) as suggested by IHE, for the esanté platform maybe other unique addresses could be used to identify intended recipients, e.g. using an -address pattern 7 This patient identifier should be the unique patient identifier of this Affinity Domain. In case of the planned esanté platform this parameter should contain the messageid which was determined after the De-Identification process with the TTP. This identifier will then be used by the Registry to determine the associated pseudonym which is related to the patient and the given messageid. The messageid should be formatted with the patientid layout as described by the IHE recommendation for this patientid parameter. 8 When using a Gateway/Connector for the communication with the esanté platform, the Connector could provide the different oid s as identifiers for the different Document Sources. 9 This implies that Data Providers have to convert their local time to the UTC time before placing inside the SubmissionSet as well as Data Consumers have to convert the UTC time from the platform to their local timezone. Cahier_des_charges_Technique_General_v1.0.docx28/158 Version 1.0,

29 5.3b XDSDocumentEntry Attributes In the following list we introduce the subset of the required attributes for the XDSDocumentEntry metadata set which are necessary for the communication with the esanté platform 10. When a Data Provider directly accesses the esanté platform functions, these parameters have to be provided by the Data Provider. By using the Connector-API functions, the connector extracts the missing parameter values out of the CDA R2 Header (see 5.3c). Attributename Occurance Valuetype Description author Required if known Structure with strings for authorperson, authorinstitution, authorrole, authorspeciality classcode Required Code as a string. The set of codes must belong to a vocabulary defined for this Affinity Domain. classcodedisplayname Required Human-readable string representation of classcode, from a vocabulary defined for this Affinity Domain. confidentialitycode Required Code as a string. The set of valid codes must be defined for this Affinity Domain. creationtime Required HL7 V2 Date Time type. Time must be given for Coordinated Universal Time (UTC). Format regular expression: Should contain information about the institution and the author of this document. Code to specify the particular kind of document (e.g. Report, Prescription) Human-readable name for the classcode, which could be used to display in applications. Specifying the level of confidentiality for this document. Creation time of the document. YYYY[MM[DD[hh[mm[ss]]]]] entryuuid 11 Required UUID Intended to use as a Document Registry management identifier. This identifier has to be provided by the DataProvider but should not be used as an external reference outside of the Registry. formatcode Required Code as a string. Valid codes could be used or Describes the format of the document so 10 The complete list of document entry set metadata attributes is specified in Chapter 4.1 of the IHE Technical Framework Volume 3 (ITI TF-3) 11 See chapter 5.3e for more details Cahier_des_charges_Technique_General_v1.0.docx29/158 Version 1.0,

30 those defined for this Affinity Domain. formatcodedisplayname Required Human-readable string representation of formatcode. healthcarefacilitytypecode Required Code as a string. Valid codes must be used defined for this Affinity Domain. healthcarefacilitytypecode DisplayName Required Human-readable string representation of healthcarefacilitytypecode from a vocabulary defined for this Affinity Domain. languagecode Required Code as string, in format nn-cc where nn is the language code based on ISO-639-1, CC is the uppercase country-code based on ISO mimetype Required As string a official MIME - type (IANA mime-type definition) that Data Consumers are able to validate if they are able to process the document (e.g. value="cdar2/ihe 1.0") Human-readable name for the formatcode, which could be used to display in applications. This code represents the type of organizational setting of the institution where the document was created (e.g. surgery, hospital,...) Human-readable name for the healthcarefacilityty pecode, which could be used to display in applications. The language of the document. MIME type of the document e.g. for CDA documents usually text/xml. patientid Required String The patient identifier which uniquely identifies the patient. 12 practicesettingcode Required Code as a string. Valid codes must be used defined for this Affinity Domain. To define more precise the clinical speciality from which the document was created (e.g. Laboratory or 12 This patient identifier should be the unique patient identifier of this Affinity Domain. In case of the planned esanté platform this parameter should contain the messageid which was determined after the De-Identification process with the TTP. This identifier will then be used by the Registry to determine the associated pseudonym which is related to the patient and the given messageid. The messageid should be formatted with the patientid layout as described by the IHE recommendation for this patientid parameter. Cahier_des_charges_Technique_General_v1.0.docx30/158 Version 1.0,

31 practicesettingcode DisplayName Required Human-readable string representation of practicesettingcode, defined for this Affinity Domain. sourcepatientid Required String containing Authority Domain Id and patient identifier of the domain typecode Required Code as a string. Valid codes must be used defined for this Affinity Domain. typecodedisplayname Required Human-readable string representation of typecode, defined for this Affinity Domain. uniqueid Required String with maxlength of 128 chars, structure and format must be consistent with the format attribute. 16 parentdocumentrelationship parentdocumentid Required (when present) Required (when parentdocu mentrelati onship is present) Possible values are APND (append), RPLC (replace), XFRM (transform) String as document identifier Radiology department) 13 Human-readable name for the practicesettingcode, which could be used to display in applications. In terms of XDS this parameter should be used to transmit the value for the local patientid of the Data Provider. 14 Specifies the precise kind of document (e.g. Radiology- Report, Lab- Report,..) 15 Human-readable name for the typecode, which could be used to display in applications. Globally unique identifier for this Document instance assigned by the Data Provider. Represents the source of a append, transformed or replacement document Represents the documentid of the parent document 13 The values for practicesettingcode could correspond to the possible values of authorspeciality. Since the possible values have to be defined, the granularity 14 This patient identifier should be the unique patient identifier from the system of the Data Provider. Out of security reasons this identifier should not be stored as Parameter in the Registry. Therefore the Connector-API will not transfer this parameter or set it to a constant value which does not relate to a patients identity. 15 Range of values have to be defined for the Affinity Domain, attribute is used for query, search and sort operations. This typecode should be a derived type from classcode and be more detailed. 16 The format of the uniqueid depends on the format of the document which is described by the DocumentEntry metadata. For example oid or oid^extension for DICOM-SR transformations, for DICOM manifest documents the uniqueid shall be the same as the SOP Instance UID of the corresponding DICOM KOS object. Cahier_des_charges_Technique_General_v1.0.docx31/158 Version 1.0,

32 The parentdocumentrelationship and the parentdocumentid are two fields which could be used to express relationships between the documents. The different relationship types (append, replace, transform) correspond to the relationship types used for IHE document associations. Although the types are the same, there is an important difference between the usage of relationships as metadata of the document (which are based on CDA document relationships, mentioned later) and the relationships expressed by using IHE XDS associations. Relationships expressed on document level (DocumentEntry - metadata) could use reference identifiers which are not limited for the usage in this Affinity Domain. Instead for associations at Document Registry side (XDS associations), the entryuuid must be used to link documents together, which should be treated as Document Registry internal management parameters. The vocabularies for the different type- and class codes are not defined yet and not part of this workpackage. Cahier_des_charges_Technique_General_v1.0.docx32/158 Version 1.0,

33 5.3c XDS metadata and CDA R2 document header element mapping The CDA R2 content templates for laboratory- or radiology reports for the esanté platform are not defined finally at the time of the writing of this document. Nevertheless the mandatory fields which must be part of the CDA-Header of the documents will be introduced now, as they are required for using the functionality of the platform. The Connector-API should extract these values during the processing of the transactions before sharing the documents and use the values for the metadata of the XDSDocumentEntry and XDSSubmissionSet attributes. The parameter definition is based on the specification of the HL7 CDA R2 document format. XDS metadata attributes CDA Header Element 17 Comment languagecode ClinicalDocument/languageCode Describe the language of the report in nn-cc format, where the nn part is the two letter language code based on ISO-639-1, CC is the uppercase countrycode based on ISO classcode CDA-Header attribute should be mapped based on the platforms coding system to a valid classcode. classcodedisplayname ClinicalDocument/code/@code CDA-Header element should be mapped based on the platforms coding system to a valid classcodedisplayname. typecode ClinicalDocument/code/@code CDA- Header element should be mapped based on the platforms coding system to a valid typecode. 18 typecodedisplayname confidentialitycode ClinicalDocument/code/@display Name ClinicalDocument/ confidentialitycode/@code 19 CDA- Header element should be used as value for the typecodedisplayname CDA- Header element should be mapped based on the platforms coding system to a valid confidentialitycode. creationtime ClinicalDocument/effectiveTime CreationTime of the document as XDS attribute must be in UTC time, so if CDA-Header field effectivetime contains time with timezone offset, the UTC time must be calculated. 17 CDA-Header elements are listed here in a kind of XQuery Notation, where sub-branches (elements) are separated by a slash (/) and attributes are marked with the at-symbol (@). To use it as an XQuery attribute a preceding slash must be added e.g. /ClinicalDocument/languageCode 18 The mapping of the CDA-Header ClincalDocument/code/@code Attribute to the XDS metadata attributes classcode, typecode could be hard to distinguish. 19 In case of using IHE-BPPC profile another mapping could also be used based on /ClinicalDocument/authorization Cahier_des_charges_Technique_General_v1.0.docx33/158 Version 1.0,

34 patientid sourcepatientid ClinicalDocument/recordTarget/ patientrole/id ClinicalDocument/recordTarget/ patientrole/id Could directly be used if Data Provider uses Affinity Domains patientid for the creation of the CDA-Header field. Otherwise the CDA s patientid must be mapped to the platforms patientid. PatientID of the Data Providers system (source system) uniqueid ClinicalDocument/id UniqueId could be created based on id from the CDA document (e.g. sion) 20 author ClinicalDocument/author Values for the author structure containing authorinstitution, authorperson, authorrole,... could be extracted from the ClinicalDocument/author sub-elements and attributes parentdocumentrelati onship parentdocumentid ClinicalDocument/relatedDocum ent/@typecode ClinicalDocument/ relateddocument/parentdocume nt/id If this optional parameter is given inside the CDA, this value could be extracted to put in the value inside the XDS DocumentEntry metadata If this optional parameter is given inside the CDA, this value could be extracted to put in the value inside the XDS DocumentEntry metadata. A value must exist if parentdocumentrelationship is defined When Data Providers already use the Affinity Domains codification system (e.g. for code, typecode) during the creation of the CDA document, no further mapping has to be done when extracting the data for the XDS SubmissionSet or DocumentEntrySet. Some of the required attributes listed in the chapters 5.3a and 5.3b are not part of the CDA- Header and therefore could not be extracted from it. The Connector-API functions must be able to create the appropriate values based on type definitions of the Affinity Domain and provide them for the Submission-Set. Although the CDA-Header is capable of providing information about informationrecipient which is used to represent recipients which should receive a copy of the document, we would prefer for XDR the usage of a function parameter recipients which should contain the intended recipients, 20 For example in DICOM-SR Cahier_des_charges_Technique_General_v1.0.docx34/158 Version 1.0,

35 as defined in the SubmitDocumentsXDR (see 5.4c) transaction. The informationrecipient parameter of the CDA-Header is intended for the definition of persons which should become a copy of the document at the time of the document authorship. 5.3d Platform document states and transitions Patient access blocking of documents offers the capability for healthcare professionals to exclude the patient from accessing and reading the document until he went to his doctor. This is a functionality which is described in the Use-Cases and the functional specification. The implementation on technical level for marking the document as blocked is not as obvious as it should. The XDSDocumentEntrySet has a defined set of attributes which must be used and doesn t define the possibility to easily add new custom based attributes e.g. for blocking. So therefore a special value for the confidentialitycode attribute could be defined, which signs that this document shouldn t be opened by the patient himself, until a health professional has changed the confidentialitycode to a level where the patient has access to. If no health professional has changed the confidentialitycode after a certain amount of time since the documents were present on the esanté platform, the patient could be allowed to change the confidentialitycode by himself. Although the confidentialitycode could be used to block/unblock the access to the documents, it differs from the description of the Use-Cases and functional specification which describe the Data Providers interface to the Connector-API. The Connector-API could internally use the confidentialitycode as metadata when sharing the document at the platform, but provide the functional parameter patientreadblocking as a simpler interface for Data Providers. Storing the unblocking code inside the CDA-R2 document could only be used by the Data Provider or the Connector-API and the Data Consumer, because the document is stored encrypted at the platform. Storing the unblocking code as part of the metadata of the XDSDocumentEntry of the document will lead to an enhancement of the document s metadata which is not forseen in IHE. The process of unblocking a document, which could be initiated by a Data Consumer will be described as a separate transaction (see 5.4r). If documents contain a patientreadblocking flag as part of their metadata (e.g. CDA-Header), as an additional option to the parameter of the document submit functions, the following rules apply: patientreadblocking function patientreadblocking Result parameter document header true true Document access will be blocked for the patient true false Document access will be blocked for the patient false true Document access will not be blocked false false Document access will not be blocked In cases where the document or the document header doesn t contain metadata fields about the patient-read blocking, the parameter values which are provided during the function call have to be used. In cases where the document contains this flag, the values are superseded by the value of the patientreadblocking function parameter. Alternatively if a certain value for patient-read blocking will be used for the parameter confidentialitycode, which could be part of the CDA R2 header instead of introducing an additional new header element, the following rules will apply: Cahier_des_charges_Technique_General_v1.0.docx35/158 Version 1.0,

36 patientreadblocking confidentialitycode Result function parameter header parameter true >= patientreadblocking Document access will be blocked for the patient true < patientreadblocking Document access will be blocked for the patient false >= patientreadblocking Document access will not be blocked false < patientreadblocking Document access will not be blocked In the second matrix we will look at the different states about the unblocking-codes, we presume that patientreadblocking is true: unblockingcode function unblockingcode from Result parameter document set set Both codes must be identical, this must be checked during the validation. If the codes are not equal, an exception will be thrown set not set The unblocking code from the function parameter will be used not set set The unblocking code from the document will be used not set not set No unblocking code, the document could only be unblocked by the health professional In cases where the patientreadblocking parameter is set to true and no unblocking code is given, the document could only be unblocked by an healthcare provider e.g. the reference doctor of the patient. 5.3e Requirements for the usage of the entryuuid parameter as a transactionid As shown in chapters 5.3a and 5.3b which define the XDSSubmissionSet and the XDSDocumentEntry structure parameter which are required for the platform, the entryuuid parameter is an important parameter for uniquely identifying instances of this types (submissionsets or documents). Concerning the assignments for the entryuuid, the IHE XDS specification defines a cascading responsibility for supplying these parameters (for submissionsets and documents), because they allow the provision of the UUID by the different actors Data Provider, Document Repository and Document Registry. Therefore the following rules apply: - If the DataProvider creates and assigns the entryuuid value as an UUID, this UUID must be used by the Repository and Registry when storing the document. Cahier_des_charges_Technique_General_v1.0.docx36/158 Version 1.0,

37 - If the Document Repository creates and assigns the UUID, this must than also be used by the Document Registry. So in both cases if the Document Registry receives a UUID as entryuuid, it must be used. Normally entryuuid s are not superseded, the only exception is if the Document Registry gets an symbolic identifier (not a UUID) as value for the entryuuid, than the Document Registry has to generate an UUID for the entryuuid itself. This leads to the following conclusion concerning our specification, which is based on IHE XDS: - The DataProvider must provide a transactionid as part of each function call of the Connector-API. This transactionid as an UUID value will then be mapped to the entryuuid of the XDSSubmissionSet which will be generated and provided by the Connector-API. The Data Provider could store this transactionid and maybe use it later on for queries about the submissionset. - The entryuuid s for the documents will be generated by the Connector-API. The entryuuid for documents, generated by the Connector-API, will also be used during the creation of associations e.g. for document addendum and replacement. The association objects refer source- and target objects by using the entryuuid (UUID). If a Data Provider is directly connected to the esanté platform without using the Connector-API, he could create the entryuuid also. 5.3f Unique document identifiers The UNIQUEID datatype specified in 5.1 should be used to uniquely identify documents from Data Consumer s and Data Provider s point of view. This uniqueid, if generated and stored at Data Provider s side, could later-on be used to reference the parent document for replacement or addendum. Otherwise a query must be executed to retrieve the entryuuid or uniqueid of the document. The UNIQUEID datatype can contain the value of the ClinicalDocument/id@root attribute of the CDA document, if an extension is given (e.g. ClinicalDocument/id@extension) it should be included using the ^ operator. For example: <id root= extension= 0001 > => uniqueid = ^0001 For DICOM KOS object manifest files the value of the SOP instance UID should be used as uniqueid for the identification of the document. Cahier_des_charges_Technique_General_v1.0.docx37/158 Version 1.0,

38 5.4 General Connector-API interface In this chapter we describe the main functions of the Connector-API. They could be logically divided into two categories, the Data Provider- and Data Consumer related functions. These functions are exposed and are adapter functions which call the core platform functions described in the chapter before. Audit-Trail messages which are generated during the transaction processing will not be described in this functional specification, because they belong to the platform specific functional behavior. 5.4a Connector-API functions overview ID: Name: Description: FU-CON-1 FU-CON-2 FU-CON-3 FU-CON-4 FU-CON-5 FU-CON-6 SubmitDocumentsXDR (See 5.4c) SubmitDocumentsXDS (See 5.4d) SubmitAddendumXDR (See 5.4e 3.5) SubmitAddendumXDS (See 5.4f) CancelDocument (See 5.4g) ReplaceDocumentXDR (See 5.4h) The caller (Data Provider) provides documents for known recipients (Data Consumer). This function implements the reliable data transmission. Documents which are successfully submitted will be listed in the InBox folder of the recipients. The caller (Data Provider) provides documents which should be stored and linked to the patient s electronic health record. The caller (Data Provider) provides addendum documents for known recipients (Data Consumer). This function could be used to add one Addendum Report to an already existing report, possibly with none or some image manifest files. The caller (Data Provider) provides documents which should be stored and linked to an already existing document of the patient s electronic health record. This function will be used for the cancellation of documents which are shared using XDR or XDS. Cancelling of documents on the platform changes the document state from Approved to Deprecated, so that the document is unavailable for viewing by normal data consumers. The caller (Data Provider) provides a replacement document for known recipients (Data Consumer). This function could be used to replace an already existing document by a new document. Cahier_des_charges_Technique_General_v1.0.docx38/158 Version 1.0,

39 FU-CON-7 FU-CON-8 ReplaceDocumentXDS (See 5.4i) QueryDocumentsXDR (See 5.4k) The caller (Data Provider) provides a document which should be stored and replace an already existing document of the patient s electronic health record. This function will be used to query for the list of document - metadata which are available at the InBox folder of the Data Consumer. The list contains metadata about all documents with status Approved and which haven t been downloaded/viewed by this Data Consumer yet. FU-CON-9 FU-CON-10 FU-CON-11 FU-CON-12 FU-CON-13 FU-CON-14 FU-CON-15 FU-CON-16 QueryDocumentsXDS (See 5.4l) RetrieveDocumentsXDR (See 5.4m) RetrieveDocumentsXDS (See 5.4n) SubmitReferralXDS (See 5.4o) QueryReferralXDS (See 5.4p) QueryDocumentReaders (See 5.4q) UnblockDocuments (See 5.4r) QueryProvidedDocuments (See 5.4s) This function will be used to query for the list of document s metadata which are part of a patients shared electronic health record. The list contains metadata about all documents with status Approved. This function will be used to retrieve documents which are available at the InBox folder of the Data Consumer. Only documents with status Approved and which haven t been downloaded/viewed are available. This function will be used to retrieve documents from a patient s shared electronic health record. The caller (Data Provider) provides a referral document for a patient which should be stored together with references to other documents which are associated with this referral case. These documents are linked to a new folder for this referral, inside the patient s electronic health record. This function will be used to query for documents of a patient related referral folder. This function will be used to query for the list of recipients or Data Consumers (aka. document readers) which have already downloaded/read a document. This function will be used to unblock already blocked documents for patient s access at platform level. This function will be used to query for the list of documents provided by one Data Provider. Cahier_des_charges_Technique_General_v1.0.docx39/158 Version 1.0,

40 5.4b Connector-API functions detailed description The following template will be used to describe the different functions. Each functional description will be followed by a sequence diagram, which shows the interactions between the system components. ID: FU-CON-X Name of the function Short Description: A one or two phrase summary description of the function Actors/Category: System component: Trigger event: Preconditions: Input Parameters: Validation: Id of the Actor Category where the function belongs to e.g. Data Provider layer or Data Consumer layer function Name of the system component which provides this functionality An event which is the cause of this function call A list of conditions which must be fulfilled in order to call this function. If these preconditions are not met, the function could not be used. A list of input parameters of the function, with name, type, cardinality and description. A list of parameter validations which have to be done. Each line of the list defines a unique ID for a validation belonging to this function. The validations themselves and the possible occurring exceptions are described. Processing: The rows and columns of this sub-table describe the whole steps of the transaction/workflow processing. These steps are visually reflected in the sequence diagram following each functional description. Only Connector-API functions/function calls are described, core platform function calls could be present in the sequence diagram but not described here in detail. PX Name of the processing step or function call Detailed description of this processing step, including a ID which corresponds to the number of the function inside of the sequence diagram and possible exceptions which could occur. Postconditions: Declaration of the properties which are guaranteed upon completion of the routine's execution. The postcondition defines that in cases in which the function is called, in a state in which its precondition holds, the properties declared by the postcondition are assured. Output Parameter: Comments: The output parameters of the function, with name, type, cardinality and description. Additional comments and remarks concerning the transaction Cahier_des_charges_Technique_General_v1.0.docx40/158 Version 1.0,

41 5.4c FU-CON-1: SubmitDocumentsXDR ID: FU-CON-1 Name: SubmitDocumentsXDR Short Description: The caller (Data Provider) provides documents for known recipients (Data Consumer). This function implements the reliable data transmission. Documents which are successfully submitted will be listed in the InBox folder of the recipients. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Provider creates CDA R2 documents as medical reports. These medical reports should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction recipients RecipientRec 1 or n Intended recipients identification provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction 21 comment String 0 or 1 Additional description text documents DocumentRef 1 or n Documents which should be submitted Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter recipients must contain valid and known recipients. UnknownRecipientException 21 The title attribute as the comment attribute too, describe the transaction itself. Documents themselves can provide their own title and comment attribute as part of the HL7 CDA R2 header (see the chapter 5.3 in this document) Cahier_des_charges_Technique_General_v1.0.docx41/158 Version 1.0,

42 V3 V4 V5 V6 V7 If one of the recipients could not be identified, an Exception is thrown. Parameter provider must link to a valid registered provider Parameter title must be a valid string and must not be larger than the defined number of chars for this field Parameter comment must be a valid string and must not be larger than the defined number of chars for this field Parameter documents must contain references to valid documents in HL7-CDA R2 format, providing the mandatory fields described in 5.3c Validate the electronic signature. The documents should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. 22 Signature related data must be compliant to the Data Providers identity. Processing: See also Sequence Diagram for SubmitDocumentsXDR UnknownProviderException InvalidLengthException InvalidLengthException Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and content. NoSignatureFoundException InvalidSignatureException P1 submitdocumentsxdr 1 Function called by Data Provider to share documents with the intended recipients. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters including the files (e.g. medical reports) must be checked for consistency. Electronic signature of the medical report will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 ParameterException Header of the reports are extracted for 22 Qualified digital signature must contain a signed timestamp from a timestamp service, maybe provided by a Trustcenter. Cahier_des_charges_Technique_General_v1.0.docx42/158 Version 1.0,

43 P4 further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid. getpublickeycertificate 1.3 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. P5 encryptdocuments 1.4 The documents are encrypted before they can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P6 createsubmissionset 1.5 Creates and prepares the XML based representation of the metadata and embeds the documents for transmission to the platform. A unique identifier must be created for each embedded document. The value of the parameter transactionid has to be used as unique identifier for the transaction, the values of the parameter recipients have to be placed as value of the intendedrecipient field of the submissionset metadata. CreateSubmissionsetException P7 signsubmissionset 1.6 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P8 provideandregisterdocumentset 1.7 This is the transaction which must be used to During the execution of the platform Cahier_des_charges_Technique_General_v1.0.docx43/158 Version 1.0,

44 transfer the documents from the local institution/health professionals to the intended recipients. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentset Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 submitdocumentsxdr Response: If the transaction succeeds the success - state and possibly a list of warnings will be send back. transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). Postconditions: Output Parameter: Comments: The operation of transmitting and storing the documents for the intended recipients is atomic. If an error occurs which prevents the delivery of a single document, the whole transaction will be cancelled. success failure The documents are provided for the intended recipients successfully. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the provision of the documents. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Notification of the recipients who have subscribed to be noticed about the arrival of new reports is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. Like , the documents are provided in the InBox-Folder for the selected Data Consumers. So far, there are no restrictions foreseen about who could send a message/document to whom. An enhancement would be to allow the Data Consumer to set restrictions on his InBox- Folder. Cahier_des_charges_Technique_General_v1.0.docx44/158 Version 1.0,

45 Sequence Diagram for SubmitDocumentsXDR The main platform scenario for the usage of the function will be shown as part of the sequence diagram below. Cahier_des_charges_Technique_General_v1.0.docx45/158 Version 1.0,

46 5.4d FU-CON-2: SubmitDocumentsXDS ID: FU-CON-2 Name: SubmitDocumentsXDS Short Description: The caller (Data Provider) provides documents which should be stored and linked to the patient s electronic health record. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. The Data Provider creates CDA R2 documents/reports. The medical report should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction patient PatientRec 1 Patient s demographic data provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction comment String 0 or 1 Additional description text documents DocumentRef 1 or n Document e.g. medical report patientreadblocking Boolean 0 or 1 True/False - Flag to sign that the document could not be read by the patient 23. unblockingcode String 0 or 1 Parameter may be used if patientreadblocki ng = True. The patient could use the unblocking 23 Default value is: False, so the patients access to the documents is not blocked by default. Cahier_des_charges_Technique_General_v1.0.docx46/158 Version 1.0,

47 code to get access to the document 24. Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V5 Parameter comment must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field. V6 Parameter documents must contain a reference to valid documents in HL7-CDA R2 format, providing the mandatory fields described in 5.3c V7 V8 V9 Parameter patientreadblocking, if set must be a valid Boolean (True/False) value. Parameter unblockingcode, should be could be provided if patientreadblocking is set. String must not be larger than the defined number of chars for this field. Validate the electronic signature. The documents should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. Processing: See also Sequence Diagram for SubmitDocumentsXDS P1 submitdocumentsxds Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and content. InvalidLengthException NoSignatureFoundException InvalidSignatureException 24 There could be situations where the patientreadblocking Flag is set and no unblockingcode was given. In those situations only a healthcare provider which has access to the document e.g. the general practitioner, could unblock the document for the patient. Cahier_des_charges_Technique_General_v1.0.docx47/158 Version 1.0,

48 1 Function called by Data Provider to share documents using the esanté platform. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters including the files must be checked for consistency. Electronic signature of the medical reports will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 Header of the reports are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid, Patient related data must be compliant to the data in the patient Parameter from the PatientRec. If the metadata of the documents contain information about patientreadblocking or unblockingcode, then this values must be validated as described in the matrix at chapter 5.3d. ParameterException P4 deidentify Patient identifying data (Parameter IdentityMatchException patient ) are used for matching the patient with the right identity, the appropriate pseudonym must be found deidentify response: A messageid corresponding to this TTP transaction. The messageid should be used later on as a replacement for the patientid for Submissionand DocumentEntrySet. P5 checkconsent Using the messageid from the TTP, it is checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. NoConsentException 25 More details about the deidentify function will be described in the technical specification of the esanté platform 26 The TTP response if the patient related data do not match to an identity at the TTP or if the patient is not registered at the TTP already, has to be defined finally in context with the opt-out scenario for the participation of the patient. 27 This consent is not about checking access policies to the health record of a patient, this is done with the checkaccessconsent function on platform level. See 4 for more information about platform security issues. Cahier_des_charges_Technique_General_v1.0.docx48/158 Version 1.0,

49 P6 If consent has been given, true should be returned, false otherwise. getpublickeycertificate 1.6 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. P7 encryptdocuments 1.7 The documents are encrypted before they can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P8 createsubmissionset 1.8 Creates and prepares the XML based representation of the metadata and embeds the documents for transmission to the platform. A unique identifier must be created for each embedded document. The messageid could be used as patientid 28. The value of the parameter transactionid has to be used as unique identifier for the transaction. CreateSubmissionsetException P9 signsubmissionset 1.9 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P10 provideandregisterdocumentset 1.10 This is the transaction which must be used to transfer the documents from the local institution/health professionals to the esanté During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if 28 This is not IHE XDS compliant but could be an easy solution, otherwise the metadata-set of DocumentEntry has to be extended. See chapter 8 for more details. This has to be discussed finally. Cahier_des_charges_Technique_General_v1.0.docx49/158 Version 1.0,

50 platform. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentsetresponse: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 submitdocumentsxds Response: If the transaction succeeds the success - state and possibly a list of warnings will be sent back. Postconditions: Output Parameter: Comments: the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). The operation of transmitting and storing the documents for sharing with the esanté platform is atomic. If an error occurs which prevents the delivery of a single document, the whole transaction will be cancelled. success failure The documents are shared and are accessible for authorized users. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the document sharing. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Notification of the users (e.g. patient, reference doctor of the patient) who have subscribed to be noticed about the arrival of new documents is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. Cahier_des_charges_Technique_General_v1.0.docx50/158 Version 1.0,

51 Sequence Diagram for SubmitDocumentsXDS The main platform scenario for the usage of the function will be shown as part of the sequence diagram below. Cahier_des_charges_Technique_General_v1.0.docx51/158 Version 1.0,

52 5.4e FU-CON-3: SubmitAddendumXDR ID: FU-CON-3 Name: SubmitAddendumXDR Short Description: The caller (Data Provider) provides addendum documents for known recipients (Data Consumer). This function could be used to add addendum reports to an already existing report. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Provider creates a CDA R2 document as medical report. The medical report should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction recipients RecipientLst 1 List of intended recipients provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction comment String 0 or 1 Additional description text documents DocumentRef 1 or n Documents which should be an addendum to a former document Validation: ID Validation Exceptions V1 Parameter transactionid must be a InvalidUuidExeption valid unique identifier by terms of an UUID. V2 Parameter recipients must contain a UnknownRecipientException list of valid and known recipients. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field Cahier_des_charges_Technique_General_v1.0.docx52/158 Version 1.0,

53 V5 Parameter comment must be a valid string and must not be larger than the defined number of chars for this field V6 Parameter documents must contain references to valid documents in HL7- CDA R2 format, providing the mandatory fields described in 5.3c V7 Validate the electronic signature. The documents should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. Processing: See also Sequence Diagram for SubmitAddendumDocumentsXDR P1 submitaddendumdocumentsxdr InvalidLengthException Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and content. NoSignatureFoundException InvalidSignatureException 1 Function called by Data Provider to share documents with the intended recipients. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters including the files (e.g. medical reports) must be checked for consistency. Electronic signature of the medical report will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 Header of the reports are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid. Although maybe present, the CDA header element ParentDocument could not be validated. ParameterException P4 getpublickeycertificate 1.3 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the Cahier_des_charges_Technique_General_v1.0.docx53/158 Version 1.0,

54 P5 TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. encryptdocuments 1.4 The documents are encrypted before they can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P6 createsubmissionset 1.5 Creates and prepares the XML based representation of the metadata and embeds the documents for transmission to the platform. A unique identifier must be created for each embedded document. The value of the parameter transactionid has to be used as unique identifier for the transaction, the values of the parameter recipients have to be placed as value of the intendedrecipient field of the submissionset metadata. CreateSubmissionsetException P7 signsubmissionset 1.6 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P8 provideandregisterdocumentset 1.7 This is the transaction which must be used to transfer the documents from the local institution/health professionals to the intended recipients. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentset Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 submitaddendumdocumentsxdr During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). Cahier_des_charges_Technique_General_v1.0.docx54/158 Version 1.0,

55 Response: If the transaction succeeds the success - state and possibly a list of warnings will be sent back. Postconditions: Output Parameter: Comments: The operation of transmitting and storing the documents for the intended recipients is atomic. If an error occurs which prevents the delivery of a single document, the whole transaction will be cancelled. success failure The documents are provided for the intended recipients successfully. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the provision of the documents. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Notification of the recipients who have subscribed to be noticed about the arrival of new reports is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. Because of XDR the platform could not guarantee that the original document still exists, referencing this document inside the metadata of the XDSSubmissionSet would lead to an Exception on Document Registry level if the referenced document does not exist anymore. Therefore the addendum report must itself clearly state what it is (e.g. by using appropriate values of the Affinity Domain for ClinicalDocument/code ) and which other report it refers to. The report as a CDA R2 document could contain as part of the header the ParentDocument Element, but using XDR the platform should not validate this parameter, because the referenced document could have been already deleted from the platform. This reference could instead be evaluated on Document Consumers side, where the original document should reside. There is no validation if the patient of the addendum report is the same as the one of the original report. This is because when using XDR, no patient identification information is provided on transaction level. Cahier_des_charges_Technique_General_v1.0.docx55/158 Version 1.0,

56 Sequence Diagram for SubmitAddendumDocumentsXDR The main platform scenario for the usage of the function will be shown as part of the sequence diagram below. Cahier_des_charges_Technique_General_v1.0.docx56/158 Version 1.0,

57 5.4f FU-CON-4: SubmitAddendumXDS ID: FU-CON-4 Name: SubmitAddendumXDS Short Description: The caller (Data Provider) provides documents which should be stored and linked to an already existing document of the patient s electronic health record. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. The Data Provider creates a CDA R2 document as medical report. The medical report should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. The Data Provider should provide a unique document identifier of the original document (parentref) to where the new document will be appended. The Data Provider could get this identifier by executing an appropriate query to the esanté platform 29. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction patient PatientRec 1 Patient s demographic data provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction comment String 0 or 1 Additional description text addendumdocuments DocumentRef 1 or n Documents which should be an addendum to a former document parentref UNIQUEID 0 Globally unique identifier of the parent Document 29 The additional communication for querying the unique documentid of the parent document could be omitted if the Data Provider could provide the uniqueid (from the ClinicalDocument/id of the parent document) or the parentdocumentid (from the new document) from a local storage. Cahier_des_charges_Technique_General_v1.0.docx57/158 Version 1.0,

58 instance patientreadblocking Boolean 0 or 1 True/False - Flag to sign that the document could not be read by the patient. unblockingcode String 0 or 1 Parameter may be used if patientreadblocking = True. The patient could use the unblocking code to get access to the document. Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V5 Parameter comment must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field V6 Parameter addendumdocuments must contain references to valid reports in HL7-CDA R2 format, providing the mandatory fields described in 5.3c Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and V7 Parameter parentref if given, must be a valid document identifier (UNIQUEID) of the parent document where this document is the addendum for. 30 content. InvalidIdentifierException could occure if reference is not in a valid format. 30 This validation procedure normally does not check if the given unique identifier for the original document links to a document which is already registered in the Document Registry. Although it would be possible to query the Document Registry for the existence of this document to validate the parameter value, the validation of the unique identifier for the referenced document should be done later on the Document Registry side during the RegisterDocument transaction. If the unique identifier of the original document is given but this document doesn t exist, an Exception will be raised and the transaction fails. If no value has been given, the addendum document will be registered anyway but just like a submitted document without association. Cahier_des_charges_Technique_General_v1.0.docx58/158 Version 1.0,

59 V8 V9 V10 Parameter patientreadblocking, if set must be a valid Boolean (True/False) value. Parameter unblockingcode, should be could be provided if patientreadblocking is set. String must not be larger than the defined number of chars for this field. Validate the electronic signature. The documents should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. InvalidLengthException NoSignatureFoundException InvalidSignatureException Processing: See also Sequence Diagram for SubmitAddendumDocumentsXDS P1 submitaddendumreportxds 1 Function called by Data Provider to share documents using the esanté platform. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters including the files must be checked for consistency. Electronic signature of the medical report will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 Header of the reports are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid, Patient related data must be compliant to the data in the patient Parameter from the PatientRec. If the metadata of the documents contain information about patientreadblocking or unblockingcode, then this values must be validated as described in the matrix at chapter 5.3d. If CDA-Header contains values ParameterException Cahier_des_charges_Technique_General_v1.0.docx59/158 Version 1.0,

60 P4 for ParentDocument and ParentDocumentID both values will be used later-on as DocumentEntry metadata, without verification. deidentify 1.3 Patient identifying data (Parameter IdentityMatchException patient ) are used for matching the patient with the right identity so the appropriate pseudonym must be found. 1.4 deidentify response: A messageid corresponding to this TTP transaction. The messageid should be used later on as a replacement for the patientid for Submissionand DocumentEntrySet. P5 checkconsent 1.5 Using the messageid from the TTP, it is NoConsentException checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. If consent has been given, true should be returned, false otherwise. P6 getpublickeycertificate 1.6 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. P7 encryptdocuments 1.7 The documents are encrypted before they can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P8 createsubmissionset 1.8 Creates and prepares the XML based CreateSubmissionsetException Cahier_des_charges_Technique_General_v1.0.docx60/158 Version 1.0,

61 P9 representation of the metadata and embeds the documents for transmission to the platform. A unique identifier must be created for each embedded document. The messageid could be used as patientid (see 8). If parameter parentref is not null an association object inside the SubmissionSet will be created which links the original document and the new documents. For the addendum an association object must be defined which links the new report as SourceObject with the unique identifier of the already existing document as TargetObject and association type of APND. If CDA-Header contains values for ParentDocument and ParentDocumentID both values will be used as DocumentEntry metadata, without verification. signsubmissionset 1.9 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P10 provideandregisterdocumentset 1.10 This is the transaction which must be used to transfer the documents from the local institution/health professionals to the esanté platform. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentset Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 submitaddendumdocumentsxds Response: If the transaction succeeds the success - state and possibly a list of warnings will be sent back. Postconditions: During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). The operation of transmitting and storing addendums of a document for sharing with the esanté platform is atomic. If an error occurs which prevents the delivery of a single document, the whole transaction will be cancelled. success The documents are shared and are accessible for authorized Cahier_des_charges_Technique_General_v1.0.docx61/158 Version 1.0,

62 Output Parameter: Comments: failure users. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the document sharing. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Addendum Reports could also be blocked as when sharing the original report. This is similar to 5.4d. Notification of the users (e.g. patient, reference doctor of the patient) who have subscribed to be noticed about the arrival of new reports is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. The platform functionality is responsible to verify if the given reference identifier to the original document exists and if the document is in a appropriate document state. The document being appended to, must be in Approved state and must not be Deprecated otherwise errors occur. It also has to be checked on Document Repository level that the patient, for whom the addendum documents should be stored, is the same patient which belongs to the parent document. Internally the Registry therefore has to query the TTP using the pseudonym of the parent document and the messageid of the new document to verify if the pseudonyms belong to the same person (e.g. see transaction equalidentity inside the interaction diagram). Cahier_des_charges_Technique_General_v1.0.docx62/158 Version 1.0,

63 Sequence Diagram for SubmitAddendumDocumentsXDS The main platform scenario for the usage of the function will be shown as part of the sequence diagram below. Cahier_des_charges_Technique_General_v1.0.docx63/158 Version 1.0,

64 5.4g FU-CON-5: CancelDocument ID: FU-CON-5 Name: CancelDocument Short Description: This function will be used for the cancellation of documents which are shared using XDR or XDS. Cancelling of documents on the platform changes the document state from Approved to Deprecated, so that the document is unavailable for viewing by normal data consumers. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. The Data Provider must be the creator of the document which he wants to cancel. The Data Provider should provide unique document identifier for the document to cancel (UNIQUEID). This identifier could be provided from the Data Provider s system or the Data Provider could get the identifier by executing an appropriate query to the esanté platform. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction 31 comment String 0 or 1 Additional description text cancelmessage String 1 Message which should describe the reason for the cancellation. This text will be used as content for the cancellation message and notification. canceldoc UNIQUEID 1 Unique identifier of document to 31 The title attribute as the comment attribute too, describe the transaction itself. Cahier_des_charges_Technique_General_v1.0.docx64/158 Version 1.0,

65 cancel Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter provider must link to a UnknownProviderException valid registered provider V3 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V4 Parameter comment must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field V5 Parameter cancelmessage must InvalidLengthException be a valid string and must not be larger than the defined number of chars for this field V6 Parameter canceldoc must contain as value a unique identifier for the document which should be canceled. InvalidIdentifierException could occur if reference is not in a valid format. 32 Processing: See also Sequence Diagram for CancelDocument P1 canceldocument 1 Function called by Data Provider to cancel a shared document, no matter if it was provided using XDR or XDS functions. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters must be checked for See Validation section above consistency. P3 createsubmissionset 1.2 Creates and prepares the XML based representation of the metadata. For the document which should be cancelled an association xml element must be created. The CreateSubmissionsetException 32 A validation if the document identifiers belong to really existing documents registered at Document Registry side is not done here. This is part of the validation procedure of the Document Registry. Documents which should be cancelled but not registered at Document Registry side should lead to warning messages, but the transaction should not fail. Cahier_des_charges_Technique_General_v1.0.docx65/158 Version 1.0,

66 P4 original (current) state of the document and the new state Deprecated for the document must be given. The association must link the SubmissionSet as sourceobject with the documentid as targetobject. signsubmissionset 1.3 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P5 updatedocumentset 1.4 This is the transaction which must be used to update the document metadata. Therefore the created SubmissionSet must be used updatedocumentsetresponse Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 canceldocumentsresponse Response: If the transaction succeeds the success - state is the response, otherwise the failure - state possibly with a list of warnings will be send back. Postconditions: During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). UnresolvedUuidException if a documententry with this ID could not be found. The operation of cancelling a document leads to a change of documents metadata and is atomic. If an error occurs which prevents the cancellation the whole transaction will be rolled back. A partial success is not allowed. success failure The document metadata are changed successfully, so that the document will be deprecated and not be retrievable using ordinary queries. In case of XDR and if the DocumentEntry still exists, the recipients of the document will get a cancellation message. An error occurred during the document metadata update. If the document with the given identifier does not exist in the Registry, the method returns a failure. The parameter messages contains the list of errors which Cahier_des_charges_Technique_General_v1.0.docx66/158 Version 1.0,

67 Output Parameter: Comments: occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. Although the patient identification is not an attribute which is part of this function parameters, in case of XDS the patients consent (patient is known on Document Registry side) should be recognized (e.g. if a Document Provider tries to cancel a document of a patient where he has no access right for). Although it is supported technically by using the ebxml DeprecateObjectsRequest function to cancel ( deprecate ) more than one document at a time by using this ebxml function, the functional specification for the Connector-Api foresees the cancellation of single documents, because of dealing with cancellation messages and notifications. Document cancelling may result in the deletion of the document, if the patient has no consent (XDR). However, the physical deletion of the document itself is not a direct consequence of the CancelDocument transaction, even though the removal of the document from all incoming Folders may have created the condition required for physical document deletion. The deletion itself is the consequence of the lack of patient consent, and is dealt with by a different service of the esanté platform, the Lifecycle service as shown in the following sequence diagram. The Lifecycle service asynchronously checks the state of the documents and is grouped with the Registry service. In case of XDS where the patient has given consent, the document state will be changed to deprecated. If the document which should be cancelled (deprecated) does not exist in the platform, the transaction returns an error. The Data Provider creates and provides the unique identifier for the transaction and therefore will be able to reference to these transaction. Notification of the users (e.g. patient, reference doctor of the patient) who have subscribed to be noticed about the update of metadata belonging to reports they have consent for, is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. Using the transaction for the cancellation (deprecation) of an already deprecated document will not lead to an error. Cancellation of a document leads to cancellation of all appended Cahier_des_charges_Technique_General_v1.0.docx67/158 Version 1.0,

68 documents (addendums), so all appended documents and the original document are deprecated. 33 The activity diagram will show more details, see the Activity Diagram for processupdatedocumentsetrequest in case of XDR transmission Sequence Diagram for CancelDocument 33 This is conformant to the IHE-XDS profile. If the orginial document is not valid anymore, any addendum which relates to this document and relies on the information of this document will be deprecated. Cahier_des_charges_Technique_General_v1.0.docx68/158 Version 1.0,

69 As shown in the sequence diagram above, the additional Lifecycle-Service is responsible for removing the deprecated XDR documents. Activity Diagram for processupdatedocumentsetrequest in case of XDR transmission The activity-diagram below shows the details of the processupdatedocumentsetrequest() method to illustrate the behavior for documents which are provided using XDR. At first all the associations between the document and the InBox folders of the recipients have to be deprecated. Therefore the unique documentid of the document is needed. For all Cahier_des_charges_Technique_General_v1.0.docx69/158 Version 1.0,

70 recipients which have already downloaded/read the document, a cancellation message will be provided in their InBox folder, which describes the cancellation by using the text from the cancelmessage parameter. Users which have subscribed for notifications about document state changes or cancellation will be notified. 5.4h FU-CON-6: ReplaceDocumentXDR ID: FU-CON-6 Name: ReplaceDocumentXDR Short Description: The caller (Data Provider) provides a replacement document for known recipients (Data Consumer). This function could be used to replace an already existing document by a new document. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Provider creates a CDA R2 document. The medical report should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction recipients RecipientLst 1 List of intended recipients provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction comment String 0 or 1 Additional description text replacemessage String 1 Text which will be used for replacement message replacedocid UNIQUEID 1 Unique Identifier of the document which should be replaced replacementdoc DocumentRef 1 New document which replaces Cahier_des_charges_Technique_General_v1.0.docx70/158 Version 1.0,

71 the old one Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter recipients must UnknownRecipientException contain a list of valid and known recipients. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V5 Parameter comment must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field V6 Parameter replacemessage must InvalidLengthException be given and must not be larger than the defined number of chars for this field V7 Parameter replacedocid must InvalidIdentifierException contain a unique identifier as reference to valid document V8 Parameter replacementdoc must contain a reference to valid document Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and V9 Validate the electronic signature. The report should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. Processing: See also Sequence Diagram for ReplaceDocumentXDR content. NoSignatureFoundException InvalidSignatureException P1 replacedocumentxdr 1 Function called by Data Provider to replace old Different Exceptions could occur Cahier_des_charges_Technique_General_v1.0.docx71/158 Version 1.0,

72 P2 documents with new documents for the intended recipients. validateinputparameters during the whole transaction and are listed at subsequent processing steps. 1.1 All input parameters including the document reference for the replacement document must be checked for consistency. Electronic signature of the medical report will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 document are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid. ParameterException P4 getpublickeycertificate 1.3 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. P5 encryptdocuments 1.4 The replacement document is encrypted. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P6 createsubmissionset 1.5 Creates and prepares the XML based representation of the metadata and embeds the document for transmission to the platform. A unique identifier must be created for the embedded document. Because of XDR transmission a replacement association is not necessary, instead the replacement information could be part of the document s header information if the document is a CDA CreateSubmissionsetException Cahier_des_charges_Technique_General_v1.0.docx72/158 Version 1.0,

73 P7 R2. signsubmissionset 1.6 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P8 provideandregisterdocumentset 1.7 This is the core platform transaction which must be used to transfer the replacement information and document from the local institution/health professionals to the intended recipients. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentset Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 replacedocumentxdrresponse: If the transaction succeeds the success - state and possibly a list of warnings will be send back. During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). Postconditions: Output Parameter: Comments: The operation of replacing the document for the intended recipients is atomic. If a critical error occurs the whole transaction will be cancelled. success failure The document is provided for the intended recipients successfully. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the replacement of the document. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Cahier_des_charges_Technique_General_v1.0.docx73/158 Version 1.0,

74 Notification of the recipients who have subscribed to be noticed about the arrival of a new document is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. Because of XDR the platform could not guarantee that the original document still exists, referencing this document inside the metadata of the XDSSubmissionSet could lead to an Exception on Document Registry level if the referenced document which should be replaced does not exist anymore. Implementing XDR the non existence of the referenced document should be accepted. Therefore the replacing document must itself clearly state what it is (e.g. by using appropriate values of the Affinity Domain for ClinicalDocument/code) and which other document it refers to. For example the report as a CDA R2 document could contain as part of the header the ParentDocument Element, but using XDR the platform should not validate this parameter, because the referenced document could have been already deleted from the platform. This reference could instead be evaluated on Document Consumers side, where the original document should reside. There is no validation if the patient of the replaced report is the same as the one of the original report. Because when using XDR, no patient identification information is provided on transaction level. Out of restrictions from IHE XDS profile, based on the ebxml Registry Services and Protocols 3.0 specification, it is not allowed to create a replace link for an already deprecated document. See Chapter 5.4 of the spec. So this will cause an Exception. The activity diagram will show more details, see: Activity Diagram for processxdrreplacementrequest at the Document Registry Cahier_des_charges_Technique_General_v1.0.docx74/158 Version 1.0,

75 Sequence Diagram for ReplaceDocumentXDR Cahier_des_charges_Technique_General_v1.0.docx75/158 Version 1.0,

76 Activity Diagram for processxdrreplacementrequest at the Document Registry As shown in the activity diagram above, at first all the associations between the old document and the InBox folders of the recipients have to be deprecated. Therefore the unique documentid of the old document is needed. For all old recipients which have already Cahier_des_charges_Technique_General_v1.0.docx76/158 Version 1.0,

77 downloaded/read the document, a replacement message is provided in their InBox folder, which describes the replacement by using the text from the replacemessage parameter. For all the recipients, the recipients listed in the parameter recipients and the all old recipients, the replacement document will be linked to their InBox folder. Users which have subscribed for notifications about document state changes or for arrival of new documents will be notified. 5.4i FU-CON-7: ReplaceDocumentXDS ID: FU-CON-7 Name: ReplaceDocumentXDS Short Description: The caller (Data Provider) provides a document which should be stored and replace an already existing document of the patient s electronic health record. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. The Data Provider creates CDA R2 documents/reports. The medical report should be signed electronically by the Data Provider. The Data Provider should provide a unique document identifier for the original document (replacedocid) which will be replaced by the new document. This identifier could be provided from the Data Provider s system or the Data Provider could get this identifier by executing an appropriate query to the esanté platform. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction patient PatientRec 1 Patient s demographic data provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction The title attribute as the comment attribute too, describe the transaction itself. Documents themselves can provide their own title and comment attribute as part of the HL7 CDA R2 header (see the chapter 5.3 in this document) Cahier_des_charges_Technique_General_v1.0.docx77/158 Version 1.0,

78 comment String 0 or 1 Additional description text replacemessage String 1 Text which will be used for replacement message replacedocid UNIQUEID 1 Unique Documentid of the document which should be replaced replacementdoc DocumentRef 1 New document which replaces the old one patientreadblocking Boolean 0 or 1 True/False - Flag to sign that the document could not be read by the patient. unblockingcode String 0 or 1 Parameter may be used if patientreadblock ing = True. The patient could use the unblocking code to get access to the document 35. Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V5 Parameter comment must be a valid string and must not be larger than the defined number of chars for this field InvalidLengthException 35 There could be situations where the patientreadblocking Flag is set and no unblockingcode was given. In those situations only a healthcare provider which has access to the document e.g. the general practitioner, could unblock the document for the patient. Cahier_des_charges_Technique_General_v1.0.docx78/158 Version 1.0,

79 V6 V7 V8 V9 V10 V11 Parameter replacemessage must be given and must not be larger than the defined number of chars for this field Parameter replacedocid must contain a unique identifier for a valid document of the patient s health record. Parameter replacementdoc must contain references to valid document which should be the replacement document for the old document. Parameter patientreadblocking, if set must be a valid Boolean (True/False) value. Parameter unblockingcode, should be could be provided if patientreadblocking is set. String must not be larger than the defined number of chars for this field. Validate the electronic signature. The document should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. InvalidLengthException InvalidIdentifierException Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and content. InvalidLengthException NoSignatureFoundException InvalidSignatureException Processing: See also Sequence Diagram for ReplaceDocumentXDS P1 replacedocumentxds 1 Function called by Data Provider to replace an old document with a new one for a patient s electronic health record. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters including the document reference for the replacement document must be checked for consistency. Electronic signature of the medical report will be checked if exists. See Validation section above P3 extractheaderdata Cahier_des_charges_Technique_General_v1.0.docx79/158 Version 1.0,

80 1.2 Data of the required fields from the document (dependent on the document type) are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid, Patient related data must be compliant to the data in the patient Parameter from the PatientRec. If the metadata of the documents contain information about patientreadblocking or unblockingcode, then this values must be validated as described in the matrix at chapter 5.3d. ParameterException P4 deidentify 1.3 Patient identifying data (Parameter IdentityMatchException patient ) are used for matching the patient with the right identity so the appropriate pseudonym must be found. 1.4 deidentify response: A messageid corresponding to this TTP transaction. The messageid must be used later on as a replacement for the patientid for Submissionand DocumentEntrySet. P5 checkconsent 1.5 Using the messageid from the TTP, it is NoConsentException checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. If consent has been given, true should be returned, false otherwise. P6 getpublickeycertificate 1.6 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. P7 encryptdocuments Cahier_des_charges_Technique_General_v1.0.docx80/158 Version 1.0,

81 1.7 The document is encrypted before it can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P8 createsubmissionset 1.8 Creates and prepares the XML based representation of the metadata and embeds the document for transmission to the platform. A unique identifier must be created for each embedded document. The messageid must be used as patientid. The SubmissionSet will be created and an association object which links the original document ( replacedocid ) and the new document, with the association type RPLC is placed together with the new document entry in the SubmissionSet. CreateSubmissionsetException P9 signsubmissionset 1.9 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P10 provideandregisterdocumentset 1.10 This is the core platform transaction which must be used to transfer the replacement information and document from the local institution/health professionals for the patient s electronic health record. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentset Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 replacedocumentxds Response: If the transaction succeeds the success - state and possibly a list of warnings will be send back. Postconditions: During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). The operation of replacing the old and storing the new document for sharing with the esanté platform is atomic. If an error occurs which prevents the replacement of the document, the whole transaction will be Cahier_des_charges_Technique_General_v1.0.docx81/158 Version 1.0,

82 Output Parameter: Comments: cancelled. success failure The new document is shared and accessible for authorized users. The replaced document s state is changed to Deprecated and is no longer accessible for users. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the document replacement, e.g. the old document does not exist or a wrong replacedocid was given. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. A replacement report should also be blocked as when sharing the original report. This is similar to 5.4d Notification of the users (e.g. patient, reference doctor of the patient) who have subscribed to be noticed about the arrival of new or replaced documents is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. The platform functionality is responsible to verify if the given reference identifier to the original document exists and if the document is in an appropriate document state. The document being replaced, must be in Approved state and must not be Deprecated otherwise errors occur (this is conform to the IHE transactional behaviour). It also has to be checked on Document Registry level that the patient for whom the replacement document should be stored is the same patient which belongs to the parent document. Internally the Registry therefore has to query the TTP using the pseudonym of the parent document and the messageid of the new document to verify if the pseudonyms belong to the same person (e.g. see transaction equalidentity inside the interaction diagram). If the document which should be replaced does not exist, the transaction fails with an Exception. The activity diagram will show more details, see Activity Diagram for processxdsreplacedocumentrequest at the Document Registry. Cahier_des_charges_Technique_General_v1.0.docx82/158 Version 1.0,

83 Sequence Diagram for ReplaceDocumentXDS Cahier_des_charges_Technique_General_v1.0.docx83/158 Version 1.0,

84 Activity Diagram for processxdsreplacedocumentrequest at the Document Registry Cahier_des_charges_Technique_General_v1.0.docx84/158 Version 1.0,

85 5.4j Principles for the usage of the Data Consumer functions for document query and retrieval For the search and retrieval of documents from the esanté platform there are mainly two functions for each communication scheme (XDR, XDS) necessary. A function to query for the metadata of the documents QueryDocumentsXDR/XDS and a function for the retrieval of the documents based on the metadata of the documents RetrieveDocumentsXDR/XDS. Using these functions, a Data Consumer s client application will be able to retrieve the documents which were selected by the user. The QueryDocumentsXDR function is related to the Reliable Data Transmission Viewer Use Case mentioned at the Cahier des charges fonctionnel, for the overview about documents which are available at the InBox folder of the Data Consumer s application. The picture below shows a mockup screen (all mockup-screens taken from the Cahier des charges fonctionnel) which uses the QueryDocumentsXDR transaction for retrieving metadata about the documents. There are 6 new documents in your Incoming Folder. Show All documents (6) Query Incomming Folder [Dr. House] Selected documents Submission date from: / / to: / / Document types: Radiology (6) Lab reports (0) Report (3) All (0) Addendum (1) Only Current (0) Significant Images (2) Other types of clinical documents will to be added when available Download Selected Documents After calling the QueryDocumentsXDR function the Data Consumer could see that there are 6 new documents available. Because the function returns the metadata of the documents, the client will be able to group the information dependent on the document types. If the Button Download Selected Documents is pressed, the Data Consumer s client application must call the RetrieveDocumentsXDR function and provide the entryuuid s of the documents selected for download. After the documents are downloaded, they will be decrypted and the Data Consumer can browse through the documents by using the view shown in the picture below. Cahier_des_charges_Technique_General_v1.0.docx85/158 Version 1.0,

86 There are 106 downloaded documents in your local folder, 6 new. Dwnld. Date Create Date Patient Matricule New [6] 19/01/11 16/01/11 MEYER Anton /01/11 15/01/11 MULLER Carola /01/11 15/01/11 PUTZ Jean-Marie /01/11 13/01/11 DA SILVA Maria /01/11 13/01/11 MULLER Carola /01/11 12/01/11 PARRAIN Claude Yesterday [11] Last Week [55] February 2011 [10] January 2011 [9] 2010 [15] Locally Browse & View Downloaded Documents [Dr. House] Patient Name & Document Type Origin Title Move View Rad. Report Zitha Klinik NM Miniscus L; Dr. DAIMLER Rad. Report CHEM NM Right arm; Dr. MERSCH Rad. Add. Report Radiol. Esch MR Osteo left knee; Dr. KONZ Rad. Radiol. 23/01/1; SC cranium; Appointment Dudelange Radiology Dpt. Dudelange Rad. Signif. CHEM NM Right arm; Images Dr. MERSCH Rad. Report Radiol. SC Thyroide I-131/125mg; Dudelange Dr. MABUSE Cahier_des_charges_Technique_General_v1.0.docx86/158 Version 1.0,

87 Before a Data Consumer is able to query and retrieve documents in an XDS scenario, he must first identify the patient from whom he wants to retrieve the documents. Identify Patient [Dr. House] Enter patient ID Lux. Matricule: Other SSN 1 : Extended Patient Search Criteria First name: Carola Last name: MULLER Gender: F (Male, Female, Other, Unknown) Birth Date: 18/04/1985 [DD/MM/YYYY] Birth Place City: Dudelange Name Alias: Last Birth Name: First Birth Name: Birth Place Country 3 Birth Nationalities: 3,, (up to 3 allowed) Nationalities: 2 LU,, (up to 3 allowed) Address Street: Address Country: 2 LU Address ZIP Code: 4253 Address City: Esch/Alzette Father s Birth Name: Mother s Birth Name: EU SSN: National SSN 1 : National SSP 4 : National SSP 4 Country: 1 LuxTrust ID: CNS LU Less search criteria 1 SSN = Social Security Number 2 nationalities ISO alpha-2 code, e.g. LU, DE, FR, PT 3 nationalities ISO alpha-2 and ISO code (for obsolete countries, such as DDDE for DDR) 4 SSP = Social Security Provider (*) becomes mandatory if Requesting Entity Patient ID is provided Quit Access Patient s SPHR These patient demographics data are a parameter of the QueryDocumentsXDS function, which delivers as a result the metadata of all documents of the patients electronic health record, which are currently in the Approved state. The client application form could then group and visualize this metadata (as shown in the picture below) for later retrieval by using the RetrieveDocumentsXDS function. If a patient could not be matched uniquely, the Data Consumer has to provide additional demographic information (see Extended Patient Search Criteria in the picture above), to provide the system more parameter values for the matching process. Cahier_des_charges_Technique_General_v1.0.docx87/158 Version 1.0,

88 Overview of Patient Carola MULLER ( ) [Dr. House] There are 17 documents, 1 folder and 1 appointment. Filter for period: / / to: / / Filter for period Radiology (2) 15/01/11 Report (*) NM Right arm; CHEM 17/01/11 Addendum NM Right arm; CHEM Appointments (1) 03/01/11 Radio. NM Right arm rescheduled to 13/01/11 8:30; CHEM; Laboratory (15) 25/11/10 Cholesterol HDL, LHDL, Triglycerides, ratio HDL/LHDL LX 10/10/10 TSH ultra sensible LY 26/07/10 TSH ultra sensible LY 03/03/10 TSH ultra sensible LY 23/11/09 TSH ultra sensible LY Referral (1) 02/02/11 Arthritis right arm New Referral (*) Images are available through the report Cahier_des_charges_Technique_General_v1.0.docx88/158 Version 1.0,

89 5.4k FU-CON-8: QueryDocumentsXDR ID: FU-CON-8 Name: QueryDocumentsXDR Short Description: This function will be used to query for the list of document - metadata which are available at the InBox folder of the Data Consumer. The list contains metadata about all documents with status Approved and which haven t been downloaded/viewed by this Data Consumer yet. Actors/Category: A2 Data Consumer layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Consumer is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. A special typed folder called InBox is registered and accessible for this Data Consumer. Input Parameters: Name Type Cardinality Description consumer 36 ConsumerRec 0 Consumer identification queryparams QryParamList 0 or 1 List of values for the query parameters Validation: ID Validation Exceptions V1 Parameter consumer if given, UnknownConsumerException must link to a valid registered consumer. V2 Parameter queryparams must contain valid values for all mandatory fields. If no parameters given, the default query will be executed. ParameterBindingException Processing: See also Sequence Diagram for QueryDocumentsXDR P1 querydocumentsxdr 1 Function called by Data Consumer to query for metadata of documents which are linked to the Consumer s InBox folder Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 36 The consumer data record is listed here as a parameter, if there is a permission for a caller to access the InBox of another Data Consumer e.g. in case of a delegation. If there is no additional security permission, the InBox must belong to the identity of the authenticated Data Consumer. Cahier_des_charges_Technique_General_v1.0.docx89/158 Version 1.0,

90 1.1 All input parameters must be checked for See Validation section above consistency. P3 createfindfoldersquery 1.2 The XML based representation for the query about metadata of the InBox folder will be created. Therefore the mandatory parameters are set e.g. the Data Consumer as owner of the folder and the XDSFolder.codeList to look for the InBox folder type. 37 CreateQueryXmlException P4 signquerydataset 1.3 The xml query document set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P5 registrystoredquery(findfolders(inbox.type)) 1.4 This is the transaction which must be used FolderNotFoundException to retrieve the folder metadata of a Data Consumer s InBox folder registrystoredqueryresponse: If the InBoxfolder could be determined for this user, the metadata of this XDS folder object are returned as the signed query response. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. InvalidSignatureException P6 creategetfolderandcontentsqueryxml 1.5 Creates and prepares the XML based representation of the metadata for the query. The GetFolderAndContents query which should be called will be referenced by an UUID. The parameters given in the queryparams attribute will be bound to the query variables, the folder from where the contents (the document metadata) should be CreateQueryXmlException 37 The metadata of the InBox folder of the Data Consumer must be determined with this query. It is important to query for the type InBox folder for the Data Consumer or the InBox folder which the caller has permissions and is owned by the Data Consumer given as parameter Consumer. In IHE a folder is related to a patient, we need therefore an extension, which is at the comments of this transaction specification. Cahier_des_charges_Technique_General_v1.0.docx90/158 Version 1.0,

91 P7 retrieved is identified by the XDSFolder.entryUUID or XDSFolder.uniqueID which has been determined during the processing of the FindFolders query in processing step P5. signquerydataset 1.6 The xml query document set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P8 registrystoredquery(getfolderandcontents(inbox.entryuuid)) 1.7 This is the transaction which must be used to execute the query transaction at the Document Registry to retrieve the documents metadata which are requested. During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework registrystoredqueryresponse: A structured XML file will be send back as a response, containing as a result set of the query the signed metadata of the matching documents and the metadata of the folder. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. 2 querydocumentsxdrresponse: If the transaction succeeds the success - state and possibly a list of warnings will be send back. Postconditions: Output Parameter: specification (Vol. 3). InvalidSignatureException The operation of querying for document metadata is atomic. If an error occurs the whole transaction will be cancelled. success Failure An empty result set or the document metadata which are the result of this query are returned. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the query execution. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description resultset String 1 or n Query result set, contains list of document metadata, Cahier_des_charges_Technique_General_v1.0.docx91/158 Version 1.0,

92 Comments: could be empty if no data found messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The function bridges the call to a stored query at the Document Registry. The parameters of the query are defined and values must be provided by using the queryparams parameter. All values are bound to their parameters inside of the Connector-API function call. Since registry stored queries are executed as SQL-Queries at the Document Registry Database, the system must strictly avoid the injection of SQL code. Therefore it is only allowed to use prepared database statements and bind values. The Connector-API internally creates first a query to determine the InBox folder s metadata. To find this folder, which is related to the DataConsumer and not to a patient, the XDSFolder attributes must be extended to provide a user reference. Additionally the InBox folder should be classified by a special type. The IHE folder specification forsees a field called XDSFolder.codeList which is intended to specify the type of clinical activity that resulted in placing XDS Documents in this XDSFolder. This seems not to be the right attribute to use, although the value sets are AffinityDomain specific and the codelist could contain more than one type. This has to be solved at core platform level. The Data Consumers user interface should provide the functionality to customize the parameter values for the query e.g. the type of reports to retrieve. The platform should provide functionalities to limit the maximal size of a Data Consumers InBox folder to ensure the availability of XDR messages. If the maximum amount of space is used, new incoming messages should be rejected and the Data Provider should be informed. 38 A maximal time limit that determines how long documents can stay in the InBox folder before being removed automatically. This is necessary to avoid long-term storage of patient data when it is not allowed, due to the absence of patient consent. The platform security related functions have to ensure that the Data Consumer who wants to query the InBox has the appropriate permissions (as described in the Preconditions section). 38 It could also be a feature to send a notification about this event to the Data Consumer (owner of the InBox ) by using a secondary mail address. Cahier_des_charges_Technique_General_v1.0.docx92/158 Version 1.0,

93 Parameterlist for attribute queryparams (GetFolderAndContents from IHE) The type QryParamList as type of the parameter queryparams contains, dependent of the query which is related to this transaction, different parameters for which values must be provided. The following table lists the parameters which could be provided by the Data Consumer: Parameter Corresponding metadata Occurance Description $XDSDocumentEntryFo rmatcode XDSDocumentEntry.formatCode 0 If a value is given, only documents with this formatcode (e.g. for CDA) are returned. Possible values are defined by IHE and could be enhanced for $XDSDocumentEntryCo nfidentialitycode XDSDocumentEntry.confidential itycode the Affinity Domain 0 If a value is given, only document metadata with this confidentialitycode are returned The following table shows the parameters which are set by the Connector-API internally when calling the core function FU-CORE-3: Registry Stored Query for GetFolderAndContents. Both parameters are determined by the Connector-API during the FindFolders Registry Stored Query function call. Parameter Corresponding metadata Occurance Description $XDSFolderEntryUUID XDSFolder.entryUUID 1 39 UUID reference to the folder $XDSFolderUniqueId XDSFolder.uniqueId 1 39 Unique identifier of the folder 39 One of both parameters must be set, either entryuuid or uniqueid to determine the folder. Cahier_des_charges_Technique_General_v1.0.docx93/158 Version 1.0,

94 Sequence Diagram for QueryDocumentsXDR Cahier_des_charges_Technique_General_v1.0.docx94/158 Version 1.0,

95 5.4l FU-CON-9: QueryDocumentsXDS ID: FU-CON-9 Name: QueryDocumentsXDS Short Description: This function will be used to query for the list of document s metadata which are part of a patients shared electronic health record. The list contains metadata about all documents with status Approved. Actors/Category: A2 Data Consumer layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Consumer is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. Data Consumer must have consent to query for patients data Input Parameters: Name Type Cardinality Description patient PatientRec 1 Patient s demographic data consumer 40 ConsumerRec 0 Consumer identification queryparams QryParamList 0 or 1 List of values for the query parameters Validation: ID Validation Exceptions V1 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V2 Parameter consumer if given, UnknownConsumerException must link to a valid registered consumer. V3 Parameter queryparams must contain valid values for all mandatory fields. If no parameters given, the default query will be executed. ParameterBindingException Processing: See also Sequence Diagram for QueryDocumentsXDS P1 querydocumentsxds 40 An consumer data record is listed here as a parameter, if not given this relates to the identity of the authenticated Data Consumer. Cahier_des_charges_Technique_General_v1.0.docx95/158 Version 1.0,

96 1 Function called by Data Consumer to query for metadata of documents which are linked to the patient defined in patient parameter P2 validateinputparameters Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. 1.1 All input parameters must be checked for See Validation section above consistency. P3 deidentify 1.2 Patient identifying data (Parameter IdentityMatchException patient ) are used for matching the patient with the right identity, the appropriate pseudonym must be found. 1.3 deidentify response: A messageid corresponding to this TTP transaction. The messageid must be used later on as a replacement for the patientid for Submissionand DocumentEntrySet. P4 checkconsent 1.4 Using the messageid from the TTP, it is NoConsentException checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. If consent has been given, true should be returned, false otherwise. P5 createfinddocumentsqueryxml 1.5 Creates and prepares the XML based representation of the metadata. The FindDocuments query which should be called will be referenced by an UUID. The parameters given in the queryparams attribute will be bound to the query variables which are described below this table. CreateQueryXmlException P6 signquerydataset 1.6 The xml query document set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P7 registrystoredquery(finddocuments) Cahier_des_charges_Technique_General_v1.0.docx96/158 Version 1.0,

97 1.7 This is the core platform transaction which must be used to execute the query transaction at the Document Registry to retrieve the metadata of the documents which matches the query. Only document metadata with Approved state are considered. See registrystoredquery Response: A structured XML file will be send back as a response, containing as a result set of the query the metadata of the matching documents. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. 2 querydocumentsxds Response: If the transaction succeeds the success - state and possibly a list of warnings will be send back. Postconditions: Output Parameter: Comments: During the execution of the platform transaction, different Exceptions could occur. These exceptions are part of the IHE Technical Framework specification (Vol. 3). The operation of querying for document metadata is atomic. If an error occurs the whole transaction will be cancelled. success Failure An empty result set or the document metadata set which are the result of this query are returned. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the query execution. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description resultset String 1 or n Query result set, contains list of document metadata, could be empty if no data found messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The function bridges the call to a stored query at the Document Registry. The parameters of the query are defined and values must be provided by using the queryparams parameter. All values are bound to their parameters inside of the Connector-API function call. Since registry stored queries are executed as SQL-Queries at the Document Registry Database, the system must strictly avoid the injection of SQL code. Therefore it is only allowed to use prepared database statements and bind values. The Data Consumers user interface should provide the functionality to Cahier_des_charges_Technique_General_v1.0.docx97/158 Version 1.0,

98 customize the parameter values for the query e.g. the type of reports to retrieve. The Data Consumer must provide a view to input patient s demographic data. If it is not sufficient to use the social security number, other unique identifiers or the surname and lastname of the patient, the client application must provide a view for typing in more detailed patient related data e.g. name at birth, birth date, address etc. In an emergency case where maybe just a view patient related demographic data are available, the doctor should have the possibility to identify the patient by using/searching at the Citizen Register. Demographic information gathered from this register should then be used for de-identification. Based on the result set of the query, the metadata of the documents should be used by the Document Consumer s client application to present an overview of the documents which are part of the patients electronic health record. The application client should list also the metadata of blocked documents to inform patients as Data Consumers about the presence of a document, even if the patient is at that time not able to retrieve and view the document. Parameterlist for attribute queryparams (corresponding to FindDocuments query from IHE) The type QryParamList as type of the parameter queryparams contains, dependent of the query which is related to this transaction, different parameters for which values must be provided. The following table shows the parameters, according to the IHE specification for the FindDocuments query: Parameter $XDSDocumentEntryClassCode $XDSDocumentEntryTypeCode $XDSDocumentEntryPracticeSettingCode $XDSDocumentEntryCreationTimeFrom Corresponding metadata XDSDocumentEntry. classcode XDSDocumentEntry. typecode XDSDocumentEntry. practicesettingcode XDSDocumentEntry. creationtime Occurance Description 0 Particular kind of document e.g Report 0 Precise kind of document e.g. Radiology Report 0 Clinical speciality e.g. Radiology or Laboratory 0 Lower range, time when Cahier_des_charges_Technique_General_v1.0.docx98/158 Version 1.0,

99 $XDSDocumentEntryCreationTimeTo $XDSDocumentEntryServiceStartTimeFrom $XDSDocumentEntryServiceStartTimeTo $XDSDocumentEntryServiceStopTimeFrom $XDSDocumentEntryServiceStopTimeTo $XDSDocumentEntryHealthcareFacilityType Code $XDSDocumentEntryEventCodeList $XDSDocumentEntryConfidentialityCode $XDSDocumentEntryAuthorPerson $XDSDocumentEntryFormatCode XDSDocumentEntry. creationtime XDSDocumentEntry. servicestarttime XDSDocumentEntry. servicestarttime XDSDocumentEntry. servicestoptime XDSDocumentEntry. servicestoptime XDSDocumentEntry. healthcarefacilityty pecode XDSDocumentEntry. eventcodelist XDSDocumentEntry. confidentialitycode XDSDocumentEntry. author XDSDocumentEntry. formatcode author created the document 0 Upper range, time when author created the document 0 Lower time when the service being documented took place e.g. encounter time 0 Upper time when the service being documented took place e.g. encounter time 0 Lower time when the service ended e.g. discharge time 0 Upper time when the service ended e.g. discharge time 0 Type of organizational setting, e.g. private clinic 0 Clinical act e.g. colonoscopy 0 Confidentiality code of the documents to retrieve 41 0 Author of the document 0 Format of the Document e.g. CDA The following table shows the parameters which are set by the Connector-API internally when calling the core function FU-CORE-3: Registry Stored Query for FindDocuments. The messageid should be set as patientid parameter, which was retrieved from the TTP during the deidentify function call. 41 The optional parameter value for the confidentialitycode which is provided as parameter by the DataConsumer. The platform will check if the requested confidentialitycode does not violate the patient s consent. Cahier_des_charges_Technique_General_v1.0.docx99/158 Version 1.0,

100 Parameter Corresponding metadata Occurance Description $XDSDocumentEntryPatientID XDSDocumentEntry.patien tid 1 Instead of the patient identifier, the messageid is provided by the Connector-API $XDSDocumentEntryStatus XDSDocumentEntry.status 1 The status parameter is set to Approved as default by the Connector-API Sequence Diagram for QueryDocumentsXDS Cahier_des_charges_Technique_General_v1.0.docx100/158 Version 1.0,

101 5.4m FU-CON-10: RetrieveDocumentsXDR ID: FU-CON-10 Name: RetrieveDocumentsXDR Short Description: This function will be used to retrieve documents which are available at the InBox folder of the Data Consumer. Only documents with status Approved and which haven t been downloaded/viewed are available. Actors/Category: A2 Data Consumer layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Consumer is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. A special typed folder called InBox is registered for this Data Consumer and accessible. The Data Consumer has selected a list of documents which should be retrieved. The metadata of the available documents are retrieved by a QueryDocumentsXDR transaction. The documents could be retrieved by using the metadata unique document identifiers. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction consumer 42 ConsumerRec 0 Consumer identification documentids UNIQUEID 1 or n List of document ids of the documents to retrieve Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter consumer if given, UnknownConsumerException must link to a valid registered consumer. V3 Parameter documentids must contain valid identifiers for the documents which should be retrieved. InvalidIdentifierException 42 The consumer data record is listed here as a parameter, if not given this relates to the identity of the authenticated Data Consumer. Cahier_des_charges_Technique_General_v1.0.docx101/158 Version 1.0,

102 Processing: See also Sequence Diagram for RetrieveDocumentsXDR P1 retrievedocumentsxdr 1 Function called by Data Consumer to retrieve the documents with the given unique id s. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters must be checked for See Validation section above consistency. P3 createencryptionkeypair 1.2 A new public-private keypair will be generated and a public certificate must be generated and signed. The private key must kept secure, whereas the public-key certificate will later-on be transferred for document retrieval. CreateKeyPairException P4 createretrievedocumentsxml 1.3 Creates and prepares the XML based representation of the metadata. For each document which should be retrieved an associated xml element must be created with the given document identifier. CreateDocumentsXmlException P5 signxmldataset 1.4 The XML dataset will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P6 retrievedocumentset(xml,pubkeycert) 1.5 This is the transaction which must be used to retrieve the documents from the Document Repository. The documents which should be retrieved are identified by their XDSDocument.entryUUID. As an extension to the standard IHE transaction definition, the retrievedocumentset function must be able to accept the public-key certificate. Because the documents must be encrypted During the execution of the platform transaction, different Exceptions could occur. These exceptions are part of the IHE Technical Framework specification (Vol. 3). Cahier_des_charges_Technique_General_v1.0.docx102/158 Version 1.0,

103 so that only the Document Consumer is able to read the content, the public-key certificate must be transmitted for the rekeying process at the core platform retrievedocumentset Response: A structured XML file will be send back, containing sections with the encrypted documents which are requested, together with the public-key encrypted symmetric key to decrypt the documents. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. If a certain document could not be retrieved, the structure will contain the error or warning message for this document. P7 decryptdocuments 1.6 The documents retrieved from the Document Repository are now decrypted by using the private key of the generated keypair. DecryptionException P8 retrievedocumentsxdr Response 1.7 If the transaction succeeds the current state of each document and the unencrypted document content are returned. If an error occurred when retrieving a document, the documents state will be error. Postconditions: Output Parameter: The operation of retrieving the documents from the esanté platform is processed as a whole. If an error occurs which prevents the retrieval of a single document, the corresponding result entry for this document will contain the error-state and an error message. The transaction will proceed until each document was requested for retrieval. success failure The result set contains the documents and their states. The result set could also contain error messages if documents could not be retrieved. An error occurred during the call of the function. Errors when retrieving single documents as part of a result set does not lead to a failure of the whole transaction. Name Type Cardinality Description documents String 1 or n XML structure containing document states and content The output parameters are encapsulated inside of a XML structure. Cahier_des_charges_Technique_General_v1.0.docx103/158 Version 1.0,

104 Comments: The Data Consumers user interface should provide the functionality to select the available documents before download. Each retrieval transaction could be interrupted by the Data Consumer. Each document which wasn t fully downloaded, remains in the InBox folder of the Consumer and could be downloaded later on. To avoid long-term storage of medical data from patients which haven t given their consent, after a period of time documents are removed from the InBox folder automatically. Visualization and organization of the documents on Document Consumer s side depends on the implementation of the client application. Before the Data Consumer is able to view the documents, they are decrypted on client side. Security mechanisms at platform level must assure that the Data Consumer is the owner of the InBox folder or has the appropriate permissions to access the folder. Implicit access is granted to the documents inside the folder. Cahier_des_charges_Technique_General_v1.0.docx104/158 Version 1.0,

105 Sequence Diagram for RetrieveDocumentsXDR As shown in the sequence diagram above, the Document Repository starts a re-encryption request to encrypt the symmetric key of the document encryption with the public-key of the Connector-API. Cahier_des_charges_Technique_General_v1.0.docx105/158 Version 1.0,

106 5.4n FU-CON-11: RetrieveDocumentsXDS ID: FU-CON-11 Name: RetrieveDocumentXDS Short Description: This function will be used to retrieve documents from a patient s shared electronic health record. Actors/Category: A2 Data Consumer layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Consumer is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Consumer has selected a list of documents which should be retrieved. The metadata of the available documents are retrieved by a QueryDocumentsXDS transaction. The documents could be retrieved by using the metadata unique document identifiers. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction consumer 43 ConsumerRec 0 Consumer identification documentids UNIQUEID 1 or n List of document ids of the documents to retrieve unblockingcode String 0 Optional parameter which enables the patient to view the documents. Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter consumer, if given UnknownConsumerException must link to a valid registered consumer V3 Parameter unblockingcode if provided, must be a valid string and must not exceed the length for this InvalidLengthException 43 If not given, the identity of the Data Consumer who calls the transaction is used. Cahier_des_charges_Technique_General_v1.0.docx106/158 Version 1.0,

107 V4 field. Parameter documentids must contain valid identifiers for the documents which should be retrieved. InvalidIdentifierException Processing: See also Sequence Diagram for RetrieveDocumentsXDS P1 retrievedocumentxds 1 Function called by Data Provider to retrieve the documents from a patient s shared electronic health record. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters must be checked for See Validation section above consistency. P3 createencryptionkeypair 1.2 A new public-private keypair will be generated and a public certificate must be generated and signed. The private key must kept secure, whereas the public-key certificate will later-on be transferred for document retrieval. CreateKeyPairException P4 createretrievedocumentsxml() 1.3 Creates and prepares the XML based representation of the metadata. For each document which should be retrieved an associated xml element must be created with the given documentid (UUID). If provided, the unblockingcode will be added as part of the metadata. CreateDocumentsXmlException P5 signxmldataset 1.4 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P6 retrievedocumentset(messageid,xml,pubkeycert) 1.5 This is the core platform transaction which During the execution of the platform Cahier_des_charges_Technique_General_v1.0.docx107/158 Version 1.0,

108 must be used to retrieve the documents from the esanté platform. As an extension to the standard IHE transaction definition, the retrievedocumentset function must be able to accept the public-key certificate retrievedocumentset Response: A structured XML file will be send back, containing sections with the encrypted documents which are requested, together with the public-key encrypted symmetric key to decrypt the documents. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. If a certain document could not be retrieved, the structure will contain the error or warning message for this document. P7 decryptdocuments transaction, different Exceptions could occur. These exceptions are part of the IHE Technical Framework specification (Vol. 3). 1.6 The documents retrieved from the Document Repository are now decrypted by using the private key of the generated keypair. DecryptionException P8 retrievedocumentsxdsresponse 1.7 If the transaction succeeds the current state of each document and the unencrypted document content are returned. If an error occurred when retrieving a document, the documents state will be error. Postconditions: Output Parameter: The operation of retrieving the documents from the esanté platform is processed as a whole. If an error occurs which prevents the retrieval of a single document, the corresponding result entry will contain the error-state and an error message. The transaction will proceed until each document was requested for retrieval. success failure The documents are shared and are accessible for authorized users. The result set contains the documents and their states. The result set could also contain error messages if documents could not be retrieved. An error occurred during the call of the function. Errors when retrieving single documents as part of a result set does not lead to a failure of the whole transaction. Name Type Cardinality Description documents String 1 or n XML structure containing document states and Cahier_des_charges_Technique_General_v1.0.docx108/158 Version 1.0,

109 content The output parameters are encapsulated inside of a XML structure. Comments: The Data Consumers user interface should provide the functionality to select the available documents before download. Visualization and organization of the documents on Document Consumer s side depends on the implementation of the client application. Before the Data Consumer is able to view the documents, they are decrypted on client side. The Document Consumer could only download/view documents where he has access to. Blocked documents are not downloadable until their confidentialitycode has been changed after providing the right unblockingcode, which is only relevant if the patient himself is a Data Consumer. The unblockingcode could be used by the platform during the checkaccessconsent Transaction to determine the Data Consumer s access right. As an addition to enter the unblockingcode as part of this transaction, we could imagine to have another function for explicitely unblock the document too. Cahier_des_charges_Technique_General_v1.0.docx109/158 Version 1.0,

110 Sequence Diagram for RetrieveDocumentsXDS By calling the checkaccessconsent method, the Document Repository is able to check for each requested document, if the caller has the permission to retrieve the document from the Repository. Cahier_des_charges_Technique_General_v1.0.docx110/158 Version 1.0,

111 5.4o FU-CON-12: SubmitReferralXDS As described at the Cahier des charges fonctionnel, before providing the referral letter of a patient at the esanté platform, the Data Provider must first create this referral letter with his application. He also has to create a referral code to be able to refer to this referral later-on. The Data Provider could select some other documents related to that patient which should be grouped with this referral. Therefore it could be necessary to query the platform for the occurrence of certain documents (QueryDocumentsXDS) which should be linked to this referral. The SubmitReferralXDS transaction could be used after that, to submit the referral information onto the platform. The basic submission transaction is nearly similar to the SubmitDocumentsXDS transaction. The referral document itself should be embedded into a CDA R2 document from which important header data are extracted for the creation of the platform metadata. For each referral a folder will be created at the esanté platform, which contains the referral letter as well as the associations to other documents which are linked to this referral. The referral code which will be printed on the paper form of the referral and which also will be part of the electronic referral document corresponds to the uniqueid of the folder (XDSFolder.uniqueID). This uniqueid will be generated during referral letter creation and must be provided during the SubmitReferralXDS transation as parameter for the referralcode. ID: FU-CON-12 Name: SubmitReferralXDS Short Description: The caller (Data Provider) provides a referral document for a patient which should be stored together with references to other documents which are associated with this referral case. These documents are linked to a new folder for this referral, inside the patient s electronic health record. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. The Data Provider creates a special CDA R2 document as an referral document. The document should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction patient PatientRec 1 Patient s demographic data provider ProviderRec 1 Provider identification Cahier_des_charges_Technique_General_v1.0.docx111/158 Version 1.0,

112 title String 0 or 1 Text which describes the transaction comment String 0 or 1 Additional description text foldername String 1 Name which will be used as title for the folder referraldoc DocumentRef 1 Referral document referralrefs UNIQUEID 0 or n Globally unique identifier of the documents which should be linked to this referral referralcode String 1 Unique identifier as key to refer later on to this referral folder Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V5 Parameter comment must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field V6 Parameter foldername must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field V7 Parameter referraldoc must contain a reference to valid referalreport in HL7-CDA R2 format, providing the mandatory fields described in 5.3c Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and V8 Parameter referralrefs must contain valid unique identifiers of the documents which have to be content. InvalidIdentifierException could occur if reference is not in a valid format. Cahier_des_charges_Technique_General_v1.0.docx112/158 Version 1.0,

113 linked to the same referral folder V9 Parameter referralcode must be a valid string and must not be larger than the defined number of chars for this field V10 Validate the electronic signature. The referral document should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. InvalidLengthException NoSignatureFoundException InvalidSignatureException Processing: See also Sequence Diagram for SubmitReferralXDS P1 submitreferralxds 1 Function called by Data Provider to share the referral document using the esanté platform. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters including the referral letter must be checked for consistency. Electronic signature of the document will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 Header of the referral letter are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid, Patient related data must be compliant to the data in the patient Parameter from the PatientRec. ParameterException P4 deidentify 1.3 Patient identifying data (Parameter patient ) are used for matching the patient with the right identity, the appropriate pseudonym must be found. IdentityMatchException Cahier_des_charges_Technique_General_v1.0.docx113/158 Version 1.0,

114 1.4 deidentify response: A messageid corresponding to this TTP transaction. The messageid must be used later on as a replacement for the patientid for Submissionand DocumentEntrySet. P5 checkconsent 1.5 Using the messageid from the TTP, it is NoConsentException checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. If consent has been given, true should be returned, false otherwise. So if false is returned or an exception occurred, the referral transaction fails. P6 getpublickeycertificate 1.6 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. P7 encryptdocuments 1.7 The referral letter will get encrypted before it can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P8 createsubmissionset 1.8 Creates and prepares the XML based representation of the metadata and embeds the referral document for transmission to the platform. A unique identifier must be created for the embedded document. The messageid must be used as patientid. The referral folder must be defined as part of this SubmissionSet, where the parameter foldername will be set as the title of the folder and the parameter referralcode will be set as the CreateSubmissionsetException Cahier_des_charges_Technique_General_v1.0.docx114/158 Version 1.0,

115 P9 XDSFolder.uniqueID. If the parameter referralrefs is not null and contains a list of document references (XDSDocumentEntry.entryUUID), association objects will be created as part of the SubmissionSet, which links the documents with the referral folder using association type HasMember. signsubmissionset 1.9 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P10 provideandregisterdocumentset 1.10 This is the transaction which must be used to transfer the referral letter from the local institution/health professionals to the esanté platform. Therefore the created SubmissionSet is used. See FU-CORE provideandregisterdocumentset - Response: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 submitreferralxds - Response: If the transaction succeeds, the success - state and possibly a list of warnings will be send back. Postconditions: Output Parameter: During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). The operation of transmitting and storing the referral letter, the folder and associations at the esanté platform is atomic. If an error occurs which prevents one operation from succeeding, the whole transaction will be cancelled. success failure The referral letter is shared and the documents and referral folder are accessible for authorized users. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the sharing. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. Cahier_des_charges_Technique_General_v1.0.docx115/158 Version 1.0,

116 Comments: The referral folder will be defined during the createsubmissionset function processing, as part of the SubmissionSet. This is because the SubmissionSet will also be stored in the Registry and later-on this transaction could be reproduced. The referral code which must be generated on Data Providers side will be used as the XDSFolder.uniqueID of the referral folder. Using this referral code during the RetrieveReferralXDS operation, the referral folder could be uniquely identified. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Notification of the users (e.g. patient, reference doctor of the patient) who have subscribed to be noticed about the arrival of new referral document is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. Cahier_des_charges_Technique_General_v1.0.docx116/158 Version 1.0,

117 Sequence Diagram for SubmitReferralXDS Cahier_des_charges_Technique_General_v1.0.docx117/158 Version 1.0,

118 5.4p FU-CON-13: QueryReferralXDS ID: FU-CON-13 Name: QueryReferralXDS Short Description: This function will be used to query for documents of a patient related referral folder. Actors/Category: A2 Data Consumer layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Consumer is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. Data Consumer must have consent to query for patients data The Data Consumer must have the referralcode which is printed on the paper form referral letter or has been provided by the patient. Input Parameters: Name Type Cardinality Description patient PatientRec 1 Patient s demographic data consumer 44 ConsumerRec 0 Consumer identification referralcode String 1 Unique identifier as key to refer to the referral folder Validation: ID Validation Exceptions V1 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V2 Parameter consumer must link to UnknownConsumerException a valid registered consumer V3 Parameter referralcode must contain valid identifier for the referral folder. InvalidUuidException Processing: See also Sequence Diagram for QueryReferralDocumentsXDS P1 queryreferraldocumentsxds 44 The consumer data record is listed here as a parameter, if not given this relates to the identity of the authenticated Data Consumer. Cahier_des_charges_Technique_General_v1.0.docx118/158 Version 1.0,

119 1 Function called by Data Consumer to query for metadata of documents which are linked to the patient s referral folder P2 validateinputparameters Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. 1.1 All input parameters must be checked for See Validation section above consistency. P3 deidentify 1.2 Patient identifying data (Parameter IdentityMatchException patient ) are used for matching the patient with the right identity, the appropriate pseudonym must be found. 1.3 deidentify response: A messageid corresponding to this TTP transaction. The messageid should be used later on as a replacement for the patientid for Submissionand DocumentEntrySet. P4 checkconsent 1.4 Using the messageid from the TTP, it is NoConsentException checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. If consent has been given, true should be returned, false otherwise. P5 creategetfolderandcontentsqueryxml(referralcode) 1.5 Creates and prepares the XML based representation of the metadata for the query. The GetFolderAndContents query which should be called will be referenced by an UUID. The parameter given in the referralcode attribute will be bound to the query variable, the folder from where the contents (the referral document metadata) should be retrieved is identified by the XDSFolder.uniqueID which will be set to the value of referralcode. CreateQueryXmlException P6 signquerydataset 1.6 The xml query document set will be electronically signed to prevent it against data corruption. The signature algorithm CreateSignatureException Cahier_des_charges_Technique_General_v1.0.docx119/158 Version 1.0,

120 P7 should use the private-key of the Connector for signature creation. registrystoredquery(getfolderandcontents) 1.7 This is the core platform transaction which must be used to execute the query transaction at the Document Registry to retrieve the metadata of the documents in the referral folder which matches the query. Only document metadata with Approved state are considered. See registrystoredqueryresponse: A structured XML file will be send back as a response, containing as a result set of the query the metadata of the matching documents from the referral folder. 2 querydocumentsxdsresponse: If the transaction succeeds the success - state and possibly a list of warnings will be send back. Postconditions: Output Parameter: Comments: During the execution of the platform transaction, different Exceptions could occur. These exceptions are part of the IHE Technical Framework specification (Vol. 3). The operation of querying for document metadata is atomic. If an error occurs the whole transaction will be cancelled. success Failure An empty result set or the document metadata set which are the result of this query are returned. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the query execution. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description resultset String 1 or n Query result set, contains list of document metadata, could be empty if no data found messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The referralcode is used as the only parameter for this query, the query itself is the same as processed during the FU-CON-8: QueryDocumentsXDR function call. The only mandatory parameter which is set is the XDSFolder.uniqueId to search for the right referral folder. Based on the result set of the query, the metadata of the documents should be used by the Document Consumer s client application to present an overview of the documents which are part of the referral. Cahier_des_charges_Technique_General_v1.0.docx120/158 Version 1.0,

121 For retrieving documents after executing this query, no additional functionality has to be provided, instead the FU-CON-11: RetrieveDocumentsXDS function could be called. Possessing the referralcode provides the consent for accessing the referral folder. The code is checked at Document Registry level. Cahier_des_charges_Technique_General_v1.0.docx121/158 Version 1.0,

122 Sequence Diagram for QueryReferralDocumentsXDS Cahier_des_charges_Technique_General_v1.0.docx122/158 Version 1.0,

123 5.4q FU-CON-14: QueryDocumentReaders ID: FU-CON-14 Name: QueryDocumentReaders Short Description: This function will be used to query for the list of recipients or Data Consumers (aka. document readers) which have already downloaded a document. The platform will trace if a recipient (XDR) or Data Consumer (XDS) has downloaded a document. This is important e.g. in case of cancellation or replacement of a submitted document, which could have an impact on Data Provider s workflows. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. The Data Provider querying for document readers must be the Data Provider which shared the document or another actor for which access has been granted. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction provider 45 ProviderRec 0 Provider identification docref UNIQUEID 1 UUID of the document Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter provider if given, must UnknownProviderException link to a valid registered provider V3 Parameter docref must be a valid unique document identifier of a document which is already stored at the platform. InvalidIdentifierException could occure if reference is not in a valid format. 45 If omitted the identity of the caller is used. Cahier_des_charges_Technique_General_v1.0.docx123/158 Version 1.0,

124 Processing: See also Sequence Diagram for QueryDocumentReaders P1 querydocumentreaders 1 Function called by Data Provider to query for recipients or Document Consumers which downloaded the document. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters must be checked for See Validation section above consistency. P3 createquery 1.2 The XML based representation for the query will be created. Therefore the docref parameters value is used and bound to the query parameter. CreateQueryXmlException P4 signquerydataset 1.3 The xml query document set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P5 registrystoredquery() 1.4 This is the transaction which must be used to retrieve the list of recipients or Data Consumer which downloaded this document registrystoredqueryresponse: A structured InvalidSignatureException XML file will be send back as a response, containing as a result set of the query the list of recipients or Data Consumer which downloaded the document. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. 2 querydocumentreadersresponse: If the transaction succeeds, the success - state with possible warning messages and the list of the document readers (possibly empty) will be send back. Cahier_des_charges_Technique_General_v1.0.docx124/158 Version 1.0,

125 Postconditions: Output Parameter: Comments: The operation of querying for document recipients/data Consumer (document readers) is atomic. If an error occurs the whole transaction will be cancelled. success Failure An empty result set or the list of document readers metadata which are the result of this query are returned. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the query execution. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description resultset String 1 or n Query result set, contains list of document readers, could be empty if no data found messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The definition of the structure of the data for the document readers has to be defined. One possibility would be to return the health professional identifiers together with some short demographic data. The patient himself should not be returned by using his demographic or other identification related data, instead Patient should be returned as a constant. The detailed definition how the platform gathers the information about who has already downloaded the document is not part of this specification. One possibility is mentioned as part of the 3.6 FU-CORE- 4: Retrieve Document Set transaction. A new Registry stored query must be defined, this query is not defined as part of IHE profiles. The platform checks the access rights if the actor who wants to get information about the document readers, has the appropriate rights to retrieve this information. Cahier_des_charges_Technique_General_v1.0.docx125/158 Version 1.0,

126 Sequence Diagram for QueryDocumentReaders Cahier_des_charges_Technique_General_v1.0.docx126/158 Version 1.0,

127 5.4r FU-CON-15: UnblockDocuments ID: FU-CON-15 Name: UnblockDocuments Short Description: This function will be used to unblock already blocked documents for patient s access at platform level. A Data Consumer (could also be the patient himself) which is allowed to, could unblock the document either by providing the appropriate unblocking code, or if he is owner of an adequate role e.g. health professional which has consent to access the document. Actors/Category: A2/A3 Data Consumer layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Consumer is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Consumer must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction consumer 46 ConsumerRec 0 Consumer identification docref UNIQUEID 1 UUID of the document unblockingcode String 0 or 1 Unblocking code to change the access right so that the patient is allowed to access the document Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter provider if given, must UnknownProviderException link to a valid registered provider V3 Parameter docref must be a valid unique document identifier of a document which is already stored at InvalidIdentifierException could occure if reference is not in a valid format. the platform. V4 Parameter unblockingcode if given must be a valid string and must not exceed the max length InvalidLengthException 46 If omitted, the identity of the caller is used. Cahier_des_charges_Technique_General_v1.0.docx127/158 Version 1.0,

128 foreseen for this field. Processing: See also Sequence Diagram for UnblockDocuments P1 unblockdocuments 1 Function called by Data Consumers to unblock a stored document to allow patients access. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters must be checked for See Validation section above consistency. P3 createsubmissionset 1.2 The XML based representation for the metadata update will be created. Therefore the docref parameter and the unblockingcode (if provided) will be used. CreateSubmissionsetException P4 signsubmissionset 1.3 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P5 updatedocumentset 1.4 This is the transaction which must be used for unblocking the document. During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework updatedocumentset: A structured XML file will be sent back as a response, containing a Boolean response value ( True or False ) and a list of warning/error messages if the operation has failed. 2 unblockdocumentsresponse: If the specification (Vol. 3). InvalidSignatureException Cahier_des_charges_Technique_General_v1.0.docx128/158 Version 1.0,

129 Postconditions: Output Parameter: Comments: transaction succeeds, the success state ( True or False ) with possible warning/error messages will be will be sent back. The operation of unblocking documents from patients access is atomic. If an error occurs the whole transaction will be cancelled. success failure True will be returned and the document is now readable by the patient. False will be returned and unblocking of the document failed due to errors described in the messages-parameter. Name Type Cardinality Description success Boolean 1 Response flag if unblocking has been processed successful. messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. A Data Consumer which possesses the unblocking code, has the implicit consent to unblock the document. This function is related to IHE XDS Metadata Update profile which allows changes of metadata for Document Administrators. This actor is grouped for the esanté platform with the Data Consumer. The unblocking operation on platform level supports unblocking with and without an unblocking code. If there is no unblocking code provided, the unblocking operation could only be done by an approved health professional with certain access roles and consent. A patient is only able to unblock documents by using an unblocking code, which is equal to the unblocking code which is stored with the document. To ensure this, the Registry checks if the unblockingcode has been provided by the caller. If so, the document is unblocked because this implies an implicit consent. If the code has not been provided, the Registry must check if the calling actor has consent to change the documents access level (e.g. confidentialitycode). The system must prevent misuse of the function by limiting the unblock attempts for a number of trials related to a time period, to avoid e.g. brute-force attacks. Cahier_des_charges_Technique_General_v1.0.docx129/158 Version 1.0,

130 Sequence Diagram for UnblockDocuments Cahier_des_charges_Technique_General_v1.0.docx130/158 Version 1.0,

131 5.4s FU-CON-16: QueryProvidedDocuments ID: FU-CON-16 Name: QueryProvidedDocuments Short Description: This function will be used to query for the list of documents provided by one Data Provider. It was a requirement defined by the laboratory group, but is not specific for laboratories, therefore it is now a general function. As a result the metadata of all documents provided by the given Data Provider Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction provider 47 ProviderRec 0 Provider identification startdate Date 1 Lower date of the document submission from whereon the documents should be searched enddate Date 0 Upper date, could be null Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter provider if given, must UnknownProviderException link to the valid registered provider V3 Parameter startdate must be a InvalidDateFormatException valid date and must not be a date in the future. V4 Parameter enddate, must be a valid date if given or null. If given it must not be older than startdate. InvalidDateFormatException 47 The original provider for which the already provided documents should be searched for. If omitted the caller of the transaction is used. Cahier_des_charges_Technique_General_v1.0.docx131/158 Version 1.0,

132 Processing: See also Sequence Diagram for QueryProvidedDocuments P1 queryprovideddocuments 1 Function called by Data Provider to query for documents which were provided by him. Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. P2 validateinputparameters 1.1 All input parameters must be checked for See Validation section above consistency. P3 createquery 1.2 The XML based representation for the query will be created. Therefore the parameter values are used and bound to the query parameter. CreateQueryXmlException P4 signquerydataset 1.3 The xml query document set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P5 registrystoredquery() 1.4 This is the transaction which must be used to retrieve the list of document metadata of all documents which are provided from this Data Provider registrystoredqueryresponse: A structured InvalidSignatureException XML file will be send back as a response, containing as a result set the metadata of the provided documents from this Data Provider. The response is electronically signed due to ensure that the data are not corrupted. The signature must be validated before proceeding. 2 queryprovideddocumentsresponse: If the transaction succeeds, the success - state with possible warning messages and the list of the document metadata (possibly empty) will be send back. Cahier_des_charges_Technique_General_v1.0.docx132/158 Version 1.0,

133 Postconditions: Output Parameter: Comments: The operation of querying for document metadata is atomic. If an error occurs the whole transaction will be cancelled. success Failure An empty result set or the metadata of documents which are the result of this query are returned. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the query execution. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description resultset String 1 or n Query result set, contains list of document metadata, could be empty if no data found messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The platform must ensure that a Data Provider using this query could only retrieve information about the documents he has submitted. Additional security permissions are required to query for a given Data Provider which is not the caller of the transaction This could also lead to an additional Use-Case which is not defined yet. Cahier_des_charges_Technique_General_v1.0.docx133/158 Version 1.0,

134 Sequence Diagram for QueryProvidedDocuments Cahier_des_charges_Technique_General_v1.0.docx134/158 Version 1.0,

135 6 Required extensions for the CARA interface Although the general functions of the Connector-API fulfills most of the requirements for sharing medical reports for different medical domains, the functional analysis of the CARA Use-Cases reveals additional requirements which must be met. These requirements and extensions are described in the following sub-chapters. 6.1 Document formats 6.1a CDA radiology report The detailed content structure of the CDA radiology report (CDA-Body) is not defined yet, but the attributes of the CDA-Header are described already in 5.3. For the radiology domain, the creation of the CDA document itself could be done, if supported by the software systems of the Data Providers, based on a transformation of the DICOM SR format as described as part of the DICOM SR Diagnostic Imaging Report Transformation Guide (see 10). 6.1b Key Object Selection Documents (DICOM KOS Documents) Instead of storing the high-res significant images at the esanté platform, only references to those images should be stored at the platform level. As specified in the IHE XDS-I profile, so called Key Object Selection Documents (KOS) which are used as manifest files, contain those references and will be stored at Document Repository level and registered at the Document Registry. A Data Consumer who wants to get access to those documents, has to retrieve the manifest-file from the Document Repository and access the Images by using a WADO Viewer. The content structure of a KOS manifest file is described in the DICOM specification (PS 3.3 Key Object Selection Document (KOS)) and as part of the description of the IHE Radiology profile. The picture below shows some attributes of the KOS manifest file. Cahier_des_charges_Technique_General_v1.0.docx135/158 Version 1.0,

136 6.2 CARA related Data Provider functions We will describe the additional requirements which have to be met when using the Connector-API for sharing of radiology reports and image-manifest files. Therefore we will list the additional constraints for the general functions. Although they are listed here as separate functions, the decision if these requirements lead to new functions to the Connector-API or to just add constraints which could be parameterized and evaluated during the processing, will be left open as a choice. 6.2a FU-CARA-1: SubmitRadiologyReport&ImagesXDR ID: Derived from: FU-CARA-1 Name: SubmitRadiologyReport&ImagesXDR FU-CON-1: SubmitDocumentsXDR Short Description: The caller (Data Provider) provides documents for known recipients (Data Consumer). This function implements the reliable data transmission. Documents which are successfully submitted will be listed in the InBox folder of the recipients. One radiology report together with imaging manifest files could be provided. Additional Constraints Parameter documents constraints: Name Type Cardinality Description radreport DocumentRef 1 Radiology report imgmanifest DocumentRef 0 or n Image manifest files The parameter documents should accept for radiology purpose only one radiology report and could reference up to n image manifest files. Validation constraints: If manifest-file references are given as values for parameter documents, these references must link to valid manifest files with DICOM KOS objects. Comments: Processing step: createsubmissionset : If parameter documents contains a list of manifest files, association objects inside the SubmissionSet have to be created which links the radiology report and the manifest files with the association type APND. Cahier_des_charges_Technique_General_v1.0.docx136/158 Version 1.0,

137 6.2b FU-CARA-2: SubmitRadiologyReport&ImagesXDS ID: Derived from: FU-CARA-2 Name: SubmitRadiologyReport&ImagesXDS FU-CON-2: SubmitDocumentsXDS Short Description: The caller (Data Provider) provides documents which should be stored and linked to the patient s electronic health record. One radiology report together with imaging manifest files could be provided. Additional Constraints Parameter documents constraints: Name Type Cardinality Description radreport DocumentRef 1 Radiology report imgmanifest DocumentRef 0 or n Image manifest files The parameter documents should accept for radiology purpose only one radiology report and could reference up to n image manifest files. Parameter patientreadblocking constraints: Radiology reports are blocked by default, therefore parameter patientreadblocking must be set to True by default, independent if it is set by the Data Provider. An unblockingcode could be stored too, if provided. Validation constraints: If manifest-file references are given as values for parameter documents, these references must link to valid manifest files with DICOM KOS objects. Comments: Processing step: createsubmissionset : If parameter documents contains a list of manifest files, association objects inside the SubmissionSet have to be created which links the radiology report and the manifest files with the association type APPND. Cahier_des_charges_Technique_General_v1.0.docx137/158 Version 1.0,

138 6.2c FU-CARA-3: SubmitAddendumReport&ImagesXDR ID: Derived from: FU-CARA-3 Name: SubmitAddendumReport& ImagesXDR FU-CON-3: SubmitAddendumXDR Short Description: The caller (Data Provider) provides addendum documents for known recipients (Data Consumer). This function could be used to add one Addendum Report to an already existing report, possibly with none or some image manifest files. Additional Constraints Parameter documents constraints: Name Type Cardinality Description radreport DocumentRef 1 Radiology report imgmanifest DocumentRef 0 or n Image manifest files The parameter documents should accept for radiology purpose only one radiology report and could reference up to n image manifest files. Validation constraints: If manifest-file references are given as values for parameter documents, these references must link to valid manifest files with DICOM KOS objects. Comments: Processing step: createsubmissionset : If parameter documents contains a list of manifest files, association objects inside the SubmissionSet have to be created which links the radiology report and the manifest files with the association type APND. Cahier_des_charges_Technique_General_v1.0.docx138/158 Version 1.0,

139 6.2d FU-CARA-4: SubmitAddendumReport&ImagesXDS ID: Derived from: FU-CARA-4 Name: SubmitAddendumReport& ImagesXDS FU-CON-4: SubmitAddendumXDS Short Description: The caller (Data Provider) provides documents which should be stored and linked to an already existing document of the patient s electronic health record. Additional Constraints Parameter addendumdocuments constraints: Name Type Cardinality Description radreport DocumentRef 1 49 Radiology report imgmanifest DocumentRef 0 or n Image manifest files The parameter documents should accept for radiology purpose only one radiology report and could reference up to n image manifest files. Parameter patientreadblocking constraints: Radiology reports are blocked by default, therefore parameter patientreadblocking must be set to True by default, independent if it is set by the Data Provider. An unblockingcode could be stored too, if provided. Validation constraints: If manifest-file references are given as values for parameter addendumdocuments, these references must link to valid manifest files with DICOM KOS objects. Comments: Processing step: createsubmissionset : If parameter addendumdocuments contains a list of manifest files, association objects inside the SubmissionSet have to be created which links the new (addendum) radiology report and the manifest files with the association type APND. The addendum radiology report is linked to the parent document by using an association type APPND as usual. 49 A problem could arise if the Data Provider wants to send additional image-manifest files which should be appended to an already existing report. Although the radreport parameter is specified as mandatory in the functional analysis and therefore in this specification too, it could be necessary to set it as an optional parameter, out of that reason. This has to be evaluated during the pilot implementation phase. Cahier_des_charges_Technique_General_v1.0.docx139/158 Version 1.0,

140 6.2e Other CARA Data Provider related functions The functionality for CARA Data Providers for cancellation or the replacement of documents is similar to those defined in the general Connector-API section. For the XDS transactions the default values for patientreadblocking must be respected. No further extensions are required, the general functions could be used. 6.3 CARA related Data Consumer functions The Data Consumer functions for retrieving radiology reports or manifest files from the platform are similar to the general functions. Therefore no additional extensions are required. The processing of the image-manifest file at Data Consumers side e.g. by processing the file with WADO to retrieve the images, is out of scope of this technical specification. Cahier_des_charges_Technique_General_v1.0.docx140/158 Version 1.0,

141 7 Required extensions for the LABO interface The functional analysis of the LABO Use-Cases reveals additional requirements which must be met. These requirements and extensions are described in the following sub-chapters. 7.1 LABO related Data Provider functions We will describe the additional requirements which have to be met when using the Connector-API for sharing of laboratory reports. Therefore we will list the additional constraints for the general functions. Although they are listed here as separate functions, the decision if these requirements lead to new functions to the Connector-API or to just add constraints which could be parameterized and evaluated during the processing, will be left open as a choice. 7.1a FU-LABO-1: SubmitLaboratoryReportsXDR ID: Derived from: FU-LABO-1 Name: SubmitLaboratoryReportsXDR FU-CON-1: SubmitDocumentsXDR Short Description: The caller (Data Provider) provides laboratory reports (partial of final) for known recipients (Data Consumer). This function implements the reliable data transmission for the submission of a laboratory report. Documents which are successfully submitted will be listed in the InBox folder of the recipients. Additional Constraints Parameter documents constraints: Name Type Cardinality Description labreport DocumentRef 1 Radiology report The parameter documents should accept one laboratory report only. Additional function parameter: Name Type Cardinality Description abnormalresults Boolean 1 Flag to sign if the laboratory report contains result values which are abnormal The parameter abnormalresults should be added. Validation constraints: Parameter abnormalresults must be set and contain a valid Boolean value. Comments: The parameter abnormalresults should be added as a metadata parameter for the Document Registry (see 8.4). The value of the Cahier_des_charges_Technique_General_v1.0.docx141/158 Version 1.0,

142 parameter must be provided as a function parameter of this SubmitLaboratoryReportsXDR function, although the CDA R2 laboratory report would contain for each laboratory result an ObservationInterpretation field. So another solution could be, if the Connector-API is able to parse the laboratory report, to search inside the report for an abnormal result (ObervationInterpretation = abnormal) and set this parameter for the XDSDocumentEntry - metadata of the document while creating the SubmissionSet. In this case no additional function will be required. 7.1b FU-LABO-2: SubmitLaboratoryReportsXDS ID: Derived from: FU-LABO-2 Name: SubmitLaboratoryReportsXDS FU-CON-2: SubmitDocumentsXDS FU-CON-7: ReplaceDocumentXDS Short Description: The caller (Data Provider) provides a laboratory report (partial or final) which should be stored and linked to the patient s electronic health record. The function offers the possibility to initially provide a laboratory report or to add a new report (partial or final) as a replacement of an already existing report. Additional Constraints Parameter documents constraints: Name Type Cardinality Description labreport DocumentRef 1 Laboratory report The parameter documents should accept one laboratory report only. Additional function parameter: Name Type Cardinality Description abnormalresults Boolean 1 Flag to sign if the laboratory report contains result values which are abnormal parentref UNIQUEID 0 or 1 Globally unique identifier of the parent Document instance The parameter abnormalresults should be added. The parameter parentref could contain a reference to an already submitted report. Parameter patientreadblocking constraints: Laboratory reports are not blocked by default, therefore parameter patientreadblocking must be set to False by default. An unblockingcode could be stored too, if provided. Validation constraints: Cahier_des_charges_Technique_General_v1.0.docx142/158 Version 1.0,

143 If parentref identifier is given, it must reference a laboratory report which has already been provided at the platform. Comments: Processing step: createsubmissionset : If parameter parentref is given and valid, an association object must be created which links the new laboratory report (partial or final) with the parent report by using the association type RPLC. Internally this function call could be processed by calling either SubmitDocumentsXDS or ReplaceDocumentXDS dependent on the value of the parameter parentref. Nevertheless the parameter abnormalresults must be processed also. Using this function to store partial or final laboratory reports as replacements change the availability status of the parent laboratory report to deprecated. Partial laboratory reports which replace current reports at the platform, must contain the laboratory results of the replaced reports. Partial reports which only provide additional information without containing the results from the former report are not allowed 50. Replacement of former laboratory reports is conform with the IHE XD- LAB profile specification. This is the only transaction which must be used for providing laboratory reports, addendums to existing laboratory reports are not foreseen c Other LABO Data Provider related functions The functionality for LABO Data Providers for cancellation of reports is similar to that defined in the general Connector-API section. For the XDS transactions the default values for patientreadblocking must be respected. No further extensions are required, the general functions could be used. An additional transaction QueryDocumentReaders which was introduced during the functional analysis of LABO is now integrated as a general transaction of the Connector-API. 7.2 LABO related Data Consumer functions The Data Consumer functions for retrieving laboratory reports from the platform are similar to the general functions. Therefore no additional extensions are required. The transaction to retrieve information about the documents which are provided by one Data Provider, has been moved to the general transaction section. This transaction was originally a requirement defined by the laboratory working group. The processing of the laboratory reports at Data Consumers side is out of scope of this technical specification. 50 Today only one hospital-laboratory is providing incremental partial reports which do not contain the laboratory results of the report provided before. All other laboratories provide partial reports as replacements of the former report, which contain all the laboratory test results. This is conform to IHE XD-LAB profile. 51 So far only replacements of former reports are allowed, as specified by the IHE XD-LAB profile. Nevertheless it could be possible that later-on reports could be appended to an already existing one. We should remain open to APND based solutions as well. But this is not conformant to the IHE XD-LAB profile specification. Cahier_des_charges_Technique_General_v1.0.docx143/158 Version 1.0,

144 8 Required extensions concerning the IHE profiles For the communication with the esanté platform, which is mainly based on IHE XDS.b/XDS-I.b profiles, there are some requirements which could not be fulfilled without extending the given profiles. Especially to ensure security and data privacy, e.g. for the electronic signature and data encryption as defined for the esanté platform, different enhancements in the transactional contexts are needed. Also for the implementation of the functionalities based on the Use-Cases there are some additional requirements which will be described in the following subchapters. 8.1 Messageid as part of the metadata for Submission- and DocumentEntrySet Instead of using the real patient identifier as value for the Submission- and DocumentEntrySet patientid parameter, the Connector-API must ensure that the real patient s identity is hided against the Document Registry/Repository. Therefore during the deidentify-function call, the API retrieves a messageid as a unique identifier for this transaction. Using this messageid, the Document Registry is able to retrieve a patient s pseudonym from the TTP. To be able to transfer the messageid as part of the metadata there are two possibilities: 1. Provide messageid as value of the metadata parameter patientid which is required to be set in the metadata 2. Extend the Submission- and DocumentEntrySet metatadata with a separate parameter for the messageid The first proposed solution will be easier to use because no extension of the metadata-set will be necessary, but there could be a misinterpretation when communicating such information with other systems outside of this Affinity Domain without declaring this concept. Extending the metadata-sets for the introduction of a new parameter for the messageid could be possible, but leads also to incompatibilities with the standard profile definition, as extensions of the standard metadataset are not foreseen although ebxml supports it. 8.2 Patient access blocking and the unblocking code To mark a document as being blocked for patient access, the confidentialitycode metadata parameter could be set on DocumentEntrySet level. The values used for the confidentialitycode could be specifically defined for the esanté platform. Therefore no extension of the metadataset will be necessary. The unblocking code must be stored together with the document metadata in the Document Registry as part of the DocumentEntry metadataset. To transmit the unblocking code with the DocumentEntrySet data during the provideandregister-documentset transaction from Data Provider s side, the unblocking code must be part of the metdataset. Therefore an extension of the DocumentEntry metadataset must be done. Since the confidentialitycode could also be part of the CDA-Header one could mention to also provide the unblocking code as an additional parameter of the CDA-Header. If so, these parameters could only be interpreted at Connector-API Cahier_des_charges_Technique_General_v1.0.docx144/158 Version 1.0,

145 level, since the document itself will be stored encrypted on the platform and so there will be no possibility to extract/interpret this parameters at platform level. 8.3 Referral code As supposed in chapter 5.4o, the referral code will be linked to the XDSFolder.uniqueID. If so, no additional metadata attributes are required. 8.4 Abnormal results flag An additional metadata flag which is required in context of storing laboratory results, to flag a laboratory report which could contain abnormal result values for a laboratory test. This provides the possibility to inform the health professional about the importance of the report. The CDA R2 laboratory report would contain for each laboratory result an ObservationInterpretation field but this could not be interpreted on platform level because the documents are encrypted. 8.5 Security related enhancements The security related requirements of the platform, especially the encryption and decryption of documents using ad-hoc generated Keypairs, lead to additional transactions and data which must be exchanged when sharing documents using the platform. For example before calling the platform function ProvideAndRegisterDocumentSet (see FU-CORE-1), the Connector-API (as Data Provider) must query for the Public-Key of the TTP to encrypt the document. When retrieving a document from the platform in case of using an XDS based sharing method, the Data Consumer must first create an Keypair and share the Public-Key Certificate with the platform during the RetrieveDocumentSet (see FU-CORE-4) transaction. These additional function calls and parameters are not part of the IHE XDS profile definition and also not part of the IHE ATNA profile. The IHE DEN (Document-Encryption) profile describes the principles of document en- /decryption and key management. It doesn t match fully with the requirements for the platform, although it could be the right base for enhancements. We could imagine to add the Public-Key Certificate as an additional XML fragment to the payload communicated with the Document Repository during the RetrieveDocumentSet transaction. Cahier_des_charges_Technique_General_v1.0.docx145/158 Version 1.0,

146 9 Conclusion In this document we described the base functionalities which could be provided by the Connector-API. For the laboratory and radiology domains we described the necessary extensions of the base functionalities to fulfill the additional requirements. The API covers most of the complex communication with the esanté platform and therefore could be the solution for easier integration of the platform functionalities with the systems of the healthcare providers. Although the platform functionalities will be based mainly on IHE profiles (e.g. XDS.b, XDS-I.b), we proposed some extensions to implement the required functionality. Cahier_des_charges_Technique_General_v1.0.docx146/158 Version 1.0,

147 10 References to other documents Title Author Version/Date WP-7 Architecture of the platform CRP Henri Tudor, SANTEC Version 0.89 March 10, 2011 WP-12 CARA Use Cases CRP Henri Tudor, SANTEC Version 2.1 January 11, 2011 IHE IT Infrastructure (ITI) Technical Framework Volume I-III IHE Radiology Technical Framework Volume I - III Imaging Integration implementation Guide for CDA Release 2.0 IHE Patient Care Coordination (PCC) Technical Framework Volume I-II Digital Imaging and Communications in Medicine (DICOM) IHE International, Inc. IHE International, Inc. Revision 7.0 Final Text August 10, 2010 Revision 9.0 Final Text June 27, 2008 HL7 International First Release March 2009 IHE International, Inc. DICOM Standards Committee, Working Group 20 and HL7 Integration Work Group Revision 6.0 Final Text August 30, 2010 Letter Ballot January 27, 2010 Cahier_des_charges_Technique_General_v1.0.docx147/158 Version 1.0,

148 11 Glossary of terms Term Affinity Domain CDA DICOM - KOS - SR - Enhanced SR - SOP - Evidence Documents - Presentation State - WADO Document Registry Document Repository Document Type Description A term used in context with IHE, an affinity domain is a community of healthcare institutions which work together to share clinical documents and agreed of using the same document formats, vocabularies and patient identification domain. Clinical Document Architecture, an XML based standard to specify the structure and semantics of clinical documents. Digital Imaging and Communications in Medicine, defines a document format for medical imaging as well as a communication protocol for the exchange of these documents. DICOM Key Object Selection (KOS) documents are used to contain and mark the significant images for a diagnostic report. DICOM Structured Reports (SR and Enhanced SR) are document architectures for encoding and exchange using the hierarchical structure of DICOM. DICOM Service Object Pair Class (SOP) objects are used as communication objects between systems, for example to call functions of the connected systems. Therefore SOP objects contain a data object (e.g. image) and the action which should be processed, for example to scale this image. DICOM Evidence Documents are based on structured reports (SR) and are used to store information during acquisition or post processing workflows about technical parameters (e.g. dose). DICOM Presentation State Objects contain configuration data about the way an image should be presented e.g. the zoom-level, greyscale, window width. Web Access to DICOM Persistent Objects, is a service for accessing and presenting persistent DICOM objects by using web-based technologies. The document registry is the storage area for document meta-data in the esanté platform. While the content of a document is stored in the Document Repository the meta-data is kept in the registry for querying. A search for documents is always carried out as a query on the registry, never on the repository. The document repository is the storage area for document contents in the esanté platform. Documents are composed of two parts: Meta-data and content. When documents are submitted to the Repository their meta-data is separated from the content and registered in the Document Registry, while the document content is encrypted and stored in the repository. Each registry entry has a back-link to one document content entry in the repository. All documents in esanté are typed according to an internal type system. When submitting a document a valid type must be provided, otherwise the submission fails. For example in case of esanté-cara the possible document types are The actual type names in the formal CDA specification may be different. The present list is given for enumerating the different types that esanté-cara introduces. Cahier_des_charges_Technique_General_v1.0.docx148/158 Version 1.0,

149 Term ebxml esanté platform Health Care Professional Registry IHE Incoming Folder - InBox Images - Illustrative - Significant Description Radiology Report Radiology Addendum Report Radiology Significant Images Radiology Illustrative Images Radiology Appointment Record Electronic Business extensible Markup Language is a set of XML based standards which are used to improve the interoperability to share electronic business information between trading partners. ebxml is also proposed by the IHE for the use as a standard in IHE profiles for cross-enterprise sharing of medical documents (XDS). The overall IT system that delivers the services and functions described in this series of use cases. Its main purpose is to store medical data related to patients in the Luxemburgish health care system, and to facilitate the secure and controlled exchange of data among its different actors. Beside data storage and transfer services the esanté platform will provide other related services such as a Notification Service, the Patient Consent Management Service etc. Or HCP Registry. A component of the esanté platform that represents a register of all HCPs that participate in the system. It provides registry and identification services for the HCPs working with esanté. Only registered HCPs can access patient health care information from esanté, and contribute own information to it. Integrating the Healthcare Enterprise (IHE), is a non-profit organization founded by healthcare professionals and the industry to improve the electronic information exchange in the healthcare sector. Also referred to as InBox folder, because of certain similarities with the system. Each HCP who is enrolled as a user in the esanté platform has his own, private Inbox that only he himself can access. Patients can also be users of esanté, but do not have an Inbox 53. The Inbox serves as a temporary storage for documents delivered through the reliable transmission channel. HCPs connected to esanté can see the content of their Inbox and download all documents contained in it. Once downloaded the documents are removed, similar to the download-and-delete mode of the Post Office Protocol (POP) for delivery. The illustrative images are the key images which are used to explain the diagnosis and are derived from the significant images. They could be part of the radiology report and are low-resolution images e.g. in JPEG format and therefore could not be used for the medical examination by radiologists. The significant images are used by the radiologists for diagnosis purpose. They are high-resolution images which are usually stored in 53 At least not in the first version of the platform. Cahier_des_charges_Technique_General_v1.0.docx149/158 Version 1.0,

150 Term MIME MTOM Description the PACS system and could be used by other radiologists too, e.g. for gathering a second opinion on a diagnosis. Multipurpose Internet Mail Extensions is used to describe the type of content (content-type) which will be exchanged between a sender and receiver. MIME types are used for example in context of electronic mail ( ). The MIME types are used in our context as values for the mimetype field of the XDSDocumentEntrySet metadata structure. Message Transfer Optimization Mechanism, is a commonly used technology for the transfer of binary data when using SOAP messages, for example to receive and send binary data using Web services. Notification Service Sub-system of the esanté platform that can be used to subscribe / unsubscribe to a notification service. This service automatically generates messages at specific events, such as the availability of new radiology exam data, or access to a patient s medical record. OID PACS Radiology data SAML SOAP SQL Object Identifier (OID) is a (worldwide) unique identifier for information objects. Each OID is a node of a hierarchical namespace which is defined by the ASN.1 standard. OIDs are represented by a sequence of numbers, e.g starting from the root (here 1). New OIDs as sub-nodes must be requested by the responsible person of the upper node. Picture Archiving and Communication System, is used in the healthcare sector mainly as an electronic archive for the storage and retrieval of digital images from different sources, e.g. CT, MR. Refers to radiology reports as well as significant and illustrative images in relation to such report. Meta information such as the date of creation, a subject/label, the type of data (several types of images, reports) and the producer of the data are also considered as radiology data. In addition a patient s appointments for a radiologic exam, together with relevant meta data, are also considered as radiology data. Security Assertion Markup Language, defines an XML-based structure which could be used as part of SOAP messages for the exchange of authentication and authorization information between security domains. SOAP nowadays a term of its own (formerly known as Simple Object Access Protocol), is an XML based communication protocol specification for the exchange of data which is mostly used in conjunction with Web services. Structured query language is a computer language which is used to query or manipulate relational databases. The language could be semantically devided into commands for data manipulation (DML, data manipulation language e.g. select, update, insert, delete) or data definition (DDL, data definition language e.g. create, alter, drop). Cahier_des_charges_Technique_General_v1.0.docx150/158 Version 1.0,

151 Term SubmissionSet TTP UTC UUID XML Description Because the database for the Document Registry relies on a relational database structure, SQL is needed to access and query the data. A SubmissionSet also called as XDSSubmissionSet inside this document, is a well defined XML based container which could contain other structured XML documents as inner XML segments. The definition of IHE s XDSSubmissionSet is based on the definition from ebxml and extended to cover the informations for the healthcare domain. The Trusted Third Party is a system that offers a number of security related services and functions to the esanté platform such as: Secure Patient Registry, which holds the registry of all patients known to esanté. Master Patient Index, an extension of the Patient Registry service which allows that patient identification data sets from multiple sources can be matched with one and the same patient. De-identification and pseudonymisation. Instead of returning a unique ID for a patient match, the TTP produces and returns pseudonyms when queried with valid patient identification information. Key management for document encryption. The TTP provides public key certificates that are used in the document encryption process. Coordinated Universal Time is the worlds primary time standard used in many Internet and WWW standards and is based on the International Atomic Time. Typically if fractions of a second are not important, it corresponds to GMT (Greenwich Mean Time). The relation between different time zones could be expressed in reference to UTC, by adding/subtraction of hours e.g. UTC+2. Universally Unique Identifiers are system-generated IDs that guarantee practical uniqueness 54 across decentralized systems. The intent of UUIDs is to enable distributed systems to uniquely identify information without significant central coordination. Thus, anyone can create a UUID and use it to identify something with reasonable confidence that the identifier will never be unintentionally used by anyone for anything else. Information labeled with UUIDs can therefore be later combined into a single database without needing to resolve name conflicts. See for the full article Extensible Markup Language, a text based document standard for the encoding of information in machine processable and human-readable form. 54 In contrast to theoretical uniqueness, which cannot be claimed because of the technical length limitation of a UUUID (usually 16 byte = 128 bit). Cahier_des_charges_Technique_General_v1.0.docx151/158 Version 1.0,

152 Term XOP Description XML-binary Optimized Packaging, is a mechanism also used with MTOM, to process XML files which contain binary data more efficiently, by separating the binary block from the xml textual part when serializing (e.g. for network transport) or storing the documents. Appendix A: FU-CARA-XX: SubmitAppointmentInfoXDS (optional) In this chapter we will describe the technical concept of sharing appointment information for radiology examinations of a patient, using the technologies which are foreseen for the XDS based esanté platform, as specified in the Cahier des charges fonctionnel. The aim for sharing this information is to provide radiologists or doctors the possibility to be informed about a patients appointment history, to be able to validate if a patient has claimed the treatment. It is not ment for appointment scheduling between patients and healthcare professionals (e.g. hospitals, other institutions). ID: FU-CARA-XX Name: SubmitAppointmentInfoXDS Short Description: The caller (Data Provider) provides appointment documents which should be stored and linked to the patient s electronic health record. Actors/Category: A1 Data Provider layer function System component: Trigger event: Preconditions: Connector API User interaction The Data Provider is already registered at the esanté platform as a user and the system granted him the access to the functions after checking his appropriate rights. The actor knows the patient and offers demographic data of the patient. The Data Provider creates a special CDA R2 document as an appointment document. The document should be signed electronically by the Data Provider. The Data Provider must be able to create a unique identifier for the transaction, which must be an UUID. Input Parameters: Name Type Cardinality Description transactionid UUID 1 Unique identifier for this transaction patient PatientRec 1 Patient s demographic data provider ProviderRec 1 Provider identification title String 0 or 1 Text which describes the transaction Cahier_des_charges_Technique_General_v1.0.docx152/158 Version 1.0,

153 comment String 0 or 1 Additional description text appointment DocumentRef 1 Appointment document appointmentref UNIQUEID 0 or 1 Globally unique identifier of the parent appointment document Validation: ID Validation Exceptions V1 Parameter transactionid must be InvalidUuidExeption a valid unique identifier by terms of an UUID. V2 Parameter patient must contain PatientIdentException valid values for all mandatory fields. V3 Parameter provider must link to a UnknownProviderException valid registered provider V4 Parameter title must be a valid InvalidLengthException string and must not be larger than the defined number of chars for this field V5 Parameter comment must be a InvalidLengthException valid string and must not be larger than the defined number of chars for this field V6 Parameter appointment must contain a reference to valid appointment-report in HL7-CDA R2 format, providing the mandatory fields described in Appendix B. Different Exceptions could occur e.g. InvalidURLException or other Exceptions depending on the document format and V7 V8 Parameter appointmentref must contain a valid unique identifier of the parent appointment document Validate the electronic signature. The appointment document should be digitally signed and contain a qualified digital signature with certified timestamp from a timestamp service. Signature related data must be compliant to the Data Providers identity. Processing: See also Sequence Diagram for SubmitAppointmentInfoXDS P1 submitappointmentinfoxds content. InvalidIdentifierException could occure if reference is not in a valid format. NoSignatureFoundException InvalidSignatureException Cahier_des_charges_Technique_General_v1.0.docx153/158 Version 1.0,

154 1 Function called by Data Provider to submit the appointment document to the patients electronic health record at the esanté platform. P2 validateinputparameters Different Exceptions could occur during the whole transaction and are listed at subsequent processing steps. 1.1 All input parameters including the appointment file must be checked for consistency. Electronic signature of the appointment document will be checked if exists. See Validation section above P3 extractheaderdata 1.2 Data of the required fields from the CDA R2 Header of the appointment document are extracted for further use (e.g. when creating the SubmissionSet and DocumentEntrySet structures). Values for required fields must be present and valid, Patient related data must be compliant to the data in the patient Parameter from the PatientRec. ParameterException P4 deidentify 1.3 Patient identifying data (Parameter IdentityMatchException patient ) are used for matching the patient with the right identity, the appropriate pseudonym must be found. 1.4 deidentify response: A messageid corresponding to this TTP transaction. The messageid must be used later on as a replacement for the patientid. P5 checkconsent 1.5 Using the messageid from the TTP, it is NoConsentException checked if a patient has given consent to share his medical data inside a longitudinal electronic health record. If consent has been given, true should be returned, false otherwise. P6 getpublickeycertificate 1.6 Using this function the TTP is called to CertificateException provide a Public-Key Certificate getpublickeycertificate response: The Public-Key Certificate is responded by the TTP. This certificate must be an X.509 Cahier_des_charges_Technique_General_v1.0.docx154/158 Version 1.0,

155 P7 compliant certificate which contains the public-key gained from the TTP, which will be used for data encryption. This public-key certificate must be validated. encryptdocuments 1.7 The appointment document is encrypted before it can be delivered to the platform. The encryption procedure must use the public-key gained before from the TTP for the encryption of the files. EncryptionException P8 createsubmissionset 1.8 Creates and prepares the XML based representation of the metadata and embeds the document for transmission to the platform. A unique identifier must be created for the embedded document. The messageid must be used as patientid. If parameter appointmentref is not null an association object inside the SubmissionSet must be created which links the new appointment document with the parent appointment document using the association type RPLC. CreateSubmissionsetException P9 signsubmissionset 1.9 The submission set will be electronically signed to prevent it against data corruption. The signature algorithm should use the private-key of the Connector for signature creation. CreateSignatureException P9 provideandregisterdocumentset 1.9 This is the transaction which must be used to transfer the appointment from the local institution/health professionals to the esanté platform. Therefore the created SubmissionSet is used provideandregisterdocumentsetresponse: A structured XML file will be send back as a response of the provideandregisterdocumentset transaction. 2 submitappointmentinfoxds - Response: If the During the execution of the platform transaction, different Exceptions could occur, e.g. XDSRegistryNotAvailable if the Registry connection could not be established. These exceptions are part of the IHE Technical Framework specification (Vol. 3). Cahier_des_charges_Technique_General_v1.0.docx155/158 Version 1.0,

156 transaction succeeds the success - state and possibly a list of warnings will be send back. Postconditions: Output Parameter: Comments: The operation of transmitting and storing the appointment for sharing with the esanté platform is atomic. If an error occurs which prevents the delivery of the appointment or the reference between the appointments, the whole transaction will be cancelled. success failure The appointment is shared and accessible for authorized users. The parameter messages could contain an array with warning messages, but not with an error. An error occurred during the appointment sharing. The parameter messages contains the list of errors which occurred. Name Type Cardinality Description success Boolean 1 True/False messages String[] 0 or 1 Message e.g. warnings/errors The output parameters are encapsulated inside of a XML structure. The Data Provider creates and provides the unique identifier for the transaction (UUID) as well as the unique identifiers (uniqueid) for the documents (e.g. as part of the CDA document header, ClinicalDocument/id) and therefore will be able to reference to these transaction/document. Notification of the users (e.g. patient, reference doctor of the patient) who have subscribed to be noticed about the arrival of new appointment document is done by the Notification Service. The Notification Service itself gets the event from the Document Registry which is shown in the sequence diagram by the notify() call between both services. The process of retrieving an appointment document from the platform is similar to the process of RetrieveDocumentXDS. Cahier_des_charges_Technique_General_v1.0.docx156/158 Version 1.0,

157 Sequence Diagram for SubmitAppointmentInfoXDS Cahier_des_charges_Technique_General_v1.0.docx157/158 Version 1.0,

158 Appendix B: CDA R2 document format for the appointment document The appointment document should be based on a CDA R2 document structure, as defined in the Cahier des charges fonctionnel. As described there, the main important elements of the document should be the type (e.g. new, reschedule or cancel ), patient, date, time, institution, address, exams type and modality data. Without describing the detailed content structure of the body of such an appointment CDA document, which is not yet defined, there are some important requirements for the CDA-Header. Those requirements are based on the information needed to provide metadata of the document at Document Registry level and the mandatory fields of the CDA header itself. The CDA header fields and their mapping to the fields of the XDSDocumentEntry metadata are the same as for other document types (described in the General requirements Document). To be able to distinguish between the different appointment types, even on metadata level, the Data Provider should provide this information as part of the CDA document header. The Connector-API would then be able to extract this information and map it into the metadata for XDS. Therefore the value for the ClinicalDocument.code attribute could be used and be mapped to the XDSDocumentEntry.classCode and XDSDocumentEntry.typeCode. The result values of such an mapping could be: XDSDocumentEntry.classCode: - Appointment XDSDocumentEntry.typeCode: - Radiology Appointment submission - Radiology Appointment reschedule - Radiology Appointment cancellation Another possibility for the mapping of the different appointment types to the appropriate XDSDocumentEntry metadata could be done by providing the type of the appointment also as an parameter of the appointment submission function. Cahier_des_charges_Technique_General_v1.0.docx158/158 Version 1.0,