D5.7 Common minimum data set for implementation in the national NCA and eHealth solutions

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 WP5 – IDMP adoption by eHealth Services D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Version: 1.0 Status: Final Dissemination Level1: PU Due date of deliverable: 28.02.2022 (6-month project extension requested in ongoing amendment with deliverable due date on 31.08.2022) Actual submission date: 09.09.2022 Work Package: WP5: IDMP adoption by eHealth Services Lead partner for this deliverable: SPMS Partner(s) contributing: ARIA, REGLOMB, GNOMON, IDIKA, ELGA, KELA, IEDOH, SAS, INDRA, HZZO Deliverable type2: R Main author(s): WP5 members Anderson Carmo SPMS Other author(s): WP5 members 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 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 2 of 69 Revision history Version Date Changes made Author(s) 0.1 10.01.2022 started the 1st draft of the document All 0.2 22.08.2022 End of 1st draft of document All 1.0 05.09.2022 Final version of the document AC 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 – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 3 of 69 Deliverable abstract To further improve the implementation of IDMP, it is also necessary to define a minimum dataset to ensure the implementation of the ISO IDMP data for eHealth proposes, set the ground for a basic understanding of the data, and allow enrichment of the current clinical documents. The availability of a common minimum dataset recognises that each country or region may have a complex set of codes and attributes required to support local healthcare activities regarding the identification of medicinal products. By identification the ‘minimum’ dataset for cross-border exchange of healthcare information it is possible to provide a basic common set of information that will support the medicinal production data exchange for the different services associated with them. This document presents a common minimum data set that needs to be implemented in the national NCA and eHealth provider to further support and facilitate the integration of IDMP into National systems. Keywords: 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-2023. The participants of the UNICOM project. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 4 of 69 TABLE OF CONTENTS Revision history ....................................................................................................................................... 2 Deliverable abstract ................................................................................................................................. 3 List of abbreviations ................................................................................................................................. 6 Executive summary ................................................................................................................................. 8 1 Introduction and Background ........................................................................................................... 9 1.1 Background.............................................................................................................................. 9 1.2 Introduction to D5.7 ............................................................................................................... 11 1.3 Scope of the document .......................................................................................................... 11 2 Overview of the state of play from NCAs and eHealth agencies ................................................... 12 2.1.1 Status of the IDMP implementation on NCAs ................................................................... 13 3 Minimum Attributes List for eHealth (MALeH) to eP/eD & PS ....................................................... 15 3.1 MALeH Attributes explanation and examples ....................................................................... 20 3.2 Preferred coding systems ...................................................................................................... 33 3.2.1 EMA-SPOR ........................................................................................................................ 33 3.2.2 WHO-ATC ......................................................................................................................... 34 3.2.3 EDQM ................................................................................................................................ 35 3.2.4 UCUM ................................................................................................................................ 35 3.3 ISO IDMP Identifiers .............................................................................................................. 35 3.3.1 Attributes required to generate PhPID .............................................................................. 36 3.3.2 MPID generation ................................................................................................................ 38 3.3.3 PCID generation ................................................................................................................ 38 4 Minimum data set specifications .................................................................................................... 39 5 Adoption Assessment ..................................................................................................................... 41 5.1 Semantic compatibility assessment ...................................................................................... 41 6 Roadmap with the eHDSI implementation ..................................................................................... 44 7 Considerations for IDMP roadmap for NCAs and solution providers ............................................. 46 7.1 Minimum data specifications vs national declinations ........................................................... 46 8 Recommendations for adoption ..................................................................................................... 47 9 Annexes .......................................................................................................................................... 49 Annex 1 – Pilot Product List (PPL) .................................................................................................... 49 Annex 2 – CP-eHDSI-066: Prepare eHDSI Requirements Catalogue for ISO IDMP ....................... 51 Annex 3 – Code Systems in MVC 6.1.0 ............................................................................................ 62 Annex 4 – CP-eHDSI-063: Improve Medication Information Representation ................................... 65 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 5 of 69 LIST OF FIGURES Figure 1: The 5 ISO standards used to identify medicinal products ....................................................... 9 Figure 2: The WP5 deliverables relationship. ........................................................................................ 10 Figure 3: Relationship between different sets of attributes and actors ................................................. 21 Figure 4: Adapted representation for Losec considering the MALeH ................................................... 30 Figure 5: Adapted representation for Hiberix considering the MALeH .................................................. 32 Figure 6: PhPID four levels.................................................................................................................... 36 Figure 7: IDMP related data models and their relationship ................................................................... 40 Figure 8: use of the MALeH semantic specifications in aligning specifications (and their relation to IDMP and UFIS). ............................................................................................................... 43 Figure 9: Roadmap for IDMP implementation for cross-border services. ............................................. 44 LIST OF TABLES Table 1: Cross-border state of play of UNICOM onboard agencies...................................................... 13 Table 2: MALeH and their relationship with eHDSI data elements ....................................................... 19 Table 3: comparison between ‘Strength’ and ‘Reference Strength’ ...................................................... 28 Table 4: MALeH flat representation for Losec ....................................................................................... 29 Table 5: MALeH flat representation for Hiberix ..................................................................................... 31 Table 6: ATC levels description ............................................................................................................. 35 Table 7: Cardinality relationships that shall be respected within the elements of a pharmaceutical product, according to ISO 11616 ...................................................................................... 37 Table 8: Pilot Product List...................................................................................................................... 49 Table 9: Code Systems in MVC 6.1.0 ................................................................................................... 62 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 6 of 69 List of abbreviations Abbreviation Complete form Ag Agency ATC Anatomical Therapeutic Chemical Classification CBeHIS Cross-Border eHealth Information Services CDA Clinical Document Architecture CEF Connecting Europe Facility CoE Community of Expertise CP Change Proposal D Deliverable DDD Defined Daily Dose eD Electronic Dispensation EDQM European Directorate for the Quality of Medicines eHDSI eHealth Digital Service Infrastructure eHN eHealth Network eHOMB eHealth Operational management Board EMA European Medicines Agency EMA IG European Medicines Agency - Implementation Guide eP Electronic Prescription EU European Union EUTCT European Union Telematics Controlled Terms FHIR Fast Health Interoperability Resources IDMP Identification of Medicinal Products ISO International Organisation for Standardization MALeH Minimum Attributes List for eHealth MoH Ministry of Health MPID Medicinal product identifier MVC Master Value Set Catalogue NCA National Competent Authority NCPeH National Contact Point eHealth OID standard Object Identifier UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 7 of 69 OMS Organisation Management Services PCID Packaged Medicinal Product Identifier PhPID Pharmaceutical Product Identifier PMS Product Management Services PPL Pilot Product List PPT Pre-Production Test PS Patient Summary RMS Referentials Management Services RoA Rout of Administration SMS Substance Management Services SPOR Substance, Product, Organisation and Referential UFIS UNICOM FHIR IDMP Server UML Unified Modelling Language URL Uniform Resource Locator VMPP Virtual Medicinal Packaged Product WP Work Package UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 8 of 69 Executive summary The work previously completed on the WP5 deliverables has defined the guidelines and semantic specifications for the adoption of ISO IDMP in the eHealth services at national level, and their connections to the Medicinal Products databases both from National Competent Authorities (NCAs) and private providers. To further improve the implementation of IDMP, it is also necessary to define a minimum dataset to ensure the implementation of the ISO IDMP data for eHealth proposes, set the ground for a basic understanding of the data, and allow enrichment of the current clinical documents. The availability of a common minimum dataset recognises that each country or region may have a complex set of codes and attributes required to support local healthcare activities regarding the identification of medicinal products. These datasets may be standardised through a national medicinal product dictionary, or they may be present across various drug files supporting local use cases. However, by identifying the ‘minimum’ dataset for cross-border exchange of healthcare information it is possible to provide a basic common set of information that will support the medicinal production data exchange for the different services associated with them. In that sense, this document has defined a minimum dataset for the adoption of ISO IDMP in the eHealth services at national and cross-border levels. Also, presents a common minimum data set that needs to be implemented in the national NCA and eHealth provider to further support and facilitate the integration of IDMP into National systems. Guidelines targeted at NCA’s, and eHealth agencies will also be designed in order to support this implementation. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 9 of 69 1 Introduction and Background 1.1 Background The UNICOM project intends to facilitate the overall implementation of the ISO IDMP (Identification of Medicinal Products) standards that provide the basis for the global identification of medicinal products. ISO IDMP is comprised by five ISO (International Organisation for Standardization) standards, which together, describe a standard data model for the proper identification and description of medicinal products and related concepts (Figure 1). Currently the Medicinal/Pharmaceutical products are described in a wide variety of forms and records among countries. By this project, the proposed work intends to support and facilitate the further development of ISO IDMP standards, its adaptation to the various (new) requirements which have or will arise, as well as to promote the successful implementation of ISO IDMP standards across countries, to allow the univocal identification of medicinal products across the European Union and globally. Figure 1: The 5 ISO standards used to identify medicinal products There are many significant predictable benefits to the application of ISO IDMP that will invariably impact many domains, particularly through improved and safe semantic interoperability across language and other aspects related to data and information, such as the regulatory field, the clinical context and pharmacovigilance applications. Also, the ISO IDMP implementation will impact the commercial / noncommercial entities regarding their global competitive advantage. Therefore, the application of ISO IDMP is fundamental to contribute to the safe prescription and dispensation of medicines, in all its evolving environment. 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 and deliver better patient outcomes. 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 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). In this regard, eHDSI has started deploying the core and generic services, as defined in the CEF, for Patient Summary (PS) and ePrescription/eDispensation (eP/eD). The generic UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 16 of 69 # Moiety Salt/ester/modification (and notes, synonyms) 6 salbutamol salbutamol sulfate 7 amoxicillin and clavulanic acid amoxicillin (anhydrous, explicitly) amoxicillin (unspecified) clavulanic acid amoxicillin sodium amoxicillin trihydrate potassium clavulanate 8 insulin glargine 9 teriparatide 10 drospirenone and ethinylestradiol drospirenone ethinylestradiol 11 atorvastatin, amlodipine and perindopril 12 calcium + vitamin D calcium carbonate ergocalciferol 13 paracetamol 14 diazepam 15 morphine morphine hydrochloride morphine sulfate morphine tartrate morphine liposomal (sulfate) 16 enoxaparin enoxaparin sodium 17 hydrocortisone hydrocortisone sodium succinate hydrocortisone valerate hydrocortisone acetate hydrocortisone butyrate hydrocortisone aceponate hydrocortisone probutate (synonyms: butyrate propionate; buteprate) hydrocortisone cypionate hydrocortisone sodium phosphate 18 lidocaine lidocaine hydrochloride also tosilate, hydrocarbonate, bicarbonate, maleate, carbonate - but not used in products? 19 trastuzumab trastuzumab emtansine (synonym: ado-trastuzumab emtansine) trastuzumab deruxtecan 20 imatinib imatinib mesilate 21 clomipramine clomipramine hydrochloride 22 carbamazepine 23 metformin metformin hydrochloride metformin pamoate (synonym: metformin embonate) 24 amlodipine (racemic) amlodipine besilate amlodipine benzoate amlodipine maleate UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 17 of 69 # Moiety Salt/ester/modification (and notes, synonyms) 25 perindopril perindopril arginine perindopril erbumine (synonym: perindopril tert-butylamine) perindopril erbumine monohydrate perindopril tosilate 26 tramadol (racemic) tramadol hydrochloride 27 ciclosporine Synonym: ciclosporin A 28 itraconazole itraconazole trihydrochloride 29 goserelin goserelin acetate 30 glyceryl trinitrate nitroglycerin 31 chloroquine chloroquine phosphate chloroquine sulfate chloroquine hydrochloride 32 clotrimazole 33 varenicline varenicline tartrate varenicline dihydrochloride 34 ibuprofen (racemic) ibuprofen sodium ibuprofen lysine 35 tafluprost UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 18 of 69 Annex 2 –) that will impact wave 6 of eHDSI. Therefore, the MALeH presents the minimum data that meets the expectations of the project and cross-border services. As mentioned, from the initial UFIS list, MALeH is composed by attributes that were identified as essential and represent the minimum data required for eHealth services (Table 2). These attributes are IDMP-compliant and were aligned with eHDSI Master Value Set Catalogue (MVC)21 and EMA IG V2.1. The other attributes highlighted initially in the UFIS list are relevant for other areas of the medicinal product lifecycle, such as pharmacovigilance, and, thus, were not selected because they are out of the scope of eHealth services. Considering the above, Table 2 presents the minimum dataset for eHealth services, their relationship with the eHDSI data elements, EMA IG and the recommended coding system to represent data when applicable. All the indicated preferred coding systems are international standards. The lines in the table with dark blue background bold indicate the main sections and subsections of attributes based on the organization of the EMA IG. Importantly, one medicinal product may have duplicate attributes, such as in cases of having two active ingredients or having two different units of presentation forms. The table below is a flat representation that allows to represent different levels of information, such as those mentioned above. The next subsection will provide an explanation and further detailed this table. 21 For the coding system IDs of the MVC 6.1.0, please see Annex 3 – Code Systems in MVC 6.1.0. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 19 of 69 Table 2: MALeH and their relationship with eHDSI data elements EMA SPOR eHDSI MVC 6.1.021 # Attributes from EMA IG V2.1 EMASPOR database Preferred coding system eHDSI Data Elements22 Value Set name 1. Medicinal Product 1.1 Product Management Service Identifier (PMS ID) Medicinal Product Code 1.2 Medicinal Product Identifier (MPID) 1.5 Authorised Pharmaceutical Form* RMS EDQM Pharmaceutical Dose Form eHDSIDoseForm 1.13 Product classification 1.13.3 ATC code(s)* RMS WHO - ATC ATC code eHDSIActiveIngredient 1.14 Medicinal Product Name 1.14.1 Full name Brand Name of the Medicinal Product 2. Marketing Authorisation Information 2.8 Marketing Authorisation Holder OMS SPOR-OMS Marketing Authorisation Holder of the prescribed medicinal product 4. Packaged Medicinal Product 4.1 Packaged medicinal product Identifier (PCID) Medicinal Product Code 4.3 Pack size** EDQM Medicinal Product Package eHDSIQuantityUnit 4.7 Package item (container)** 4.7.1 Package item (container) type* RMS EDQM Medicinal Product Package eHDSIPackage 4.7.5 Package item (container) quantity 4.10 Manufactured Item 4.10.1 Unit of Presentation RMS EDQM eHDSIQuantityUnit 4.10.2 Manufactured Item Quantity* RMS UCUM Package size eHDSIUnit 4.10.3 Manufactured Dose Form RMS EDQM Pharmaceutical Dose Form eHDSIDoseForm 5 Ingredient 5.1 Ingredient role RMS SPOR-RMS 5.5 Substance 5.5.1 Substance SMS SPOR-SMS Active Ingredient eHDSISubstance 5.5.2 Strength (quantitative composition) 5.5.2.2.2 Strength (Presentation single value or low limit) RMS UCUM Strength of the Medicinal Product eHDSIUnit 5.5.2.3.2 Strength (Concentration single value or low limit) RMS UCUM eHDSIUnit 5.5.3. Reference Strength 5.5.3.1 Reference Substance* SMS SPOR-SMS Active Ingredient eHDSISubstance 5.5.3.3.2 Reference Strength (Presentation single value or low limit)* RMS UCUM Strength of the Medicinal Product eHDSIUnit 5.5.3.4.2 Reference Strength (Concentration single value or low limit)* RMS UCUM eHDSIUnit 6. Pharmaceutical Product - Pharmaceutical Product identifier (PhPID) 23 Medicinal Product Code 22 The eHDSI data elements were evaluated from the eHDSI confluence page at (eHDSI restricted access): https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/05.01.+Create+the+eHDSI+Patient+Summary+content https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/06.01.+Create+the+eHDSI+ePrescription%28s%29+content https://ec.europa.eu/cefdigital/wiki/display/EHOPERATIONS/07.01.+Create+the+eHDSI+eDispensation+content For some eHDSI data elements there are more than one correspondence of EMA attributes. In those case, the eHDSI data elements are repeated in this column. 23 Note: This version of the guidance does not report information on additional identifiers such as the Pharmaceutical Product Identifier (PhPID). Further details on the related definitions and defining elements will be available at later stage as it requires further discussions prior the implementation. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 20 of 69 6.2 Administrable Dose Form RMS EDQM Pharmaceutical Dose Form eHDSIDoseForm 6.3 Unit of Presentation* RMS EDQM Foreseen to wave 624 eHDSIQuantityUnit 6.6 Route(s) of Administration* RMS EDQM Route of Administration eHDSIRouteof Administration * The attributes marked in bolt should be preferred over similar ones (e.g., dose forms and unit of presentation) and considered as highly recommended. The reader is advised to read the next section for further details. **Pack size and Package item (container) should be considered optional for simple-type package medicines, but mandatory for complex packaging medicines (e.g., box containing ‘tables + cream’, or ‘vial + syringe’, etc.). 3.1 MALeH Attributes explanation and examples The provision of the eP/eD and PS in a cross-border scenario requires the exchange of health data between different stakeholders. The medicinal product information is provided by the NCAs to the eHealth agencies that use this data to issue the clinical document and that can be consumed at national or cross-border levels (when applicable). At the cross-border level, the data from the clinical document is ‘transformed’ in an interoperable format at the NCPeH-A and exchanged through the eHDSI infrastructure to the NCPeH-B to complete the exchange and provide the service to the end-user. To ensure that all stakeholders involved in the eHealth services can communicate in an interoperable way, the definition of a minimum attribute list is essential to support all the actors of project and the stakeholders so that they can use the same minimum information to issue the eHealth services -aligned to ISO IDMP standards. In this section, you can find the justification of all required attributes based on their grouping. Note that some attributes intend to support the identification of complex package medication accordingly to the eHDSI CP-063 – ‘Improve Medication Information Representation’ (Annex 4 – CP-eHDSI-063: Improve Medication Information Representation) and are not required for the representation of most medicinal products. The following diagram (Figure 3) presents the relationship and differences between the different sets of attributes and their implementations. 24 The eHDSI Wave 6 is scheduled to starts in September 2022 and finishes in August 2023. For more details see chapter ‘ Roadmap with the eHDSI implementation UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 21 of 69 Figure 3: Relationship between different sets of attributes and actors In summary, • ISO IDMP defines all the attributes that can be used in identifying and describing a medicinal product. • The EMA Implementation Guide is based on those attributes and defines a technical format for exchanging those attributes and provides any additional constraints – in other words the EMA Implementation Guide is a specialisation of the ISO IDMP attributes. • UNICOM defined a standard set of product attributes for the regulatory space in the scope of the Pilot Product List (then implemented in the UFIS server). • For clinical purposes, the smaller set of attributes (MALeH) is a subset or specialisation of the full attribute list – this means that the products are defined in the regulatory domain, and the clinical domain uses a subset of the attributes. The MALeH, as is shown in the UNICOM WP5 deliverables, is derived from its “superset” (all IDMP attributes from EMA IG v2.1) - the IDMP attributes in the regulatory space. This ensures consistency, while allowing the clinical domain to advance with the critical data while expecting the regulatory data to be present at any present or future stage. The EMA IG and eHDSI sometimes presents similar names to describe the attributes, however with different meaning. In that sense is important for the reader to ensure to consult the correct reference to avoid misunderstanding. Below on the description of the attributes there are some examples regarding this issue. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 22 of 69 From the Wave 6 (2022-2023), the eHDSI infrastructure will present in their system the fields for the IDMP identifiers (PhPID, MPID and PCID). However, as the IDMP identifiers are not yet available, the national identifiers shall continue be used on cross-border services, in the same way that this service is provided currently. Annex 3 – Code Systems in MVC 6.1.0 The Table 9 presents the coding systems and their identifiers codes used in the eHDSI MVC 6.1.0 for eHDSI wave 6 (2022-2023). Table 9: Code Systems in MVC 6.1.0 Value Set name Value Set ID Code System(s) Code System(s) ID Version(s) of Code System used in MVC eHDSIAbsentOrUnknownAllergy 1.3.6.1.4.1.12559.11 .10.1.3.1.42.47 IPS Absent and Unknown Data 2.16.840.1.113 883.5.1150.1 0.2.0 eHDSIAbsentOrUnknownDevice 1.3.6.1.4.1.12559.11 .10.1.3.1.42.48 IPS Absent and Unknown Data 2.16.840.1.113 883.5.1150.1 0.2.0 eHDSIAbsentOrUnknownMedication 1.3.6.1.4.1.12559.11 .10.1.3.1.42.49 IPS Absent and Unknown Data 2.16.840.1.113 883.5.1150.1 0.2.0 eHDSIAbsentOrUnknownProblem 1.3.6.1.4.1.12559.11 .10.1.3.1.42.50 IPS Absent and Unknown Data 2.16.840.1.113 883.5.1150.1 0.2.0 eHDSIAbsentOrUnknownProcedure 1.3.6.1.4.1.12559.11 .10.1.3.1.42.51 IPS Absent and Unknown Data 2.16.840.1.113 883.5.1150.1 0.2.0 eHDSIActiveIngredient 1.3.6.1.4.1.12559.11 .10.1.3.1.42.24 ATC Classification 2.16.840.1.113 883.6.73 2022-01 eHDSIAdministrativeGender 1.3.6.1.4.1.12559.11 .10.1.3.1.42.34 HL7 v3 AdministrativeGender 2.16.840.1.113 883.5.1 20210930 eHDSIAdverseEventType 1.3.6.1.4.1.12559.11 .10.1.3.1.42.18 SNOMED CT 2.16.840.1.113 883.6.96 44469 eHDSIAllergenNoDrug 1.3.6.1.4.1.12559.11 .10.1.3.1.42.19 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 eHDSIAllergyStatus 1.3.6.1.4.1.12559.11 .10.1.3.1.42.59 FHIR Allergy Intolerance Clinical Status Codes 2.16.840.1.113 883.4.642.4.13 73 4.0.1 eHDSIBloodGroup 1.3.6.1.4.1.12559.11 .10.1.3.1.42.20 SNOMED CT 2.16.840.1.113 883.6.96 43677 eHDSIBloodPressure 1.3.6.1.4.1.12559.11 .10.1.3.1.42.21 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSICertainty 1.3.6.1.4.1.12559.11 .10.1.3.1.42.58 FHIR Allergy Intolerance Verification Status Codes 2.16.840.1.113 883.4.642.4.13 71 4.0.1 eHDSICodeProb 1.3.6.1.4.1.12559.11 .10.1.3.1.42.23 SNOMED CT 2.16.840.1.113 883.6.96 43677 eHDSIConfidentiality 1.3.6.1.4.1.12559.11 .10.1.3.1.42.31 HL7 v3 Confidentiality 2.16.840.1.113 883.5.25 91320091020 eHDSICountry 1.3.6.1.4.1.12559.11 .10.1.3.1.42.4 ISO 3166-1 Country codes (Alpha-2 code) 1.0.3166.1 Second Edition 2006 eHDSICriticality 1.3.6.1.4.1.12559.11 .10.1.3.1.42.57 FHIR Allergy Intolerance Criticality 2.16.840.1.113 883.4.642.4.13 0 4.0.1 eHDSICurrentPregnancyStatus 1.3.6.1.4.1.12559.11 .10.1.3.1.42.60 SNOMED CT 2.16.840.1.113 883.6.96 44469 eHDSIDisplayLabel 1.3.6.1.4.1.12559.11 .10.1.3.1.42.46 epSOSDisplayLabel 1.3.6.1.4.1.125 59.11.10.1.3.1. 44.4 1.5 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 23 of 69 Value Set name Value Set ID Code System(s) Code System(s) ID Version(s) of Code System used in MVC eHDSIDocumentCode 1.3.6.1.4.1.12559.11 .10.1.3.1.42.32 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSIDoseForm 1.3.6.1.4.1.12559.11 .10.1.3.1.42.2 EDQM Standard Terms 0.4.0.127.0.16. 1.1.2.1 44579 eHDSIHealthcareProfessionalRole 1.3.6.1.4.1.12559.11 .10.1.3.1.42.1 ISCO-08 2.16.840.1.113 883.2.9.6.2.7 2008 eHDSIHospitalDischargeReportType 1.3.6.1.4.1.12559.11 .10.1.3.1.42.53 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSIIllnessandDisorder 1.3.6.1.4.1.12559.11 .10.1.3.1.42.5 ICD-10 International Statistical Classification of Diseases and Related Health Problems 10th Revision 1.3.6.1.4.1.125 59.11.10.1.3.1. 44.2 2016 eHDSILaboratoryReportType 1.3.6.1.4.1.12559.11 .10.1.3.1.42.52 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSILanguage 1.3.6.1.4.1.12559.11 .10.1.3.1.42.6 ISO 639-1 + ISO 3166-1 1dd183a66d2b-4a9d8f5dbe09d6bb5a6e March 2017 eHDSIMedicalDevice 1.3.6.1.4.1.12559.11 .10.1.3.1.42.8 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 eHDSIMedicalImagesType 1.3.6.1.4.1.12559.11 .10.1.3.1.42.55 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSIMedicalImagingReportType 1.3.6.1.4.1.12559.11 .10.1.3.1.42.54 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSINullFlavor 1.3.6.1.4.1.12559.11 .10.1.3.1.42.37 HL7 v3 NullFlavor 2.16.840.1.113 883.5.1008 91320091020 eHDSIOutcomeOfPregnancy 1.3.6.1.4.1.12559.11 .10.1.3.1.42.62 SNOMED CT 2.16.840.1.113 883.6.96 44469 eHDSIPackage 1.3.6.1.4.1.12559.11 .10.1.3.1.42.3 EDQM Standard Terms 0.4.0.127.0.16. 1.1.2.1 44579 eHDSIPersonalRelationship 1.3.6.1.4.1.12559.11 .10.1.3.1.42.38 HL7 v3 RoleCode 2.16.840.1.113 883.5.111 91320091020 eHDSIPregnancyInformation 1.3.6.1.4.1.12559.11 .10.1.3.1.42.9 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSIProcedure 1.3.6.1.4.1.12559.11 .10.1.3.1.42.10 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 eHDSIQuantityUnit 1.3.6.1.4.1.12559.11 .10.1.3.1.42.56 EDQM Standard Terms 0.4.0.127.0.16. 1.1.2.1 44579 eHDSIRareDisease 1.3.6.1.4.1.12559.11 .10.1.3.1.42.63 ORPHAnet 1.3.6.1.4.1.125 59.11.10.1.3.1. 44.5 44683 eHDSIReactionAllergy 1.3.6.1.4.1.12559.11 .10.1.3.1.42.11 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 eHDSIResolutionOutcome 1.3.6.1.4.1.12559.11 .10.1.3.1.42.30 SNOMED CT 2.16.840.1.113 883.6.96 43677 eHDSIRoleClass 1.3.6.1.4.1.12559.11 .10.1.3.1.42.39 HL7 v3 RoleClass 2.16.840.1.113 883.5.110 91320091020 e.g., 1.3.6.1.4.1.12559.11 .10.1.3.1.42.12 EDQM Standard Terms 0.4.0.127.0.16. 1.1.2.1 44579 eHDSISection 1.3.6.1.4.1.12559.11 .10.1.3.1.42.26 LOINC 2.16.840.1.113 883.6.1 2.59 eHDSISeverity 1.3.6.1.4.1.12559.11 .10.1.3.1.42.13 SNOMED CT 2.16.840.1.113 883.6.96 43677 eHDSISocialHistory 1.3.6.1.4.1.12559.11 .10.1.3.1.42.14 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 24 of 69 Value Set name Value Set ID Code System(s) Code System(s) ID Version(s) of Code System used in MVC eHDSIStatusCode 1.3.6.1.4.1.12559.11 .10.1.3.1.42.15 SNOMED CT 2.16.840.1.113 883.6.96 43677 eHDSISubstance 1.3.6.1.4.1.12559.11 .10.1.3.1.42.61 EMA SMS Substance 1.3.6.1.4.1.125 59.11.10.1.3.1. 44.1000000758 25 44711 eHDSISubstitutionCode 1.3.6.1.4.1.12559.11 .10.1.3.1.42.7 HL7 v3 substanceAdminSubstitut ion 2.16.840.1.113 883.5.1070 91320091020 eHDSITelecomAddress 1.3.6.1.4.1.12559.11 .10.1.3.1.42.40 HL7 v3 AddressUse 2.16.840.1.113 883.5.1119 91320091020 eHDSITimingEvent 1.3.6.1.4.1.12559.11 .10.1.3.1.42.41 HL7 v3 TimingEvent 2.16.840.1.113 883.5.139 91320091020 FHIR Event Timing 2.16.840.1.113 883.4.642.4.13 71 4.0.1 eHDSIUnit 1.3.6.1.4.1.12559.11 .10.1.3.1.42.16 UCUM Unified Code for Units of Measure 2.16.840.1.113 883.6.8 April 2021 eHDSIVaccine 1.3.6.1.4.1.12559.11 .10.1.3.1.42.28 ATC Classification 2.16.840.1.113 883.6.73 2022-01 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 25 of 69 Annex 4 – CP-eHDSI-063: Improve Medication Information Representation Medicinal Product o Product Management Service Identifier (PMS ID) It is required as a specific identifier of medicinal products related to EMA. While not currently available, it should be provided when possible. o Medicinal Product Identifier (MPID) It is required as a specific national identifier of medicinal products, and it is most relevant for eD and PS. While not currently available, it should be provided when possible. o Authorised Pharmaceutical Form According to the eHN eP Guidelines25: “Dose form of a product could be either authorised dose form (includes European Directorate for the Quality of Medicines – EDQM combination pack dose forms), administrable dose form or manufactured item dose form. It must be made clear which type of dose forms are provided. For example, for the same product several different dose forms can be provided: ‘powder and solvent for solution for injection’ as authorised dose form, ‘solution for injection’ as administrable dose form, and ‘powder’ and ‘solvent’ as the dose forms for the manufactured items in the inner packaging.” Ideally the 3 attributes should be presented, however on the impossibility to provide them, it must be clearly specified which attribute is being provided. ‘Authorised Pharmaceutical Form’ should be preferred over ‘manufactured dose form’ and ‘administrable dose form’, since the former is the most used by Member States to describe the dose form and contains the complete description of the medicinal product dose form. o ATC code(s) It is required to define the product classification, and it is already in use on eHDSI services. The Anatomical Therapeutic Chemical Classification – ATC code should be assigned at the level of the medicinal product pack. It is important to also add Defined Daily Dose (DDD) unit and DDD value, (which might be different for oral and parental forms of certain substances) and to calculate the number of DDDs per pack or per unit of presentation. o Full name It must be provided on eD and PS and optional on eP, considering the possibility of prescribing generic medicines and/or different medicinal product names between Member States. Marketing Authorisation Information o Marketing Authorisation Holder (organisation) It must be provided on eD and PS and optional on eP. It describes the name of the organisation that holds the marketing authorisation of a medicinal product. It should be indicated as listed in SPOR – Organisation Management System (OMS), using the ‘LOC-ID’ linked to the organization in this system. Packaged Medicinal Product o Packaged medicinal product Identifier (PCID) 25 https://health.ec.europa.eu/latest-updates/eprescription-and-edispensation-authorised-medicinal-products-guidelineselectronic-exchange-health-2022-06-10_en UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 32 of 69 1. - Medicinal Product 1.13. - Product Classification 1.14. - Medicinal Product Name 2. - Marketing authorisation information 4. - Packaged Medicinal Product 4.7. - Package item (container) [2] 4.10. - Manufactured Item [3] 5. - Ingredient 5.5. - Substance 6. - Pharmaceutical Product 4.7. - Package item (container) [4] 4.10. - Manufactured Item [5] 4.7. - Package item (container) [1] 5.5.2. - Strength (quantitative composition) 5.5.3. - Reference Strength 5.5.2. - Strength (quantitative composition) 5.5.3. - Reference Strength 1.5. - Authorised Pharmaceutical Form: Powder and solvent for solution for injection (100000073868) 1.2. - MPID: IE-100001573-00000001 1.1. – PMSID: 00007007 1.13.3. - ATC Code(s): J07AG51 (100000096521) 1.14.1. - Full name: Hiberix. Haemophilus Type b (Hib) vaccine Powder and Solvent for Solution for Injection 2.8. - Marketing authorisation holder: 4.3. - Pack Size: 1 vial + 1 syringe 4.1. - PCID: IE-100001573-00000001-0002 4.7.5. Package item (container) quantity: 1 4.7.1. - Package item (container) type: Vial (100000073563) 4.10.2. - Manufactured Item Quantity: 1 Unit(s) (100000110756) 4.10.1. - Unit of Presentation: Vial (200000002158) 4.10.3. - Manufactured Dose Form: Powder for solution for injection (100000073866) 5.1. - Ingred ient role: Active (100000072072) 5.5.1. - Substance: Haemophilus influenzae type b capsular polysaccharide (PRP) conjugated to tetanus toxoid (TT) (mean TT/PS ratio: 2.5) (100000089691) - PhPID: not available yet 6.2. - Administrable Dose Form: Solution for injection 6.3. - Unit of Presentation: Syringe 6.6. - Route of Administration: Intramuscular use 4.7.5. Package item (container) quantity: 1 4.7.1. - Package item (container) type: Pre-filled syringe (100000073544) 4.10.2. - Manufactured Item Quantity: 0.5 millilitre(s) (100000110662) 4.10.1. - Unit of Presentation: Syringe (200000002150) 4.10.3. - Manufactured Dose Form: Solution for solution for injection (100000174029) 4.7.5. Package item (container) quantity: 1 4.7.1. - Package item (container) type: Box 5.5.2.2.2. - Strength (Presentation single value or low limit): Numerato r: Denominator: 5.5.2.3.2. - Strength (Concentration single value or low limit): Numerato r: Denominator: 5.5.3.1. - Reference Substance: Haemophilus influenza type b polysaccharide (polyribosylribitol phosphate) (PRP) 5.5.3.3.2. – Reference Strength (Concentration single value or low limit): Numerato r: 10 microgram(s) Denominator: 1 vial 5.5.3.4.2. - Strength (Concentration single value or low limit): Numerato r: 20 microgram(s) Denominator: 1 mililitre 5.5.2.2.2. - Strength (Presentation single value or low limit): Numerato r: Denominator: 5.5.2.3.2. - Strength (Concentration single value or low limit): Numerato r: Denominator: 5.5.3.1. - Reference Substance: Tetanus toxoid 5.5.3.3.2. – Reference Strength (Concentration single value or low limit): Numerato r: 25 microgram(s) Denominator: 1 vial 5.5.3.4.2. - Strength (Concentration single value or low limit): Numerato r: 50 microgram(s) Denominator: 1 mililitre Figure 5: Adapted representation for Hiberix considering the MALeH UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 33 of 69 3.2 Preferred coding systems In order to describe attributes of medicinal products in a standardised way, the use of international coding systems is highly recommended. International coding systems represent all the attribute variables in a coded and interoperable way29. Thus, it can support the national stakeholders to identify foreign products and assist in translations (when needed). The eHDSI Master Value Sets Catalogue (MVC) is a collection of terms, used within certain parts of the eHDSI pivot documents (either parts describing the patient demographics or the clinical problems, for example), based on standardised code systems (Annex 3 – Code Systems in MVC 6.1.0) such as ICD10, SNOMED CT, ATC Classification, EDQM Standard Terms, or UCUM. The use of the preferred coding systems indicated below are in line with the specifications of the eHDSI MVC. The use of these specific coding systems eliminates the transcoding step, thus increasing the safety of the services by avoiding mismatches. As part of UNICOM’s work with the eHDSI communities, SPOR-SMS has been included in the new version of the MVC - MVC 6.1.0 - as the coding system for substance, which will impact Wave 6 of eHDSI (2022-2023). The indicated preferred coding systems for representing IDMP attributes (Table 2 are further explained below. 3.2.1 EMA-SPOR30 The European Medicines Agency (EMA) through the Substances, Products, Organisations and Referentials (SPOR) data management services is centralising the codification of the information relating to medicinal products. SPOR databases were created to be compliant with ISO IDMP standards, supporting its implementation and removing the need to convert/transform the information. The databases are split in four main services: SMS, PMS, OMS and RFS: • Substance Management Services (SMS) SMS provides a central dictionary of substance data in multiple languages, composed by “harmonised data and definitions to uniquely identify the ingredients and materials that constitute a medicinal product”31. SMS supports the continuous exchange of data between information systems across the European medicines regulatory network and across the pharmaceutical industry. SMS is currently live as an EMA internal system. Until it is onboarded in the SPOR portal, external users should use the following systems: • View and search substance data in European Union Telematics Controlled Terms (EUTCT)32 or IRIS33; • Submit substance change requests in the EMA Service Desk34 portal. 29 1. Vander Stichele R, Kalra D. Aggregations of Substance in Virtual Drug Models Based on ISO/CEN Standards for Identification of Medicinal Products (IDMP). Stud Health Technol Inform. 2022 May 25; 294:377-381. doi: 10.3233/SHTI220478 2. Vander Stichele, Robert H., Joseph Roumier, and Dirk van Nimwegen. 2022. "How Granular Can a Dose Form Be Described? Considering EDQM Standard Terms for a Global Terminology" Applied Sciences 12, no. 9: 4337. https://doi.org/10.3390/app12094337 3. Karpetian N, Vander Stichele RH, Quintana Y. Alignment of two standard terminologies for dosage form: RxNorm from the National Library of Medicine for the United States and EDQM from the European Directorate for the Quality in Medicines and Healthcare for Europe. IJMI, accepted for publication, in press. 30 https://spor.ema.europa.eu/sporwi/ 31 https://www.ema.europa.eu/en/human-regulatory/research-development/data-medicines-iso-idmpstandards/substance-product-organisation-referential-spor-master-data 32 http://eutct.ema.europa.eu/ 33 https://iris.ema.europa.eu/substances/ 34 https://servicedesk.ema.europa.eu/ UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 34 of 69 This coding system was recently adopted by eHDSI (going live in wave 6 of eHDSI) to support the description of the substances on eHealth services and should be the preferred coding system in this regard. • Product Management Services (PMS) PMS encompasses “harmonised data and definitions to uniquely identify a medicinal product based on regulated information (e.g., marketing authorisation, packaging and medicinal information)”31. PMS will cover a subset of the authorised medicinal product part of the ISO IDMP standards. However, this database is not yet available. Future PMS iterations will implement other product data elements of the authorised medicinal product and the investigational medicinal product part of the ISO IDMP standards. • Organisation Management Services (OMS)35 OMS provides a central dictionary of organisation data in multiple languages. It covers organisation names; location address details; communication details such as email address and telephone number per location. It is already in use and should be the used to describe the organization name in the ‘Market Authorization Holder’ attribute. • Referentials Management Services (RMS)36 RMS provides referentials lists and terms (such as routes of administration, dose forms, unit of presentation) in multiple languages (the 24 official languages of the EU, and 13 other languages relevant to the European Council). RMS supports the continuous exchange of data between information systems across the European medicines regulatory network and the pharmaceutical industry. RMS replaces the European Union Telematics Controlled Terms (EUTCT) system as the repository of referentials and controlled terms. However, stakeholders should continue to use EUTCT to browse lists of substances until the new SMS become available. It also presents lists of terms that are managed and maintained by organisations other than EMA, such as WHO-ATC and EDQM. Those lists are updated accordingly by the system owner. This update does not change the previous coding system. The use of RMS as a coding system for the different attributes listed Table 2 should be considered in the future. Currently, eHDSI has no value sets or transcoding tables for RMS and if this coding system is the preferred choice of NCAs, then it shall be transcoded to the indicated preferred coding system to exchange clinical documents on cross-border context. RMS provides a mapping between each RMS ID and the main sources used (e.g., EDQM, UCUM, ATC, etc). As a result, it constitutes an opportunity to connect different coding systems assuming that NCAs will provide the information of the exact coding system that being provided to the system to exchange eP/eD and PS throughout eHDSI. 3.2.2 WHO-ATC 37 In the Anatomical Therapeutic Chemical (ATC) classification system, the active substances are divided into different groups according to the organ or system on which they act and their therapeutic, pharmacological and chemical properties. Drugs are classified into groups at five different levels (Table 6). This system is managed by the World Health Organisation (WHO) Collaborating Centre for Drug Statistics Methodology. 35 https://spor.ema.europa.eu/omswi/ 36 https://spor.ema.europa.eu/rmswi/ 37 https://www.who.int/tools/atc-ddd-toolkit/atc-classification UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 35 of 69 Table 6: ATC levels description ATC Level Description 1 st The system has fourteen main anatomical or pharmacological groups (1st level). 2nd Pharmacological or Therapeutic subgroup 3rd and 4th Chemical, Pharmacological or Therapeutic subgroup 5th Chemical substance The ATC codes are broadly used for the classification of medicinal products among different countries. It is already in use on the eHDSI for the identification of ‘active substance’, which is not the proper use and, as such, it should be maintained for classification of medicinal product packages, in such a way that it is instrumental to drug utilisation research and drug consumption statistics. Assigning the ATC code at the Medicinal product package level is important, as DDD can differ according to oral and parenteral products. Also, it is at the medicinal product package level that the number of DDD per pack are calculated. From now on, the identification of the ’substance’ as the ‘substance with the role of precise active ingredient’ is achieved by using SPOR-SMS. On eHDSI infrastructure. 3.2.3 EDQM38 The European Directorate for the Quality of Medicines & HealthCare (EDQM) is responsible for, developing and monitoring the application of quality standards for medicines and their safe use, which is recognised as a scientific benchmark and applied worldwide. It presents lists for the classifications of most attributes required on the MALeH and is the preferred coding system on eHDSI infrastructure. The NCA provide the EDQM code over the RMS code. In the future the eHDSI should also adopt the RMS as coding system, until it happens, the EDQM should be preferred. 3.2.4 UCUM39 The Unified Code for Units of Measure (UCUM) is a code system intended to include all units of measures being contemporarily used in international science, engineering, and business. The purpose is to facilitate unambiguous electronic communication of quantities together with their units. The focus is on electronic communication, as opposed to communication between humans. This coding system can also be used to describe many attributes on MALeH and should also be preferred over RMS for the time being. The codification on UCUM or EDQM has the same impact once eHDSI has value sets to describe both coding systems, namely SPOR-RMS 3.3 ISO IDMP Identifiers To describe medicinal products, there are a series of different attributes that can contribute to their identification for diverse proposes, such as i) eP/eD & PS; ii) pharmacovigilance; and iii) EMA communication, among others. From those attributes described in the ISO IDMP standards, it is also possible to generate some identifiers that are based on the attributes and the market authorisation/registration in the national bodies. In the IDMP definition is possible to present 3 different identifiers: • PhPID – Pharmaceutical Product Identifier • MPID – Medicinal Product Identifier • PCID – Package Medicinal Product Identifier 38 https://www.edqm.eu/en/ 39 https://ucum.org/trac UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 36 of 69 Noteworthy, these identifiers are not yet available. However, the eHDSI has already included fields for their representation, allowing its use on the eP/eD and PS services in eHDSI infrastructure to be used in the future. These identifiers will be described in detail below. 3.3.1 Attributes required to generate PhPID • ISO IDMP PhPID Overview The Pharmaceutical Product Identifier (PhPID) is a global-level identifier that is uniquely assigned at the pharmaceutical product level. According to the ISO 1161640, the PhPID is represented within two strata – active substance stratum and specified substance stratum, and both comprise four PhPID identification levels for each pharmaceutical product contained in a medicinal product. PhPID is generated by using: • Substance standard (ISO 11238 and ISO/TS 19844) • Strength (ISO 11239 and ISO/TS 20440) o The reference strength shall be repeated in both PhPID strata, and is derived from the active moiety / moieties of an active substance (depending on the specific product characteristics) • Administrable dose form (ISO 11239 and ISO/TS 20440) • Unit of measurement standard (ISO 11240) For products that requires reconstitution (e.g., powder + liquid for solution), the PhPID shall consider the administrable dose form, which already considers this initial reconstitution step. Figure 6: PhPID four levels. 40 ISO 11616 - Health informatics — Identification of medicinal products — Data elements and structures for unique identification and exchange of regulated pharmaceutical product information PhPID active substance stratum PhPID_SUB_L1 Substance PhPID_SUB_L2 Substance(s) + strenght + reference strenght PhPID_SUB_L3 Substance(s)+ administrable dose form PhPID_SUB_L4 Substance(s) + strength + reference strenght + administrable dose form PhPID specified substance stratum PhPID_SpSUB_L1 Substance PhPID_SpSUB_L2 Substance(s) + strenght + reference strenght PhPID_SpSUB_L3 Substance(s)+ administrable dose form PhPID_SpSUB_L4 Substance(s) + strength + reference strenght + administrable dose form UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 37 of 69 Table 7 shows the relationship between the elements of a pharmaceutical product and their respective cardinality. Table 7: Cardinality relationships that shall be respected within the elements of a pharmaceutical product, according to ISO 11616 Cardinality relationship PhPID has one administrable dose form 1..1 PhPID may have zero to one unit of presentation a) 0..1 PhPID has one or more active substances 1..* PhPID has one strength b) – based on one-to-many active substances or Specified substances 1..1 1..* PhPID has one to many reference strengths (i.e., active moieties with a corresponding strength), as it relates to the strength of one-to-many active substances/specified substances 1..* Notes: a) This is frequently employed specifically at the point of delivery to the patient in situations where a quantitative unit of measurement is not appropriate; b) For liquid preparations, the strength (presentation) and strength (concentration) shall both be represented. Moreover, a PhPID shall be generated to represent the strength concentration. In this case, this shall be known as product code concept, since it represents a calculation of the strength presentation of a liquid preparation as authorised. As the PhPID is generated based on the attributes of the medicinal product, all the products that share the same exact attributes have the same PhPID code, irrespective of the country where the medicine is registered. Conversely, PhPID does not convey all the information to identify the dispensed product as a packed medicinal product, and further information could be required. Taking this into consideration, the use of PhPID wherever possible will enhance the translating and transcoding of medicinal product information to assure the correct identification and thus the safe and accurate dispensation. • EMA SPOR Implementation Guide According to EMA PMS Implementation Guide Chapter 2 – Version 2.141, no information is provided on this report regarding on “additional identifiers such as the Pharmaceutical Product Identifier (PhPID). Further details on the related definitions and defining elements will be available at later stage as it requires further discussions prior the implementation. Moreover, additional clarifications on the PMS ID defining elements and the relationship with the MPID will be provided in the EU IG v2.2 release”. Status and Attributes importance • Currently, there is no process defined for the generation and governance of PhPID codes, as well as the timeline for this development. • The use of the attributes needed to generate the PhPID codes will facilitate its implementation in future iterations. • An automatic way of generating such identifiers and attributes codes will facilitate this implementation and decrease the probability of errors. • Considering the global impact of PhPID codes, a governance model at this level should also be defined, which will involve institutions of different parts of the world. Currently, intense discussions between EMA, FDA, and WHO_UMC are ongoing regarding this issue in the Global IDMP Working Group GIDWIG. • Medicinal product databases should include the attributes needed to generate PhPID: o Substance(s) o Reference strength o Reference strength 41 Product Management Service (PMS) - Implementation of International Organization for Standardization (ISO) standards for the identification of medicinal products (IDMP) in Europe, Chapter 2: Data elements for the electronic submission of information on medicinal products for human use Version 2.1. EMA/285848/2020, 24 June 2021. Available at https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/product-management-services-pmsimplementation-international-organization-standardization-iso_en-0.pdf UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 38 of 69 o Administrable dose form • Medicinal product databases should map these attributes, their compliance to ISO IDMP, and preferentially opt for structured coded data. 3.3.2 MPID generation According to the ISO 11615:201742, the Medicinal Product Identifier (MPID) is uniquely associated to each medicinal product authorised in a country. It shall be associated to any national authorisation number. The MPID shall “use a common segment pattern related to a Medicinal Product, which when each segment is valued shall define a specific MPID concept”42. The pattern is composed by: a) country code segment (ISO 3166-1 alpha-2 code elements); b) marketing authorisation holder (organisation identifier) code segment; c) Medicinal Product code segment. A new MPID shall be assigned if any of the values associated with these three codes changes. According to the ISO IDMP 1161542 standard, a new MPID can be assigned to a product following a substantial change in the product (e.g., change in indication) but also for administrative reasons (e.g., change in marketing authorisation holder). The variability of an MPID and the complexity of its constitution means that many drug verbatims cannot have an MPID accurately coded based on the information provided if more than one MPID would be available for that product. The MPID is assigned in accordance with the country code segment, marketing authorisation holder and Medicinal Product code segment. In a national context, it can be used to define specific brand product in the eP, however the identification of generic medicines on eD is challenging. Considering both contexts (national and cross-border), MPID may be used in both the eD report and PS document, to indicate accurately the product that was dispensed (eD) or used by the patient (PS). 3.3.3 PCID generation According to the ISO IDMP 11615, the Package Medicinal Product Identifier (PCID)42Error! Bookmark not defined. is associated to each package medicinal product authorised in a country. The PCID shall “use a common segment pattern related to a package of a Medicinal Product, which when each segment is valued, shall define a specific PCID concept”42. The pattern is composed by: a) MPID for the Medicinal Product; b) package description code segment, which refers to a unique identifier for each package. A new PCID shall be assigned if any of the values associated to these code segments changes. The PCID is more detailed than MPID because it includes the medicinal products’ packaging information. Several PCIDs can be associated with one MPID, such as: same medicinal product in two different box presentations: box with 20 pills, or box with 30 pills. As the PCID is a further refinement of product specification when compared to the MPID (the PCID only increases in the ‘package description’), it has the same implications as MPID, so the same considerations mentioned above for MPID are also applicable for the use of PCID in the eHealth services. 42 https://www.iso.org/standard/70150.html UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 39 of 69 4 Minimum data set specifications Fully specifying a data set means, in our case, defining the structure of the data elements and populating that structure. In other words, the Minimum Data Set consists of the MALeH instantiated for a minimum set of products. A formal definition of the MALeH should be structured (as opposed to verbose, human-readable), to ensure that such specifications are understood by everyone. This can be done in several ways – data dictionaries, formal (logical) data models, and using technical languages such as Unified Modelling Language (UML) or Fast Health Interoperability Resources (FHIR) for Logical Data Models). These specifications are semantic specifications and as such are at the logical level – expressing entities, their definitions, relationships and constraints – following the same indications as in UNICOM Deliverable D1.2 – ‘Requirements for a new ISO logical model [platform independent]’43, and the same approach that is used in the ART-DECOR® specifications for eHDSI. The attributes that are required depend on the core attributes to identify a product, and additional operational attributes that are required to ensure proper operations. These required attributes depend on the intended use. It is therefore important to consider the scope of application when defining the minimum attribute list, and possibly validate and iterate with concrete examples. These functionalities may require slightly different semantic specifications, or “dialects”, (for example in terms of required data elements) – which should be supported, as long as they remain compatible with the common data specifications. These “dialects” are identified with an analysis of the intended application of IDMP – they are “subscopes” of the broader scope for IDMP adoption and usage: • ePrescription • eDispensation • Patient Summary Also, there are other attribute sets for other purposes, such as the subset of data needed to produce and maintain unique and global PhPIDs. Such a breakdown provides a checklist that can be used for monitoring the progress of adoption - i.e., whether a Member State adopts IDMP specifications for ePrescription, or eDispensation, or Patient Summary, or all. While it is expected that the data needs will be different for the different use cases, they all should share the common specifications in the MALeH. For this reason, the specification is done for the entire MALeH at once (from where it can be focussed on for the different use cases if needed). Another advantage of allowing and documenting such sub-scopes and respective semantic dialects is that later scopes can be added, as long as they remain compatible with the same model – which in turn is compatible with the adjacent models like the regulatory model, the eHDSI specifications, etc. The diagram below (Figure 7) presents another perspective on how these models relate to each other: 43 https://unicom-project.eu/wp-content/uploads/2022/01/UNICOM_D1.2-Logical-Model_Final.pdf UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 40 of 69 Figure 7: IDMP related data models and their relationship Figure 7 illustrates that all the models are a specification of IDMP – DS1 being the Data Specifications for the “full” IDMP, and the UNICOM Minimum Attribute List (represented by DS2) provides a “core” semantic specification, which is then sub-specialised in the ePrescription and eDispensation models (as well, for example, as the national drug databases and the data specifications for the PhPID generation) and they are related to the eHDSI specifications – following the alignment and recommendations done from UNICOM towards the eHDSI change procedure. These are not technical format specifications - i.e., they are not Clinical Document Architecture (CDA) or FHIR or any other technical format – the logical specifications can then be realised in different technical specifications as Clinical Document Architecture (CDA), FHIR, or others. Analysing the specifications in this and previous UNICOM deliverables, the following diagram presents the MALeH expressed as a Logical Data Model. This Logical Data Model44 is expressed in UML and is “flatter” than the FHIR resources being currently designed – for 3 main reasons: 1. Logical data models can be inspired by physical implementations, but they should be independent from any physical implementation like FHIR resources; 2. Logical data models define the data that is needed, and that is less likely to change than technical specifications – for example the FHIR resources are still in low maturity and some changes can be expected, while the logical data model is expected to remain more stable. 3. A flatter attribute list can be implemented in clinical systems or regulatory systems, where the necessary hierarchies can be created. An example: in a prescription, we can prescribe either a medicinal product or a packaged product, or something in between, or a combination of attributes of each. There is no need to force a hierarchical model, for example using 2 or 3 data structures to represent something simple like a Virtual Medicinal Packaged Product (VMPP). In the clinical document (prescription) this can be represented as a single data object, while in the 44 The current Logical Model for the MALeH is available under: https://build.fhir.org/ig/hl7-eu/unicom-ig/branches/D5.7/StructureDefinition-MinimumAttributeList.html#tabs-diff and will be published in its final destination once UNICOM technical FHIR specifications have a first release. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 41 of 69 regulatory databases this can still be represented as a single data object or as multiple data objects for EMA submission purposes, for example. This way, by focusing on the data that is needed, and not present more data or additional structures, the MALeH can be implemented in different “technical flavours”, as required. This presents the least impositions on the architecture – choosing a more complex structure will impose some technical architecture constraints. One conclusion that can be taken is that the semantic specifications can be defined in different ways – and the key specifications can be captured in slightly different models – in other words, there are different ways to specify a model based on the semantic requirements. For this document we use the FHIR representation of a logical data model (which is not the same as FHIR specifications, as it does not consider any specific FHIR resources, only the data structures). This further reveals the interest of having a formal, documented logical data model for IDMP (as proposed in UNICOM D1.243 - an effort that is being developed by ISO TC215 WG645). Once that model is available (DS1 in Figure 7, then it will be even easier to confer the alignment between the logical data model for the MALeH. A note on the value sets in the logical data model: Adding them to a logical data model would ideally require a unique identifier of the value set (e.g., a unique URL (Uniform Resource Locator) or OID (standard Object Identifier46) for “Authorised Pharmaceutical Form” and another for “Package type”, - as well as for “Route of Administration”, etc.). At the moment, what is known is that Authorised Pharmaceutical Form and Pack are both from EDQM, but the value sets need to be defined. While these are not technically available from SPOR (and made available on a terminology server), the logical data model captures the need for the value sets but cannot point to a published value set. 5 Adoption Assessment Understanding that IDMP adoption is a major and complex migration, there should be no expectations of a rapid “big bang” approach by all Member States simultaneously. Like the rest of the eHealth specifications, Member States require the preparedness and autonomy to phase in such changes. Therefore, it is fundamental to facilitate and monitor the adoption by the Member States – and ideally the consequent effectiveness of interoperability. This in turn requires consistent criteria for such monitoring, as well as providing facilitators (methods, tools) for the adoption of IDMP / UNICOM recommendations. The MALeH presents both the common semantic specifications that can be used as a target, and the content, which can be used as a facilitator and some test criteria/test data. 5.1 Semantic compatibility assessment As described in previous deliverables in this work package, the establishment of a reference semantic specification is a fundamental step towards assessing semantic compatibility of systems, by providing a common specification that both systems should adhere to. This materialises the need of Semantic Compatibility (or semantic interoperability): whether 2 or more systems express data that has a common or compatible meaning. This notion of “compatibility” normally introduces some pitfalls, so it is important to clarify a few aspects: • Using a single database vs allowing different interoperable systems: Semantic compatibility means that systems are compatible, not that they are the same system. One common pitfall is to resort to a central data store that stores everything, but while that may appear 45 http://isotc215-wg6.team/ 46 https://en.wikipedia.org/wiki/Object_identifier UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 48 of 69 4. Semantic specifications shall be compared with the target / UNICOM MALeH specifications – each member state should keep a correspondence between the national specifications and the common specifications – noting where there are conflicts or gaps. a. Conflicts are actual differences for example completely different value sets, or different definitions. Gaps are missing correspondences e.g., an attribute that exists in the national specification but not in the MALeH or vice-versa. 5. All changes to the semantic specifications should be controlled changes – Member States should keep track of the changes that are needed or that were implemented. a. An overview of the data structures and data elements, with their full definition, and the statuses like “matching”, “compatible” or “different” - where “compatible” means that there are gaps but no conflicting discrepancies. 6. A common list of products should exist, to validate the models a. There should be a process (and possibly a set of roles like a committee or contact person) to validate the models with the products, namely the common products in the minimum data set. b. There should be a process to enter national product data into a IDMP compatible format. This can be aligned with the regulatory activities, or taken from existing data, or any other way decided by the NCA. c. It is expected that not all the data will be immediately converted to the IDMP compatible It is highly recommended that NCAs start their conversion and adoption from the Minimum Attribute List (as defined above) and with limited set of products (the lot products that contain the 35 substances identified as more relevant) 7. There should be a clear, documented mapping between the national semantic specifications and the technical implementations – a. to the national drug databases b. To the national ePrescription / eDispensation / Patient Summary specifications c. To the common eHDSI specifications With these principal processes and roles in place, the monitoring of progress will be facilitated, and most importantly, the actual progress of the member states will be facilitated, as there can be Communities of Practice, common solutions to common problems, guidance on key aspects, good practices, etc. In other words, some degree of industrialisation of the process will greatly benefit the work that needs to be done, and the monitoring of the progress. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 49 of 69 9 Annexes Annex 1 – Pilot Product List (PPL) The PPL contains 35 substances (PhPID L1) that have been selected for the UNICOM pilots and should be considered by NCAs and eHealth Agencies when planning the Pilots / data provision. Table 8: Pilot Product List # Moiety Salt/ester/modification (and notes, synonyms) 1 simvastatin 2 enalapril enalapril sodium enalapril maleate enalaprilat 3 omeprazole omeprazole sodium omeprazole magnesium 4 diclofenac diclofenac sodium diclofenac potassium diclofenac diethylamine (synonym: diclofenac diethylammonium) diclofenac epolamine 5 cefuroxime cefuroxime sodium cefuroxime axetil 6 salbutamol salbutamol sulfate 7 amoxicillin and clavulanic acid amoxicillin (anhydrous, explicitly) amoxicillin (unspecified) clavulanic acid amoxicillin sodium amoxicillin trihydrate potassium clavulanate 8 insulin glargine 9 teriparatide 10 drospirenone and ethinylestradiol drospirenone ethinylestradiol 11 atorvastatin, amlodipine and perindopril 12 calcium + vitamin D calcium carbonate ergocalciferol 13 paracetamol 14 diazepam 15 morphine morphine hydrochloride morphine sulfate morphine tartrate morphine liposomal (sulfate) 16 enoxaparin enoxaparin sodium 17 hydrocortisone hydrocortisone sodium succinate hydrocortisone valerate hydrocortisone acetate UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 50 of 69 # Moiety Salt/ester/modification (and notes, synonyms) hydrocortisone butyrate hydrocortisone aceponate hydrocortisone probutate (synonyms: butyrate propionate; buteprate) hydrocortisone cypionate hydrocortisone sodium phosphate 18 lidocaine lidocaine hydrochloride also tosilate, hydrocarbonate, bicarbonate, maleate, carbonate - but not used in products? 19 trastuzumab trastuzumab emtansine (synonym: ado-trastuzumab emtansine) trastuzumab deruxtecan 20 imatinib imatinib mesilate 21 clomipramine clomipramine hydrochloride 22 carbamazepine 23 metformin metformin hydrochloride metformin pamoate (synonym: metformin embonate) 24 amlodipine (racemic) amlodipine besilate amlodipine benzoate amlodipine maleate 25 perindopril perindopril arginine perindopril erbumine (synonym: perindopril tert-butylamine) perindopril erbumine monohydrate perindopril tosilate 26 tramadol (racemic) tramadol hydrochloride 27 ciclosporine Synonym: ciclosporin A 28 itraconazole itraconazole trihydrochloride 29 goserelin goserelin acetate 30 glyceryl trinitrate nitroglycerin 31 chloroquine chloroquine phosphate chloroquine sulfate chloroquine hydrochloride 32 clotrimazole 33 varenicline varenicline tartrate varenicline dihydrochloride 34 ibuprofen (racemic) ibuprofen sodium ibuprofen lysine 35 tafluprost UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 51 of 69 Annex 2 – CP-eHDSI-066: Prepare eHDSI Requirements Catalogue for ISO IDMP Change Proposal Summary information Change Proposal Title: ISO IDMP Adoption by eHDSI – Business Requirements Submitter’s Name(s) and e-mail address(es): Oskar Thunman [email protected] Submission Date: 08/10/2021 Component(s) or Configuration item(s) to be changed48: eHDSI Business requirements Actor(s) affected: Business and Solution Requirements impacted: 05.01. Create the eHDSI Patient Summary content 05.02. Transcode, translate and exchange cross-border the Patient Summary 06. Make ePrescription available to HP 06.01. Create the eHDSI ePrescription(s) content 06.02. Transcode, translate and exchange cross-border the ePrescription 07. Handle Dispensation of medicine and Substitution 07.01. Create the eHDSI eDispensation content 07.02. Transcode, translate and exchange cross-border the eDispensation 09. Ensure high quality information (structured, equivalent, understandable) is exchanged between countries Specifications/documentation impacted: See the list above Change estimated impact 49 (minor, major): Minor 48 Component examples: Client connector, WS server, OpenNCP Portal, epSOSWeb, OpenATNA, TRC-STS, Security Manager, TSL-Sync, TSL-Editor, TSL-Util, Protocol Terminators, TSAM Sync, Stork Plugin, CDA display tool, xslttransformer, tsamexporter, cdautils, epsos-util, configuration manager, epsos-common-components, e-SENS eID richclient, e-SENS eID design-main… 49 Change estimated impact is the estimated order of magnitude of the change: a change will be qualified as major if it introduces for instance a component that already exists or a new component, impacting the architecture; it will be qualified as minor if it improves the existing behavior without impacting the architecture. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 52 of 69 Change Proposal Description Please consider that this is the section used by the eHDSI stakeholders when assessing the impact of the requested change proposal. REASON/BUSINESS JUSTIFICATION (WHY this change is needed) The implementation of the ISO IDMP standard in EMA SPOR databases is changing how medicinal products are (a) identified and (b) described by the National Competent Authorities, which will inform future eHealth System implementations at both national and regional level. The goal with this change proposal is to enable the eHDSI services to make use of ISO IDMP to solve known challenges in representing medicinal products for the cross-border use cases. This includes known challenges such as complex packages, different representations of dose forms and strengths and identifying prescribed and dispensed medicinal products using unique identifiers. The CP is therefore related to the CP “Medication Information Representation Improvements”, which is being processed in parallel. It is important to provide support for the new way of identifying and describing medicinal products because this information is used in the ePrescription/eDispensation & Patient Summary (Medication Section) data sets. There are significant benefits to making use of ISO IDMP standard including, but not limited to, improving the presentation of information about medicinal products, and streamlining the dispensation process in many cases. The implementation of ISO IDMP is predicted in the Commission Implementing Regulation (EU) Nº 520/2012, articles 25 and 26, which obliges EU MS, marketing authorisation holders and EMA to make use of the ISO IDMP standards. In order to ensure a correct implementation of ISO IDMP in the eHDSI specifications, this CP aims at introducing new phrasings for relevant identified business requirements to the ePrescription & Patient Summary services. It is noted (also mentioned in UNICOM D5.1 - Business requirements for the adoption of IDMP in eHealth Services) that the adoption of IDMP does not impose that countries must use exclusively IDMP in their national processes – in short, national processes shall still be able to use national models). Therefore, IDMP adoption appends, but not necessarily restricts, data exchange at national and cross-border levels. Those identified changes were previously evaluated through intense study and their implementation will support the further ISO IDMP implementation. This CP focuses on eP/eD related requirements. The work done is also beneficial to update PS related requirements. It is suggested that, when implemented, PS Cluster is involved to get aligned requirements. In preparation of this CP, a few missing data elements were discovered in the Data elements descriptions in the eHDSI Requirements Catalogue. This CP also contains a few suggested clarifications and suggested additions to the Data elements descriptions to better reflect the current CDA implementation, although this is not directly IDMP-related. DESCRIPTION OF THE REQUESTED CHANGE Background information Glossary General EMA SPOR Data management services by European Medicines Agency. The four SPOR data management services are: - SMS: substance management service - PMS: product management service - OMS: organisation management service UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 53 of 69 - RMS: referentials management service (value sets) More information can be found on EMA SPOR web site. Identifiers MPID Medicinal product identifier. Unique identifier assigned to a branded product. The MPID is tied to the marketing authorisation life cycle and the same product is assigned a new MPID when the marketing authorisation changes. PMS ID Product Management Service identifier. PMS ID is a unique identifier of the medicinal product in EMA SPOR PMS system. Unlike the MPID, PMS ID remains unchanged during the entire lifecycle of the product. PMS ID is not in the original data model of ISO IDMP, but an extension by EMA. PhPID Pharmaceutical product identifier is a unique identifier of the product on a generic level. The PhPID is calculated on the basis of ingredients, strength, administrable dose form. Unique PhPIDs and different levels of PhPID will be available in the future. PCID Packaged medicinal product identifier. PCID consists of two parts: the corresponding MPID and the package description code segment. A unique PCID is assigned for each package that has a different set of size, package type/material or manufactured items. Dose forms Authorised dose form The pharmaceutical dose form as authorised by regulatory authorities. This includes combined pharmaceutical forms like Powder and solvent for solution for injection. Authorised dose form is not in the original data model of ISO IDMP, but an extension by EMA. Administrable dose form Pharmaceutical dose form in which the product is administered to the patient. For example, in case of the example given for the authorised dose form section, the corresponding administrable dose form is Solution for injection. Manufactured dose form Pharmaceutical dose form of a manufactured item (before transformation into the pharmaceutical product). One medicinal product may consist of several manufactured products with different manufactured dose forms, e.g., Solution for solution for injection, Powder for solution for injection. Strengths Reference strength Reference strength represents the strength of the active moiety to express the strength of the product. If the active substance in the product is salt or ester, the reference strength would be different from the presentation/concentration strength. For example: if the strength for omeprazole magnesium is 20.6mg/tablet; the reference strength of the product would be described as omeprazole 20mg/tablet. Concentration strength Concentration strength represents the amount of an active ingredient per single unit of measure. This is the regular way of describing the strength for liquid dose forms, e.g., 10mg/g. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 54 of 69 Presentation strength Presentation strength represents the amount of an active ingredient per one unit of presentation. This is the regular way of describing the strength for tablets, capsules and other solid countable items. This information would also be available for other dose forms, e.g., 10mg/vial, 120mg/bottle, 50mcg/actuation. Units Unit of measurement Units of measurements are standardized quantities of measurement. The eHDSI and EMA SPOR both make use of the UCUM list of units of measure. Unit of presentation Unit of presentation describes the single countable entity in which a pharmaceutical product or manufactured item is presented. Although unit of presentation has an overlapping content with package types as well as dose forms, it should not be confused with either of them. Full ISO IDMP data model is a complex set of data elements in a specific structure. The granularity of this information is suitable for the regulatory authorities. Even though it is expected, that having unified and more detailed medication data available on a national and international level will change the way this data is represented in all the information systems, there is no clear guidance on if, how or when these changes should be implemented in national prescription systems. eHDSI is not aiming to implement full ISO IDMP in the eHDSI services, but to make use of ISO IDMP data model and EMA SPOR value sets to improve our services and make it possible for member states to send their data in a similar (but simplified) format. However, it must be stated, that if a member state is not capable of sending this data, it can still use the services, and the new attributes and layers of information will be optional on country A side. To plan the upcoming changes, some changes have to be made in the business requirements that are listed below. In many cases, the actual change is still up for discussion, but it is important to show the relations between current business requirements, parallel change requests and possible future implementation changes that are still up for discussion. For more information about implementing ISO IDMP in EMA SPOR, please refer to EU ISO IDMP Implementation Guide. List of improvements and discussion points 05.01 Create the eHDSI Patient Summary content Requested change The table named “The dependencies between the information exchanged in both services” should be removed/replaced, as it is partly misleading. Further analysis needed There is an overlapping content in Patient Summary’s medication summary and ePrescription and eDispensation. These data sets should be harmonised where necessary and the ePrescription content changes described below (requirement 06.01) should be taken into account. Impact No impact at this point. Requested change aims to clarify the actual existing content. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 55 of 69 Any decisions emerging from the analysis of the PS content will be communicated to the member states separately and member states will have an opportunity to agree or disagree with the change. 05.02 Transcode, translate and exchange cross-border the Patient Summary. Change requests No changes are required to the business requirement text at this time. Further analysis Additional translations and transcodings might be required, in the event of new code systems and value sets being developed and introduced, switching to EMA SPOR value sets where necessary. The use of ISO IDMP will positively contribute to the implementation of this business requirement in the future by replacing some of the textual elements with coded entries and improving the data structure. Impact No impact, as the possible future changes will be approved by member states before implementation. 06.01 Create the eHDSI ePrescription content. GENERAL Further analysis needed The data sets used for the Medication Summary section in Patient Summary, ePrescription and eDispensation should be harmonised (use of the same attributes and elements to describe the medicinal products, for the different use cases) across the use cases; eP/eD and PS. While product information should be harmonised, it is important also to acknowledge that the level of detail about products in an ePrescription may differ from the level of detail in a eDispense – in a prescription, the product information can be more or less granular, but dispenses are reported with much more detail (as reported in UNICOM D5.2). Therefore, we suggest to start by splitting the notion of Prescribed Product and Dispensed Product. The exact content and cardinality of data elements is yet to be discussed more thoroughly and agreed with the member states. Impact The change has no impact on member states at this point. The exact changes are negotiable and have to be agreed by member states. Any changes in the cardinality of data elements must take into account that member states who are already active in the eHDSI services must be able to continue data exchange. IMPROVE DESCRIPTION OF DATA ELEMENTS Requested changes Add ATC code to the specification as it is already supported by the technical specifications but absent from the business requirements. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 56 of 69 Add Packaged product description text field into the data set specification to provide a sufficiently detailed description of the prescribed medicinal product/package. Add and clarify information according to the parallel CP “Medication Information Representation Improvements”. The business requirements should help understand how to describe layers of complex packages and how to use MPID and PCID or their national equivalents. Impact No impact. The changes are simply rephrasing the business requirements to give better explanation of the existing solution and the parallel CP (agreed by Member States independently from this CP). NEW DATA ELEMENTS FOR DISCUSSION IDMP identifiers Further analysis needed ISO IDMP and EMA SPOR introduce a list of identifiers to be used on different levels for identifying a medicinal product or its package. Enable provision of ISO IDMP identifiers in addition to the currently supported “national code”: PCID, MPID, PhPIDs; assuring that the type of each IDMP ID is correctly identified, including the multiple levels of PhPID. Introducing new identifiers requires corresponding data structure to be implemented. Any changes in the implementation needs to take into account that not all member states have this data available at the same time and using new identifiers must remain optional. Parallel CP “Medication Information Representation Improvements” proposes adding PCID, but also states that using this data element is optional and a national package identifier can be used. Impact No impact at this point. Ingredients and strenghts Further analysis needed ISO IDMP and EMA SPOR SMS provide an opportunity to identify all the ingredients in the product: active ingredients as well as other ingredients such as adjuvants or additives (e.g., lactose). It should be thoroughly analysed how this information could improve the quality of eHDSI services. The strength of active ingredients could also be described more precisely by adopting the ISO IDMP model for expressing strength. For example, by adding reference strength, it would be possible to express the strength by the quantity of salt (omeprazole magnesium) as well as by the active moiety within the salt (omeprazole). The example below is a piece of ISO IDMP data model from EU ISO IDMP Implementation Guide (Chapter 8, Annex I “Complete Representation”). UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 57 of 69 Impact No impact at this point. Member states are invited to discuss the need and opportunities to express additional information about ingredients and strengths. Package size Requested changes The most important changes in representing the contents of the package are proposed as a separate CP “Medication Information Representation Improvements”. These changes follow the structural and conceptual logic of ISO IDMP and would help us overcome the main problems we’re facing today: representing multi-layer packages (e.g., 5 vials of 3ml as one product) and complex packages (e.g., creme + tablets marketed as one product). The business requirements must be renewed according to these changes, so that the description of the data element Medicinal product package would explain how the nested structure helps calculate the total amount of the product within a package or the overall amount prescribed on an ePrescription. Impact No impact to the member states as this change requests only states the need to renew the business requirements. The actual change request for implementation changes is processed separately. The change itself will improve the reliability of crossborder eP by removing ambiguities and increasing dispensability. Dose forms and unit of presentation: Further analysis needed UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 64 of 69 Value Set name Value Set ID Code System(s) Code System(s) ID Version(s) of Code System used in MVC eHDSISubstitutionCode 1.3.6.1.4.1.12559.11 .10.1.3.1.42.7 HL7 v3 substanceAdminSubstitut ion 2.16.840.1.113 883.5.1070 91320091020 eHDSITelecomAddress 1.3.6.1.4.1.12559.11 .10.1.3.1.42.40 HL7 v3 AddressUse 2.16.840.1.113 883.5.1119 91320091020 eHDSITimingEvent 1.3.6.1.4.1.12559.11 .10.1.3.1.42.41 HL7 v3 TimingEvent 2.16.840.1.113 883.5.139 91320091020 FHIR Event Timing 2.16.840.1.113 883.4.642.4.13 71 4.0.1 eHDSIUnit 1.3.6.1.4.1.12559.11 .10.1.3.1.42.16 UCUM Unified Code for Units of Measure 2.16.840.1.113 883.6.8 April 2021 eHDSIVaccine 1.3.6.1.4.1.12559.11 .10.1.3.1.42.28 ATC Classification 2.16.840.1.113 883.6.73 2022-01 SNOMED CT 2.16.840.1.113 883.6.96 43677 44469 UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 65 of 69 Annex 4 – CP-eHDSI-063: Improve Medication Information Representation Change Proposal Summary information Change Proposal Title: Medication Information representation improvements Submitter’s Name(s) and e-mail address(es): Christof Geßner, [email protected] Submission Date: 30/09/2021 Component(s) or Configuration item(s) to be changed50: CDA IG, OpenNCP, CDA Display Tool Actor(s) affected: • eHMSEG STF Architecture workgroup • eP cluster Business and Solution Requirements impacted: - Specifications/documentation impacted: - Change estimated impact 51 (minor, major): minor Change Proposal Description Please consider that this is the section used by the eHDSI stakeholders when assessing the impact of the requested change proposal. REASON/BUSINESS JUSTIFICATION (WHY this change is needed) Since some time, the concern was raised by Member States that it is impossible to represent some complex medication packages using the existing CDA IG template definitions. Examples of complex medicinal packages were collected by Member States and the analysis and investigation was started in the eHMSEG STF Architecture WG on how these examples could be represented in the CDA IGs: this allowed us to identify shortcomings in our current CDA IGs and by looking at the HL7 standard and the extended XML schema definitions, it was considered what modifications need to be introduced to solve our current issues. During this analysis and thinking process, other projects like ISO IDMP and UNICOM were kept in mind. As a conclusion, 5 changes to the CDA IGs were identified, that could solve almost all shortcomings in our current CDA IGs and would allow Member States to present their complex medication packages. These suggestions were presented to the eP Cluster, where the analysis was continued and feedback was collected from the Member States. Analysis and feedback from both groups were collected and combined in this change proposal. Final remark is that special attention must be paid to writing explanatory documentation of the elements to be adapted the CDA IGs. It must be clear for implementers how to specify complex medication packages by just reading the provided documentation. 50 Component examples: Client connector, WS server, OpenNCP Portal, epSOSWeb, OpenATNA, TRC-STS, Security Manager, TSL-Sync, TSL-Editor, TSL-Util, Protocol Terminators, TSAM Sync, Stork Plugin, CDA display tool, xslttransformer, tsamexporter, cdautils, epsos-util, configuration manager, epsos-common-components, e-SENS eID richclient, e-SENS eID design-main… 51 Change estimated impact is the estimated order of magnitude of the change: a change will be qualified as major if it introduces for instance a component that already exists or a new component, impacting the architecture; it will be qualified as minor if it improves the existing behaviour without impacting the architecture. UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 66 of 69 DESCRIPTION OF THE REQUESTED CHANGE In total, 5 improvements and fixes were identified that could improve the presentation of the medicinal product packaging: 1. To represent the package structure in more detail, one or multiple (up to 3) optional intermediate layers of asContent element could be defined in the CDA IGs. In order to represent complex medicinal product packages, there is the current limitation that we only have one epsos:asContent element which makes it impossible to represent layering of packages. Therefore we want to follow the approach taken in the HL7 IPS CDA where nested epsos:asContent elements can be provided. The product might have a single (30 pills bottle) or multiple (5 vials 10 ml; box with 2 blisters of 20 tablets) layers of packaging. In the latter case, the most inner (nested) item represents the most outer package item. For example the case \--Box \-----2 blisters \--------20 tablets is described as "20 tablets" contained by "a blister"; "2 blisters" contained by one box. The most inner package represents the Packaged Medicinal Product. When the IDMP Packaged Medicinal Product ID (PCID) will become actually available for usage, the most inner package <code> element will be used to convey the IDMP PCID. Until then a national package identifier can be used. The second improvement will go more in detail on the package identifier. Example of a Packaged Medicinal Product with multiple layers packaging: <asContent> <containerPackagedProduct> <!-- Inner Package --> <code codeSystem="..." code="..." displayName="..."/> <asContent> <containerPackagedProduct> <!-- Intermediate Package --> <asContent> <containerPackagedProduct> <!-- Outer Package / Packaged Medicinal Product --> </containerPackagedProduct> </asContent> </containerPackagedProduct> </asContent> </containerPackagedProduct> </asContent> Impact UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 67 of 69 Since the additional asContent layers are optional, Member States that can provide this information will be able to represent it in the new structure. Member States receiving this information must be able to visualize it in the CDA Display Tool for display, that will need to be adapted. 2. An optional code element (which is available in the schema definitions) could be added to the innermost package element (outermost package) to contain the package identifier. In the future, this could be used to contain the ISO IDMP PCID. In the current version of the CDA IGs, there is the possibility to put the regional/national medicinal product code or MPID compliant with the IDMP system in the hl7:code element inside the hl7:manufacturedMaterial element. It is noted that this element contains often the regional/national medicinal product package identifier. Currently there is no way to define this package identifier. The idea of this improvement is to provide an additional (optional) code element at the outermost package level inside the epsos:asContent structure. Since this element is optional, it does not need to be filled in, but it allows Member States to fill in the correct identifiers at the correct location. Impact Member States need to consider where they put the regional/national medicinal product code and package codes. Also the CDA Display Tool needs to be adapted to display both codes. 3. epsos:capacityQuantity on containerPackagedMedicine level (which is the capacity of the package) is not used according to the CMET specifications, instead epsos:quantity on the asContent level should be used to capture the capacity of the package. In the current version of the eHDSI Material template (https://art-decor.ehdsi.eu/html/publication/epSOS/epsoshtml-20210621T103924/tmp-2.16.840.1.113883.3.1937.777.11.10.143-2020-09-09T141531.html), the epsos:capacityQuantity element is used to contain the package size of a product. This is a wrong interpretation from the past: The capacityQuantity is supposed to represent the functional capacity of the container: e.g., blister containing 20 tablets or a bottle of 1L. But this container could only be filled partially: Maybe a blister with space for 20 tablets, only contains 10 tablets or a 1L bottle is only filled by half. The real package size is supposed to be contained in the epsos:quantity element on the epsos:asContent level. The epsos:quantity element needs to be added as mandatory to the epsos:asContent level to contain the real package size and the epsos:capacityQuantity can be omitted to avoid further misuse. Impact UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 68 of 69 Member States need to provide the package size in the epsos:quantity element and no longer in the epsos:capacityQuantity element. The CDA Display Tool needs to be updated accordingly. 4. There are a lot of situations where a box consists of different parts where each part has its own ingredients or strength. To represent this, the part element can be introduced. Most of the medicinal products can be represented well using the current structure, but for some cases, the package consists of different parts with every part having its own ingredients/strength. This can currently not be represented by the CDA IGs. However, in both the epsos extensions of the CDA schema definitions and the HL7 pharmacy extensions, the epsos:part element is defined which allows to define different parts of the medicinal product. This part element can be added as optional and can be used in the case the medicinal product package consists of different parts, which in turn, possibly may have different active ingredients and strength. In the CMET model below, it can be seen that a product can have one or multiple optional part elements, which in turn contains again partProducts with all the elements available for a medicinal product. Impact Since the part elements are optional, the part elements can only be provided by Member States that are capable of providing this type of information. Like the other items, Member States receiving this information must be able to represent it in their CDA Display Tool. 5. Consider the switch of the epSOS medication CDA extensions to the hl7 pharmacy profile. Background UNICOM – D5.7: Common minimum data set for implementation in the national NCA and eHealth solutions Page 69 of 69 The exchange of clinical documents in the eHDSI project is based on the eHDSI CDA implementation guides normative specifications based on the CDA R2 specifications. For inspiration, the IHE PCC and CCD template definitions where used to define the templates. Since for the electronic prescriptions and patient summaries, specific requirements are needed that could not be fulfilled using the standard CDA R2 XML schema definitions, an extension was created. The epSOS CDA extensions for the medication are handled under the XML namespace identifier urn:epsos-org:ep:medication and typically use the namespace prefix epsos. More recently, the HL7 pharmacy profile is defined, which almost completely matches the epSOS medication profile. The HL7 pharmacy profile uses the XML namespace identifier urn:hl7-org:pharm and typically use the namespace prefix pharm. Motivation Some issues were encountered with the current epsos medication extensions that need to be fixed. Since these problems are already fixed in the HL7 Pharm extensions, it is a good moment to align our specification with existing initiatives. With the move from the epSOS medication profile towards the HL7 pharmacy profile it is not our intention to change the specifications, but just to align better with the different initiatives and standards. The HL7 pharmacy project is already used in the HL7 IPS (International Patient Summary) CDA and can be seen as a joint work item with the UNICOM project and HL7 Europe. Impact • The biggest difference / improvement is the usage of the subordinated SBADM that allows to resolve some inconsistencies with the effectiveTime and have a single template structure independent of the type of administration. • Currently the HL7 pharmacy profile has no support for defining the marketing authorization holder, which is defined in the specifications on the ManufacturedProduct level in the epSOS medication extension. • Namespace and namespace prefix will change. • Some element names will change. Conclusion • In the eHDSI project a switch could be made to the HL7 pharmacy profile with a relative small impact for the Member States, that will solve some issues in the epSOS medication extension. It is always good to adhere to a standard. To avoid an ad hoc solution to write an eHDSI specific extension to support the marketing authorization holder, it could be integrated in the HL7 pharmacy extension. OVERVIEW OF THE EXPECTED OUTCOMES/BENEFITS Current CDA IG definitions can be used to represent the vast majority of the medicinal product package structures. The goal of this change proposal is to fix the remaining cases and to improve the quality of the ePrescription service and the patient care in Europe. Although not all Member States are able to provide the medicinal product packaging structures in the proposed form, there is at least the possibility for Member States that are requesting this feature. Linked with this improvement, it is a good opportunity to consider the switch to the hl7 pharmacy profile in order to adhere to an HL7 standard and fix open issues in the current epSOS medication extensions.