D1.4 Testing and assessment

This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Grant Agreement No. 875299 Project acronym: UNICOM Project full title: Up-scaling the global univocal identification of medicines in the context of Digital Single Market strategy Call identifier: H2020-SC1-DTH-2019 Deliverable 1.4: Testing and assessment Version: 1 Status: Final Dissemination Level1: PU Due date of deliverable: 15.04.2024 Actual submission date: 28.05.2024 Work Package: WP 1 Lead partner for this deliverable: IHE-Europe Partner(s) contributing: IHE-Europe, Nictiz, CEN TC-251 Deliverable type 2 : R / P / DEM / DEC / Other Main author(s): José Costa Teixeira IHE-Europe Sofia Franconi IHE-Europe Derek Ritz IHE-Europe 1 Dissemination level: PU: Public; CO: Confidential, only for members of the consortium (including the Commission Services); EU-RES: Classified Information: RESTREINT UE (Commission Decision 2005/444/EC); EU-CON: Classified Information: CONFIDENTIEL UE (Commission Decision 2005/444/EC); EU-SEC Classified Information: SECRET UE (Commission Decision 2005/444/EC) 2 Type of the deliverable: R: Document, report; DEM: Demonstrator, pilot, prototype; DEC: Websites, patent fillings, videos, etc.; OTHER; ETHICS: Ethics requirement; ORDP: Open Research Data Pilot Resource consumption estimate: Person months Ref. Ares(2024)3859000 - 29/05/2024 UNICOM – T1.4 Testing and assessment Page 2 of 27 Revision history Version Date Changes made Author(s) 0.1 07-12-2021 First version of the document, structure and introduction Karima Bourquard Sofia Franconi 0.2 17-01-2022 Structure and new sections update Karima Bourquard Sofia Franconi 0.3 13-10-2022 General update Sofia Franconi 0.4 10-02-2023 Adding of the part 4 and update of the other parts Sofia Franconi Derek Ritz José Costa Teixeira 0.5 22-03-2023 Finalization of the document send for internal review Sofia Franconi Derek Ritz José Costa Teixeira 0.6 15-04-2024 Final version of the document after review by WP1 Sofia Franconi Esther Peelen Robert Stegwee Zain Ishfaq 1 Submission Statement of originality This deliverable contains original unpublished work except where clearly indicated otherwise. Acknowledgement of previously published material and of the work of others has been made through appropriate citation, quotation or both. UNICOM – T1.4 Testing and assessment Page 3 of 27 Deliverable abstract The Task 1.5 of the UNICOM project focuses on summarizing all testing activities across its work packages and Testing Lab initiatives to ensure the correct implementation of Identification of Medicinal Products (IDMP) standards. This effort aims to enhance patient safety and healthcare efficiency. The deliverable is divided in two parts: 1. Testing Activities Across UNICOM Work Packages: In WP3, adaptation of application forms and tools to IDMP standards is underway, with testing emphasizing portal implementations, PDF creation, integration, and signature services. WP5, WP6, and WP7 collaborate to integrate IDMP into eHealth services, establishing a Software Factory in WP6 to develop testing tools. The IHE Methodology guides effective use case definition, aligns standards through HL7 collaboration, designs interopera bility architectures, and proposes modular transactions supporting various IDMP adoption approaches, focusing on FHIR specifications. The IHE methodology serves as a guiding framework, facilitating collaboration, refining standards, and designing interoperability profiles. WP8 targets patient safety enhancement through eDispensation and clinical decision support systems, testing IDMP application in big data for scientific reports. WP9 ensures compliance of medicinal product dictionaries with IDMP standards, with testing centered on data analysis and compliance measurement. 2. UNICOM Test Lab Initiative and Pipeline Metaphor: The UNICOM Test Lab initiative, aligned with the IHE methodology, aims to validate and test tools for IDMP standards implementation, striving for semantic interoperability and fostering a safe and efficient pharmaceutical supply chain within the EU. Operating within a metaphorical data pipeline, it facilitates the flow of IDMP content among stakeholders. Key activities include regulatory data submission, populating Master Product Databases, managing ePrescription/eDispensation, and facilitating cross-border data sharing. Testing involves various stakeholders to ensure conformance to standards and interoperability specifications, promoting standardized practices and efficient healthcare delivery across borders. Keywords: IDPM, IHE Methodology, HL7 FHIR, Testing, Test Lab This document contains material, which is the copyright of the members of the UNICOM consortium listed above, and may not be reproduced or copied without their permission. The commercial use of any information contained in this document may require a license from the owner of that information. This document reflects only the views of the authors, and the European Commission is not liable for any use that may be made of its contents. The information in this document is provided “as is”, without warranty of any kind, and accept no liability for loss or damage suffered by any person using this information. © 2019-2024. The participants of the UNICOM project. UNICOM – T1.4 Testing and assessment Page 4 of 27 TABLE OF CONTENTS Revision history ....................................................................................................................................... 2 Deliverable abstract ................................................................................................................................. 3 List of abbreviations ................................................................................................................................. 6 1 Introduction ....................................................................................................................................... 7 2 Background ...................................................................................................................................... 8 3 Testing activities across UNICOM WPs ........................................................................................... 9 3.1 WP3 Pan-European IDMP compliant application forms .......................................................... 9 3.2 WP5, WP6 and WP7 ............................................................................................................... 9 3.3 WP8 Clinical Care, Patients, Pharmacies, Research and Pharmacovigilance ..................... 11 3.4 WP9 Medicinal Product Dictionaries and Clinical System Software ..................................... 11 3.5 IHE Methodology: Use cases, Standards, specifications ...................................................... 12 3.5.1 Use Cases and requirements ............................................................................................ 12 3.5.2 Standards – Collaboration, improvement and feedback ................................................... 12 3.5.3 IHE interoperability architecture ........................................................................................ 12 3.5.3.1. Requirements Analysis .................................................................................................. 12 3.5.3.2. Interoperability framework ............................................................................................. 12 4 Support the UNICOM Test Lab use cases ..................................................................................... 14 4.1 UNICOM data pipeline ........................................................................................................... 14 4.2 Breaking down the pipeline into component transactions ..................................................... 14 4.2.1 Inputs to Regulators........................................................................................................... 15 4.2.2 Populating an MPD ............................................................................................................ 16 4.2.3 Creating and Persisting ePrescription / eDispensation ..................................................... 18 4.2.4 Cross-border Sharing of ePrescription / eDispensation .................................................... 20 5 Conclusion ...................................................................................................................................... 27 LIST OF FIGURES Figure 1 - 5 ISO standards used to identify medicinal products .............................................................. 8 Figure 2 - UNICOM Data Pipeline ......................................................................................................... 14 Figure 3 - Submitting Medicinal Product Information to a Regulator..................................................... 15 Figure 4 - Populating an MPD ............................................................................................................... 16 Figure 5 - Comparing HL7 FHIR Data Models for MedicationKnowledge and Medication ................... 16 Figure 6 - Save an ePrescription ........................................................................................................... 18 Figure 7 - Retrieve ePrescription into PFA ............................................................................................ 19 UNICOM – T1.4 Testing and assessment Page 5 of 27 Figure 8 - epSOS Healthcare Provider Authentication and Patient Identification ................................. 21 Figure 9 - epSOS Cross-border IHE Profiles ........................................................................................ 21 Figure 10 - Retrieve ePrescription from Country-A to Country-B .......................................................... 22 Figure 11 - Execute the safe substitution logic...................................................................................... 23 Figure 12 - Save the eDispensation from Country-B to Country-A ....................................................... 24 UNICOM – T1.4 Testing and assessment Page 6 of 27 List of abbreviations Abbreviation Complete form ADE Adverse drug event EDQM European Directorate for the Quality of Medicines EMA European Medicines Agency EMVO European Medicines Verification Organisation GTIN Global Trade Item Number IDMP Identification of Medicinal Products ISO International Organisation for Standardisation MA Marketing authorisation MPD Medicinal product dictionary MPID Medicinal product identifier NCA National competent authority PCID Packaged medicinal product identifier PhPID Pharmaceutical product identifier WHO World Health Organization UNICOM – T1.4 Testing and assessment Page 7 of 27 1 Introduction UNICOM is about improved patient safety and better healthcare for all. To contribute to this vision, this European Commission supported Innovation Action focuses on implementing the International Organization for Standardization (ISO) suite of IDMP (IDentification of Medicinal Products) standards. Work involves their further development, testing, implementation, and diffusion. UNICOM partners include national medicines authorities across Europe, healthcare organisations, standardisation bodies, health ICT companies, SMEs and research institutes. They are working together to enable the many existing databases and products that include medicines information to be adapted towards and incorporate IDMP compatible data fields and attributes, so that all sources of medicines information become semantically interoperable, can be accurately cross-referenced with each other, integrated and analysed nationally, European-wide and at the global level. The task T1.5 will report all testing and assessment activities that are performed in other WPs and that need to take place in the future in order to assure proper compliance and interoperability across the full spectrum of IDMP applications. It will also secure that the tooling and procedures remain available beyond the duration of the project. To sustain the task T1.5, both WP1 and WP6 co-created the UNICOM Test Lab. This initiative unites a diverse range of stakeholders from the project, including national medicines authorities, healthcare organizations, and IT companies, to enable the seamless exchange of medicinal product information. Section 4 of the document will provide more details about the principles behind the test lab. The result of this task is a report on the testing profiles, Projectathon and IDMP related data exchanges. The deliverable includes the following sections: ► The section 1 is the current introduction of the document, ► The section 2 gives context and background to the document ► The section 3 is stating the different testing and assessment activities across all UNICOM WPs ► The section 4 drives us through the test lab activities and the use cases ► The section 5 is the conclusion of the document UNICOM – T1.4 Testing and assessment Page 8 of 27 2 Background Information in healthcare is enormously complex, covering many different types of data. This information needs to be aggregated and shared across different healthcare settings to deliver citizen centric healthcare. The absence of clear and concise identification of medicines may have a negative impact on the safe delivery of (cross-border) healthcare. In response, the European eHealth Digital Service Infrastructure (eHDSI) was set up to manage the initial deployment and operation of services for cross-border health data exchange under the Connecting Europe Facility (CEF). eHDSI sets up and starts deploying the core and generic services, as defined in the CEF, for Patient Summary and ePrescription. The generic services are the necessary implementation of data exchange at country level, the core services at EU level. These together enable the provision of Cross-Border eHealth Information Services (CBeHIS) and is offered to the European Member States under the name of ‘MyHealth@EU’. Building on this, another EU initiative is the development of the UNICOM project. This work aims to support the implementation of a number of use cases including the implementation of IDMP as a global and univocal identification of medicines for cross-border ePrescribing and eDispensation. The Identification of Medicinal Products (IDMP), is a set of five different ISO standard specifications used to identify medicinal products. It defines the data elements and structures for the unique identification and exchange of medicinal products information. This approach to medicine identification aims to ensure better safety to the patients at national or cross-border levels within Europe and beyond. Figure 1 - 5 ISO standards used to identify medicinal products To support the delivery of IDMP, the UNICOM project involves a number of Work Packages, each relating to different aspects of interoperability, business data and technology implementations. Inside UNICOM, WP1 is focused on the universal use of IDMP and its related standards and terminologies. This document is part of the WP1 work and documents all testing and assessment activities that are performed in other WPs during the course of the project. The goal is to provide a resource of testing profiles, tools and procedures to ensure IDMP compliance in future implementations, as well as an overview of further work to be carried out on developing these resources. UNICOM – T1.4 Testing and assessment Page 9 of 27 3 Testing activities across UNICOM WPs The testing in the UNICOM project concerns other WPs. This section proposes an overview of the tasks performed by the different WPs that include or are related to testing. The relevant tasks and documents are quickly summarized with the relevant testing or assessment information. More information about the performed activities can be directly accessed in the deliverable indicated. When describing testing-related activities, this document references the IHE methodology (see 3.5 for a description), which includes definition of the use cases, selection and refinement of standards, and designing of technical specifications that can be used in the different systems that implement IDMP in cross-border regulatory and clinical data exchange. The IHE specifications come in the form of interoperability profiles. Interoperability profiles consist of transactions, which are structured data exchange specifications for the fulfilment of specific modular use cases. IDMP adoption means that systems correctly use and exchange IDMP data in their activities – from manufacturing and regulatory to clinical care and product supply and monitoring. As a result of UNICOM and related activities, it has been observed and documented that “exchanging IDMP data” doesn’t mean exchanging only the complete IDMP data. The interoperability profiles specify which parts of IDMP data need to be exchanged in different use cases depending on the specific goals of these use cases. 3.1 WP3 Pan-European IDMP compliant application forms The aim of this work package is to adapt the application forms and required tools towards the IDMP standards and to increase the usage of EMA’s SPOR. The task T3.4 technical implementation of IDMP-compliant application forms for new marketing authorisations, variations and renewals in the CESP (Common European Submission Portal) dataset module performed several tests activities such as: ► Portal Implementations: Testing the implementation and integration of web portals for various application forms, including variations, product forms, and marketing authorization applications, with completion rates ranging from 0% to 100%. ► Automatic creation of eAF (electronic Application Form) PDF representation: Testing the development of a .NET Azure Function to generate NtA-compliant (Notice to Applicant) variation PDFs from FHIR bundles, with completion rates varying for different forms and a roadmap outlined for future enhancements. ► Integration: Testing the integration of user management systems with EMA's Identity and Access Management, enhancing SPOR integration for better user experience, and enabling PMS (Product Management Services) integration for standardized selection of medicinal products. ► PDF Signature Service: Testing the development of a Signature Service module using a digital certificate to sign PDFs, ensuring data integrity within official service-generated PDFs, and planning integration with the PDF generator for a streamlined process. 3.2 WP5, WP6 and WP7 WP5, WP6 and WP7 have been working jointly in the UNICOM project. UNICOM – T1.4 Testing and assessment Page 16 of 27 eCTD v4 standard. A regionalization of this global spec will be defined in Volume-4 of the IHE spec. This regionalization (for Europe) will describe the content specializations introduced in EMA’s implementation guide. Artefacts of the IHE Pharmacy technical committee are found at their website.8 To support the ongoing progression of UNICOM, post project, UNICOM’s NCA participants will be invited to contribute to the development of the conformance-testable IHE Profiles that operationalize this workflow. The IHE Gazelle platform may be employed by NCAs to support conformance test events of the relevant interoperability specifications. 4.2.2 Populating an MPD Figure 4 - Populating an MPD Three crucial workflow processes are pictorially illustrated by Figure 4. In the first of these, we see that an IDMP MPD Data Requestor actor retrieves IDMP MPD Data from an IDMP MPD Data Responder. Continuing to leverage our fictitious characters from IDMP in a Capsule, we can suggest that the “HealthApp digital health solution is retrieving clinical information about the new SweetDreams product from Z-Index (the Dutch MPD)”. This simple actor-transaction pair, however, surfaces some of the truly challenging aspects related to our UNICOM data pipeline. One of these is the non-trivial workflow that maps IDMP-conformant regulatory content to the clinical content models that drive care delivery. Figure 5 - Comparing HL7 FHIR Data Models for MedicationKnowledge and Medication 8 https://www.ihe.net/ihe_domains/pharmacy/ QA/QC of legacy data transformation OUTPUT-from-Regulator: •Content feed from NCAs to MPD operators •Content feed from NCAs to NCPeH operators Mapping from a regulatory data model to a care delivery data model. IDMP MPD Data Requester IDMP MPD Data Responder IDMP MPD Data Sweet D r eams Clinical Information IDMP Regulatory Data Sender IDMP Regulatory Data Receiver IDMP Regulatory Data M&P Co . Sweet D r eams Regulatory Submission MedicationKnowledge Medication UNICOM – T1.4 Testing and assessment Page 17 of 27 The nature of this challenge is illustrated by Figure 5. There is a significant difference in the level of precision and the level of complexity between the data models needed to serve regulatory purposes (e.g. the IDMP-based HL7 FHIR MedicationKnowledge resource) and the data models needed to support care delivery (e.g. the HL7 FHIR Medication resource). Returning to Figure 4 – From the IDMP Regulatory data content model to a data content model useable in clinical settings, often presented in a MPD. Numerous issues need to be addressed9 for this mapping to be successfully accomplished: • To use the IDMP-based regulatory data in clinical environment, a subset of these data elements is needed. The core medication data must be extracted from the full IDMP-conformant data structure while ensuring the resulting data model sufficiently describes of all possible product types (including combination packages). To benefit from the harmonisation work that has been accomplished in the regulatory domain (EMA and NCAs), the simplification of IDMP data must be done the same way by all the member states. Otherwise, we would continue to see different representations of the same products coming from different countries, and interoperability across borders would not be achieved. • MyHealth@EU cross-border services that use medication data have been revised during the UNICOM project, and the change proposals regarding IDMP-compatible representation of medication data have been implemented (see WP5 deliverables mentioned in section 3 of the document). At present, cross-border services using CDA do not need significant further activities regarding ISO IDMP implementation. Such is not the case for those member states who wish to employ the HL7 FHIR standards, however. Currently, the HL7 FHIR Medication resource does not meet the business requirements set in MyHealth@EU services. Analysing the extensions used in different national implementations, it becomes evident that European national and cross-border needs are not significantly different. Presently, HL7 has not defined extensions for Medication resource in the base specification. There is a risk that different implementers may create their own extensions and workarounds to fulfil the same needs. This could de-harmonise the medication data in clinical workflows and negatively impact the quality and safety of cross-border services. • It is at the MPD level that virtual medicinal product (VMP) codes are introduced. At present, no consistent standard has been adopted across members states regarding how VMPs are to be created, VMP is country-specific and very much dependent on the model of representation in the MPD. Importantly, the VMP plays a key role in determining the allowable substitutions for a medicinal product. Consistency in developing VMP codes has potential patient safety implications and could impact how successfully member states are able (internally) to deal with shortages. • As a practical matter, it can be expected that national drug identifiers will continue to be employed. The mapping from EMA’s pan-European IDs to the local IDs used to support domestic care delivery networks has cross-border implications. The ways GS1 codes (such as the GTIN) may be leveraged to address such challenges has not been well explored within UNICOM. The third workflow illustrated in Figure 4 relates to the creation, by NCAs, of IDMP-conformant data sets within their internal data processing systems. To move to full IDMP-conformance, each NCA will need to undertake legacy data conversion processes. It is anticipated that quality assurance and quality control (QA/QC) of these transformation workflows represents a shared challenge that could benefit from a set of common approaches and, possibly, common test tools. Testing As may be noted from Figure 4, testing of these workflows relies on participation from NCAs, (potentially) from MPD operating agencies or private sector MPD solution providers, and (potentially) from national digital health agencies / NCPeH operators. 9 This section benefitted greatly from a Non-paper on IDMP Implementation Challenges authored as a discussion document by Rutt Lindstrom UNICOM – T1.4 Testing and assessment Page 18 of 27 There has not been active testing of this workflow; rather, the focus of Test Lab activities has been to surface the requirements. The way MPDs are operationalized differs from member state to member state. In some, the MPD is operated by the NCA. In others, there is a completely separate agency of the government tasked with operating the MPD. Some rely on multiple private sector MPDs (and in these contexts, there is often a government agency coordination of the market players to ensure all are adherent to, for example, the same VMP logic). A set of discussion aids (a “card game” and companion online tool) were developed that help MSs to appreciate the implications of their MPD-related decisions. A framework for QA/QC testing of regulatory data sets was also developed and the reference implementation (see section xx) may be leveraged to assist in establishing conformance of data sets expressed using the HL7 FHIR standard. Ongoing efforts within the HL7 and IHE standards organizations will be informed by these efforts, issues were submitted following the common HL7/IHE methodology). Implementable and conformance testable IHE Profiles that reference these underlying FHIR standards are being developed. To support the ongoing progression of UNICOM, post project, NCA and MPD teammates will be invited to engage in the HL7 and IHE Pharmacy committee efforts. It can be expected that SDO artefacts related to UNICOM will be governed by their respective bodies (e.g. HL7 Europe, IHE-Europe). 4.2.3 Creating and Persisting ePrescription / eDispensation Save an ePrescription or eDispensation Figure 6 - Save an ePrescription As noted in Figure 6, there exist mature, conformance-testable specifications related to creating an ePrescription and persisting it to the local data repositories that serve domestic care delivery networks. In Europe, the CDA-over-XDS family of IHE specifications are used to operationalize this workflow. A Content Creator actor builds the ePrescription CDA in accordance with the eHealth Network guideline’s normative specification related to this digital health document.10 The Content Creator is grouped with a Document Source actor that persists this document to a Document Repository actor, which is, in turn, grouped with the Content Consumer. The pattern of content exchange is described in IHE’s Document Sharing Health Information Exchange white paper.11 The following important points should be noted, here: • The ePrescribing pattern is the same for Generic Prescriptions, which are described in the eHealth Network specification as “the prescription of medication by a health professional using the generic name of a substance. This allows the dispensing pharmacist to choose between generic equivalent products of different brands.” Importantly, international non-proprietary name (INN) prescribing is the norm in some member states. In these situations, the ePrescription will 10 https://health.ec.europa.eu/document/download/b744f30b-a05e-4b9c-9630ad96ebd0b2f0_en?filename=ehn_guidelines_eprescriptions_en.pdf (release 3, June-2022) 11 https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html#3-document-sharing-profiles Content Creator Content Consumer ePrescription Data Sweet D r eams CDA-based ePrescription Create an ePrescription: •Provider submits an MPD-adherent ePrescription to the “local” (Country-A) EHR Document Source Document Repository UNICOM – T1.4 Testing and assessment Page 19 of 27 not name the medicinal product (e.g. SweetDreams), but rather will generically identify the active ingredient(s), the INN and/or the ATC code, or the virtual medicinal product (VMP). This highlights the importance of MPD-related issues articulated in Section 4.2.2. • The pattern of document exchange illustrated in Figure 6 is the same for eDispensation documents. Unlike for ePrescriptions, however, the record of the dispense will not be generic; it will always reference the relevant identifier. The normative data elements for an eDispensation document are described in the eHealth Network guideline (see previous link). Retrieve an ePrescription or eDispensation Figure 7 - Retrieve ePrescription into PFA Included in the UNICOM Test Lab participants was a cohort focused on patient-mediated cross-border data exchange. This international team leveraged digital health apps to enable a patient to, themselves, operationalize cross-border interoperability. The prototyping of the participant teams leveraged patient facing apps (PFA) that already had a copy of the relevant ePrescriptions in FHIR format. A workflow that could support a PFA’s retrieval of an existing ePrescription, using FHIR, is illustrated in Figure 7. Again leveraging the fictitious characters described in IDMP in a Capsule, we can say that “the patient leverages her MyHealthPFA patient facing app to retrieve, in FHIR format, a copy of her ePrescription for the SweetDreams product directly from her care provider’s HealthApp or, alternatively, from the Dutch ePrescription document repository”. Such a document exchange could be operationalized using IHE’s conformance-testable mobile Health Document (MHD) Profile.12 The following important points may be noted: • The prototype apps that operationalized cross-border data exchange leveraged a common shared service (also prototyped as part of the illustrative workflow) to execute the necessary translations operationalized by the National Contact Points for eHealth (NCPeH). The copy of an ePrescription that may be obtained by a PFA from the local provider EMR or from the domestic document repository will not meet the eHealth Network specifications for crossborder exchange until such processing is done. Furthermore, this processing cannot be undertaken until the target country is known. • With the caveats noted above, patient-mediated cross-border data exchange was successfully demonstrated at multiple UNICOM events. It was evident, from these demonstrations, that Europe’s broad smartphone adoption13 opens significant opportunities to increase patient agency in their own care. As an equity note, however, although the European mobile phone adoption rate has topped 86% -- only 4 in 5 mobile phone users have smartphones. Put another way: there are 95 million European mobile phones users who are not yet using smartphones. 12 https://profiles.ihe.net/ITI/MHD/ 13 https://www.gsma.com/mobileeconomy/wp-content/uploads/2022/10/051022-Mobile-Economy-Europe-2022.pdf MHD Document Consumer MHD Document Responder ePrescription Data Sweet D r eams ePrescription Retrieve an ePrescription: •A Patient retrieves an ePrescription from the national EHR or from the prescribing Provider’s EMR solution UNICOM – T1.4 Testing and assessment Page 20 of 27 • It may be possible to leverage smartphones to operationalize data sharing on a point-to-point basis on an aggressive timescale – possibly more quickly than the overall eHealth Network adoption will afford. Testing As may be noted from Figure 6 and Figure 7, testing of the ePrescribing workflow relies on participation from digital health solution developers, (potentially) care providers, and (potentially) national digital health agencies. Of course, any development of patient-facing applications should also involve end-users (patients), but their involvement is unlikely to be needed during interoperability testing. Testing of IHE’s CDA-over-XDS family of workflows and of MHD-based workflows is regularly conducted at IHE Connectathon and Projectathon events. The very commonly implemented ePrescription and eDispensation workflows are not, per se, UNICOM workflows. Rather, they represent prerequisites to the cross-border workflows that were the subject of UNICOM Test Lab use cases. That said, it is noteworthy that there has been active work within IHE technical committees to develop FHIRbased equivalents to the mature CDA-based document exchanges. This work is particularly relevant to PFA-centric workflows, which will generally favour the FHIR standard. To support the ongoing progression of UNICOM, post project, IHE Pharmacy is undertaking the development of FHIR-based specifications functionally equivalent to the existing CDA-based ePrescription and eDispensation workflows. This work will continue, post-UNICOM. The impacts of IDMP support will be reflected in the global IHE specifications and, where they differ, UNICOM-specific (e.g. EU-specific) requirements will be incorporated in the Volume-4 section of the specification and governed by IHE-Europe. 4.2.4 Cross-border Sharing of ePrescription / eDispensation The cross-border use case is functionally described, in the eHealth Network guideline, as follows: 1. A health professional issues an electronic prescription for the patient (in country A). 2. The patient requires medication (in Country B). 3. The patient visits a pharmacy (in Country B). 4. The patient identifies himself/herself to the pharmacist/staff. 5. The Pharmacist is identified, authenticated, and authorised. 6. The patient or optionally the authorised party asks for his/her ePrescriptions. By doing so, the patient gives the dispenser/pharmacist his/her authorisation to access his/her electronic prescriptions. 7. The pharmacist requests the patient’s ePrescriptions via the pharmacy’s dispensation system in a secure way. a. The ePrescription is received (from Country A). b. The ePrescription is translated by a semantic service. c. Pharmacist receives the ePrescription either translated into his/her own language or English, and a copy of the original information in the prescription. 8. Pharmacist decides on dispensing. 9. The requested medication is then dispensed to the patient. 10. Information about the dispense act and dispensed medicine is tracked in a dispense record and should be sent back to an ePrescription system in the country of prescription (Country A). The authentication and authorisation processes described in steps 5 and 6 are common to all crossborder MyHealth@EU-supported transactions (not just ePrescription / eDispensation). The process steps are described, graphically, in Figure 8 (which was originally published in the epSOS System Technical Specification, D3.2.2, 2010). As may be noted from the graphic, the provider authentication steps are entirely executed within Country-B. The balance of the cross-border patient identification and document exchange processes follow this authentication step. These cross-border processes are supported by IHE specifications and by the companion translational processes executed by each UNICOM – T1.4 Testing and assessment Page 21 of 27 NCPeH. A “bird’s eye view” of this is illustrated in Figure 9 (which was originally published in the epSOS Common Components specification, D3.4.2, 2010). Figure 8 - epSOS Healthcare Provider Authentication and Patient Identification Figure 9 - epSOS Cross-border IHE Profiles The remainder of this section specifically focuses on UNICOM Test Lab use cases related to steps 7, 8 and 10 (as described in the eHealth Network guideline). UNICOM – T1.4 Testing and assessment Page 22 of 27 Retrieve an ePrescription from Country-A to Country-B Figure 10 - Retrieve ePrescription from Country-A to Country-B The workflows and processes related to step 7 of the cross-border use case story are illustrated (at a high level) by Figure 10. This is a complicated, multi-step workflow crossing multiple digital systems. In Country-B: the pharmacist’s system, playing the role of a Patient Document Service Consumer actor, requests the ePrescription Data from Country-B’s NCPeH, which is playing the role of a Patient Document Service Supplier.14 In turn, Country-B’s NCPeH now plays the role of a Patient Document Service Consumer actor and requests the ePrescription Data from Country-A’s NCPeH, which is playing the role of a Patient Document Service Supplier. Important preparation of the ePrescription occurs at Country-A before the reply transaction is completed. Country-A’s NCPeH retrieves and makes a copy of the ePrescription, which is then processed to create a “pivot document” conformant to the eHealth Network’s guideline. The pivot document leverages the Master Value Sets Catalogue (MVC) and the Master Translation/Transcoding Catalogue (MTC) to map the ePrescription from the national language of Country-A to English. Terminological codes local to Country-A are also mapped to the European codes.15 The NCPeH in Country-A returns the original ePrescription and the pivot document to the NCPeH in Country-B. Here, more preparation must be done. Leveraging, again, the MVC and MTC, the NCPeH in Country-B translates the pivot document from English into the national language of Country-B. If necessary, the European codes in the pivot document may also be translated to match the local terminological codes of Country-B. Finally, the original ePrescription and the translated/transformed ePrescription (and, possibly, the pivot document as well) are returned to the original requestor. Leveraging our fictitious characters from IDMP in a Capsule, and assuming our patient has travelled from the Netherlands to Greece, we can say: “the Greek pharmacist uses her HellaRx solution to request the SweetDreams ePrescription from the Dutch NCPeH and it is returned to her in both Dutch and Greek.” There are noteworthy aspects related to this workflow: • If the ePrescription is for a medicinal product, it may not be one that enjoys a marketing authorization in Country-B. • As noted previously, the ePrescription may not be for a medicinal product, but rather may indicate a generic prescription. As noted in Section 4.2.2, if Country-A and Country-B have inconsistent methods of assigning VMPs, there is a potential for confusion. 14 These precise actor names are used within the eHealth Network and mask a larger underlying cast of actors. The IHE Crosscommunity Access specification (XCA: https://profiles.ihe.net/ITI/TF/Volume1/ch-18.html) is employed to operationalize this exchange. In this exchange, a Document Consumer requests through an Initiating Gateway to a Responding Gateway that, in turn, passes the request to a Document Registry (for lookup) and to a Document Repository (for retrieval). 15 An excellent summary of the processing is found, here: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC9918835/ Cross-border Retrieve of ePrescription Patient Document Service Consumer Patient Document Service Supplier Patient Document Service Supplier Patient Document Service Consumer ePrescription Data eHDSI-related ePrescription transformations NL,EN,GR,VMP UNICOM – T1.4 Testing and assessment Page 23 of 27 These points illustrate the benefits of leveraging IDMP as a consistent standard for describing medicinal products and the need for a processable method to leverage this unambiguous coding to support safe substitutions of medicines. This is the subject of the next section. Determine the Allowable Substitutions Figure 11 - Execute the safe substitution logic As noted in the previous section, there may be situations where the medicinal product or the generic prescription indicated in the cross-border ePrescription cannot be directly dispensed and a substitution must be made. The process for executing step 8 of the cross-border scenario, substitution, is illustrated in Figure 11. In this workflow, a Dispensation Options Requester requests a Dispensation Options List from a Dispensation Options Responder. As noted in the diagram – multiple different digital health solutions could potentially play the role of the Dispensation Options Responder. The substitution logic could be executed as part of the native functionality of the pharmacist’s digital health solution. In the alternative, a substitution logic service could be hosted as part of the infrastructure of Country-B’s NCPeH or it could be part of the functionality of an MPD. Leveraging the fictitious characters from UNICOM in a Capsule, we could describe these three alternatives: 1. “The Greek pharmacist uses the native functionality of her HellaRx solution to generate a list of safe alternatives for the SweetDreams product.” 2. “The Greek pharmacist uses her HellaRx solution to query the substitution service at the Greek NCPeH for a list of safe alternatives to the SweetDreams product.” 3. “The Greek pharmacist uses her HellaRx solution to query the national MPD for a list of safe alternatives to the SweetDreams product.” Get substitution list: •Provider fetches list of Dispensation options Substitution Logic “Engine”… running locally or in a shared service. Dispensation Options Requester Dispensation Options Responder Dispensation Options List UNICOM – T1.4 Testing and assessment Page 24 of 27 Save the eDispensation from Country-B to Country-A Figure 12 - Save the eDispensation from Country-B to Country-A The workflows and processes related to step 10 of the cross-border use case story are illustrated (at a high level) by Figure 12. This complicated, multi-step workflow mirrors the one illustrated in Figure 10, but in reverse. In Country-B: the pharmacist’s system, playing the role of a Content Creator actor, submits the eDispensation Data to Country-B’s NCPeH, which is playing the role of a Content Consumer. Country-B’s NCPeH leverages the MVS catalogue and the MTC service to process the eDispensation Data to create a pivot document. Country-B’s NCPeH then plays the role of a Dispensation Service Provider actor and submits original eDispensation and the pivot document to Country-A’s NCPeH, which is playing the role of a Dispensation Service Consumer.16 Country-A’s NCPeH leverages the MVC and the MTC to processes the inbound eDispensation content. It then plays the role of a Content Creator and persists this translated and transformed eDispensiation Data to the appropriate domestic repository, which plays the role of a Content Consumer. It should be noted that, at present, the eDispensation exchange is treated as optional on the sender side (Country-B) and there is also a dispensation discard option that may be adopted on the receiver side (Country-A). Leveraging our fictitious characters from UNICOM in a Capsule, we may describe this workflow process as: “a record of the medication actually dispensed in satisfaction of the ePrescription for SweetDreams is communicated from the Greek pharmacist’s HellaRx solution to the relevant data repository in the Netherlands.” Testing As may be noted from Figure 10 and Figure 12, testing of cross-border workflows relies on participation from digital health solution developers and from each country’s NCPeH operator. As may be noted from Figure 11, testing of substitution logic will require participation from digital health solution developers, (potentially) from MPD operators, and (potentially) from national digital health agencies that may host shared substitution services. Testing of the MyHealth@EU workflows (steps 7 and 10 of the cross-border use case) is regularly conducted in support of each successive wave of adoption by EU member states. This testing leverages IHE’s Gazelle platform and the set of validators that have been specifically developed to support conformance testing of the eHDSI. The functional workflow tests are described on the MyHealth@EU wiki as follows: 16 These precise actor names are used within the eHealth Network. The IHE Cross-enterprise Document Reliable Interchange (XDR: https://profiles.ihe.net/ITI/TF/Volume1/ch-15.html) specification is employed to operationalize this exchange. The generic actors named in XDR are Document Source and Document Recipient. Create an eDispensation: •Provider submits an adherent eDispensation to NCPeH-B ( NCPeH-A EHR-A) eHDSI-related eDispensation transformations Content Creator Content Consumer eDispensation Data Dispensation Service Consumer Dispensation Service Provider Content Creator Content Consumer eDispensation Data+ GR,EN,(VMP),NL UNICOM – T1.4 Testing and assessment Page 25 of 27 A number of scenarios must be tested through functional workflow tests, in various combinations. Some of the scenarios may depend on the ePrescription system design specifics in Country A or in Country B. 1. Dispensation in Country B of full amount, partial amount, or amount exceeding the prescribed amount (overdispensation, which may be allowed by Country B rules). a. For an unmodified prescription. b. For a prescription modified in Country A (if modifications are supported). c. For a prescription prepared as a result of renewal in Country A (if renewals are supported). d. For prescription that has been partially dispensed in Country A. e. For a prescription that has been partially dispensed through eHDSI by another test partner. 2. Dispensation with substitution and without substitution. 3. For a prescription partially dispensed through eHDSI, dispensation (full, partial or overdispensation) of the remaining amount by a pharmacy system in Country A. 4. In case substitution is prohibited, dispensation of the same drug with name or ID modification. The same drug may be available in Country B under a slightly different name or with a different ID, even though substitution is not performed. 5. Dispensation with different package size or package type. 6. Verification of negative conditions: it should be not possible to dispense when a. Not all required data is filled (dispensed amount, dispensed drug name, etc). b. Entered data is invalid (negative values, zero values, etc). c. Prescription has been fully dispensed. d. Strength or ATC code is changed. e. The prescription type is not supported by eHDSI rules or implementation (time-based prescription, combination packages, narcotics, medications prepared in the pharmacy, etc.). f. Prescription has been cancelled in Country A. g. Prescription has been renewed in Country A (a new prescription has been created based on the current one). 7. In case the prescription is valid in Country A but considered invalid in Country B, verification that the prescription is not available for dispensation in Country B. The cases may depend on the ePrescription system design specifics in Country A, but examples include: a. Prescriptions that are locked or reserved, for example for an automated dose dispensing service in Country A. b. Prescriptions that are written for patients who are identified through non-standard means (for example, prescriptions written based on name and birth time in countries that normally use identification numbers). c. Prescriptions for drugs affecting the central nervous system, not classified as narcotics, but requiring special handling. 8. An optional operation of dispensation discard may be tested, if supported by Country A and Country B. Depending on the ePrescription system design specifics in Country A or Country B, a number of extra conditions may need to be tested. Test results for each pairwise set of member states in each adoption wave are reported and logged on the wiki, as are details of each IHE Gazelle validator and the test plans that employ them. There is not, at present, conformance testing regarding step 8 of the cross-border use case: safe medicinal product substitution. IHE has actively participated in the development of prototype online services that demonstrate the properties and system behaviours of different substitution approaches. This work has surfaced important considerations related to patient safety and necessary system flexibility. These considerations apply to ePrescription substitution in cross-border scenarios as well as, generally, to the substitutions needed to deal with medications stock-outs, which are a pressing issue in many member states. IHE’s ongoing support to the MyHealth@EU cross-border conformance testing will continue in support of each successive adoption wave. To leverage the lessons learned from the active prototyping done during UNICOM, a new work item will be suggested to IHE Pharmacy an interoperability specification related to safe medication substitution. This work will continue, post-UNICOM. These