D3.1 Gap and requirements analysis for IDMP compatible application forms

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 Gap and requirements analysis for IDMP compatible application forms D3.1: Gap and requirements analysis document Version: 1.0 Status: Final draft Dissemination Level1: PU Due date of deliverable: 30.11.2021 Actual submission date: 30.11.2021 Work Package: WP3: IDMP compatible application forms Lead partner for this deliverable: AGES Partner(s) contributing: AEMPS – ES, BfArM – DE, CBG-MEB – NL, HPRA – IE, MPA – SE, NoMA – NO Deliverable type2: R Main author(s): AGES, Noel Diamant AGES, Georg Neuwirther 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 UNICOM – D3.1: Gap and requirements analysis document Page 2 of 29 Revision history Version Date Changes made Author(s) 0.1 13.10.2020 Concept, content overview ND, GN 0.3 4.11.2020 First draft ND 0.4 12.11.2020 Internal review ND, GN 0.5 26.11.2020 Adaptation ND 0.6 7.12.2020 Internal review ND, GN 0.7 19.1.2021 Finalisation ND 0.8 26.01.2021 Finalisation Update GN, ND 0.8.1 01.02.2021 Finalisation Update GN 0.8.2 13.02.2021 Finalisation Update GN 0.9 02.03.2021 Consultation version for review ND, GN 0.9.1 02.02.2021 Minor changes and suggestions (internal review) Pelle Persson, SEMPA 0.9.2 23.03.2021 Integrated comments from UNICOM partners ND, GN 0.9.3 4.05.2021 Integrated comments from EMA DADI and SPOR ND, GN 1.0 30.11.2021 Submitted 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 – D3.1: Gap and requirements analysis document Page 3 of 29 Deliverable abstract This document is the summary of the outcome of deliverable “3.1: Gap and requirements analysis for providing the IDMP compliant application dataset”. This deliverable was created within task “3.1 Perform a GAP-Analysis between the current application datasets and supporting tools and the IDMP standards”. In this task, the WP members evaluated the gaps between the AS-IS “PDF based legacy application forms” and the TO-BE “IDMP compatible web forms”. The outcome considered multiple perspectives: • Data structure • User Interface • Data content • Data authoring process • Functional and non-functional requirements A detailed requirements documentation can be found in the AGES confluence wiki. This deliverable is the input for the following software engineering process, which will deliver the technical implementation in an agile development methodology. Keywords: AGES, ISO IDMP, SPOR, REFACTORING, WEBFORM, eAF, PDF 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 – D3.1: Gap and requirements analysis document Page 4 of 29 TABLE OF CONTENTS Revision history ....................................................................................................................................... 2 Deliverable abstract ................................................................................................................................. 3 Deliverable review ................................................................................................................................... 6 List of abbreviations ................................................................................................................................. 7 1 Executive summary .......................................................................................................................... 9 2 Content of the deliverable .............................................................................................................. 11 2.1 Contents of the deliverable .................................................................................................... 11 2.1.1 Additional information ........................................................................................................ 11 2.2 Authorship and responsibilities .............................................................................................. 11 3 User experience ............................................................................................................................. 12 4 Content of application forms........................................................................................................... 15 4.1 Transformation of content ...................................................................................................... 15 4.1.1 Package ............................................................................................................................. 15 4.1.2 Organisation and Contacts ................................................................................................ 17 4.1.3 Manufacturers .................................................................................................................... 17 4.1.4 Ingredient ........................................................................................................................... 17 4.1.5 Manufactured item and Pharmaceutical product ............................................................... 18 4.2 Transformations in the content backbone ............................................................................. 19 4.3 Possible content extensions derived from additional business cases ................................... 21 4.3.1 Potential extensions .......................................................................................................... 21 4.3.2 Technical approaches to consider extensions .................................................................. 22 4.3.3 Indications .......................................................................................................................... 22 5 Data authoring process .................................................................................................................. 23 5.1 General AS-IS process .......................................................................................................... 23 5.2 General TO-BE process ........................................................................................................ 23 5.2.1 Details Variation Forms AS-IS ........................................................................................... 23 5.2.2 Details Variations Form TO-BE ......................................................................................... 24 5.2.3 Details Initial Marketing Authorisation and Renewal Form TO-BE .................................... 25 5.2.4 Line Extensions ................................................................................................................. 25 5.3 Utilising RIM systems to create application datasets ............................................................ 25 6 Requirements Analysis ................................................................................................................... 26 6.1 Document functional requirements ........................................................................................ 26 6.2 Document Business Rules for Variation form ........................................................................ 27 6.3 Create FHIR Resources ........................................................................................................ 27 6.3.1 Differences between EU IG, FHIR and eAF ...................................................................... 27 6.4 Set up requirements processes ............................................................................................. 28 7 Development .................................................................................................................................. 29 UNICOM – D3.1: Gap and requirements analysis document Page 5 of 29 7.1 Originally planned architecture concept for a PowerApps approach .................................... 29 LIST OF FIGURES Figure 1: eAF PDF OMS selection ........................................................................................................ 13 Figure 2: eAF AS-IS structure of a package.......................................................................................... 16 Figure 3: TO-BE FHIR structure of a package ...................................................................................... 16 Figure 4 IDMP Ingredient represented in FHIR #R5 ............................................................................. 18 Figure 5: Composition comparison eAF / IDMP .................................................................................... 19 Figure 6: Use Case diagram (web form) As an applicant I want to enter procedural information ........ 26 Figure 7: Originally planned PowerApps Architecture ........................................................................... 29 LIST OF TABLES Table 1: MS Word based forms ............................................................................................................. 12 Table 2: PDF based forms..................................................................................................................... 12 Table 3: Web form as data entry ........................................................................................................... 14 Table 4: Comparison FHIR / DES based backbones ............................................................................ 20 UNICOM – D3.1: Gap and requirements analysis document Page 6 of 29 Deliverable review Internal reviewer: UNICOM WP3 partners External reviewer: EMA Answer Comments Type* Answer Comments Type* Is the deliverable in accordance with the Description of Action? ☒ Yes ☐ No ☐ M ☐ m ☐ a ☒ Yes ☐ No ☐ M ☐ m ☐ a the international State of the Art? ☒ Yes ☐ No ☐ M ☐ m ☐ a ☒ Yes ☐ No ☐ M ☐ m ☐ a Is the quality of the deliverable in a status that allows it to be sent to European Commission? ☒ Yes ☐ No ☐ M ☐ m ☐ a ☐ Yes ☒ No ☐ M ☐ m ☐ a that needs improvement of the writing by the originator of the deliverable? ☐ Yes ☒ No ☐ M ☐ m ☐ a ☐ Yes ☒ No ☐ M ☐ m ☐ a that needs further work by the Partners responsible for the deliverable? ☐ Yes ☒ No ☐ M ☐ m ☐ a ☐ Yes ☒ No ☐ M ☐ m ☐ a Is the structure and contents of the deliverable structured, logical and easy to understand? ☒ Yes ☐ No ☐ M ☐ m ☐ a ☒ Yes ☐ No ☐ M ☐ m ☐ a suitable to meet its intended scope? ☒ Yes ☐ No ☐ M ☐ m ☐ a ☒ Yes ☐ No ☐ M ☐ m ☐ a Is in conformance with UNICOM deliverable template? ☒ Yes ☐ No ☐ M ☐ m ☐ a ☒ Yes ☐ No ☐ M ☐ m ☐ a * Type of comments: M = Major comment; m = minor comment; a = advice UNICOM – D3.1: Gap and requirements analysis document Page 7 of 29 List of abbreviations Abbreviation Complete form ADO Azure DevOps AGES Austrian Agency for Food and Health Safety API Application Programming Interface CDM, LDM, PDM Conceptional, Logical, Physcial Datamodel CMDx Coordination Group for Mutual Recognition and Decentralised Procedures (human or vet) DADI Digital Application Dataset Integration DCP Decentralised Procedure DES Data Exchange Standard (eAF PDF) DoA Description of the Action eAF Electronic Application Form EC European Commission eCTD Electronic Common Technical Document ePI Electronic Product Information EMA European Medicines Agency EMRN European Medicines Regulatory Network FHIR Fast Healthcare Interoperability Resources IDMP ISO Standard for the “Identification of Medicinal Products” (also ISO IDMP) IRIS A secure online platform for handling product-related scientific and regulatory procedures with EMA EU IG EMA EU Implementation Guide ISO International Organization for Standardization MAA Marketing Authorisation Application MAH Marketing Authorisation Holder MEA AGES Medicines & Medical Devices business segment (German: Medizinmarktaufsicht) MG Management Group (eAF-MG) MP Medicinal Product MRP Mutual Recognition Procedure UNICOM – D3.1: Gap and requirements analysis document Page 8 of 29 NCA National Competent Authority NtA The EC group “Notice to applicants” OMS Organisation Management Services PDF Portable Document Format (mostly known from Adobe) PHAROS Pharmaceutical Organisation System at AGES PM Project Manager PMS Product Management Services POC Proof of Concept RMS Reference Member State RMS Referentials Management Services SMPC Summary of Product Characteristics SMS Substance Management Services SPOR EMA service delivering quality data management services for substances, products, organisations and referentials (SPOR) to power EU regulatory activities. UX User Experience (Optimising the user Interface, system interaction and general journey) vNeeS veterinary Non eCTD elektronic Submission WP Work package XEVMPD Extended EudraVigilance Medicinal Product Dictionary XML Extensible Markup Language UNICOM – D3.1: Gap and requirements analysis document Page 9 of 29 1 Executive summary Applying for authorisations for medicinal products and managing their life cycles is a regulated process supported by electronic application forms and supporting electronic tools. At the moment neither the structure of application forms nor the PDF based tools for initial authorisations, variations and renewals are supporting IDMP standards. Thus, it is not possible to automate and feed regulatory processes with IDMP compatible data and easily re-use the data in EU-wide eHealth services. The change to move to online IDMP compatible forms was triggered by the regulatory network. This initiative is now also supported by the EU commission via the Horizon 2020 programme. It is an objective of UNICOM WP3 to provide basic work to overcome this current situation by developing IDMP compatible online tools, which are able to provide IDMP compatible application datasets. The rollout of the new tools will be organised by the European Regulatory Medicines Network (EMRN) and is not in-scope of the UNICOM project. In mobilising activity, the project team assessed the optimal approach to delivering the solution, and ensuring that the solution architecture and technology choices provide a future proof solution. This included discussions with EMA information technology representatives to confirm alignment with the EMA technology strategy in order to enable EMA to provide the long-term support arrangement, hosting and maintenance and continued enhancement of the IDMP compatible application forms in a stable network environment. The Agency recommended to utilise the platform “Power Apps” which is already in use at the EMA for other types of applications (e.g. for orphan drugs) in the IRIS system. The platform also provides a reusable integration with SPOR services and EMA’s user management. To evaluate the viability of “Power Apps” as a development platform, a proof of concept (POC) was undertaken by EMA in July which showed first promising results. After the agreement of the UNICOM partners to follow EMAs recommendation to use “PowerApps”, EMA takes over the responsibility of developing the technical implementation of the application forms as part of the DADI project. IDMP standards describe the underlying concepts and semantics, while FHIR is the necessary implementation to exchange IDMP compatible data. The FHIR implementation was also chosen by EMA as a foundation technology to establish data interoperability. For these reasons this document considers IDMP, as well as FHIR topics. This document is the summary of the outcome of deliverable “3.1: Gap and requirements analysis for providing the IDMP compliant application dataset”. This deliverable was created within task “3.1 Perform a GAP-Analysis between the current application datasets and supporting tools and the IDMP standards”. In this task, the WP members evaluated the gaps between the AS-IS “PDF based legacy application forms” and the TO-BE “IDMP compatible Online Tools providing a PDF representation and FHIR message data export”. The outcome of WP3’s work is the basis for the technical implementation in an agile software delivery methodology. The authors followed the approach to group the analysed gaps into five topics: Chapter “User experience” The current application forms are derived from a “paper world”, which was transformed into PDF based forms. There are some improvements being made in the latest versions of the variation form on dynamic data entry, which will be further enhanced. The new web based and IDMP/FHIR structured tool for entering application data will therefore be a significant next transformation. This chapter describes the change of the user experience. Chapter “Content of application forms” This chapter describes gaps related with the data content of application forms. Although the content of the application form will remain mostly the same, there are some structural changes necessary to comply with the IDMP model. These changes encompass mostly in the context of “product name”, UNICOM – D3.1: Gap and requirements analysis document Page 16 of 29 Figure 2: eAF AS-IS structure of a package In contrast, the TO-BE structure in FHIR depicts a scenario where a “packaged product” contains a packaged item that has a type of package and a self-reference to allow for containers in container. In addition, the packaged item contains a reference to a number of manufactured items. This allows for needed hierarchies and linkage of manufactured items and packaged products. Figure 3: TO-BE FHIR structure of a package Furthermore, the IDMP standards clearly define the semantics on how to describe a package data in a more defined way than the current eAF, e.g. rather than text 1. the package size is clearly defined as a number, 2. material is a choice of controlled terms from RMS 3. the manufacturer is linked by a reference identification 4. characteristics/properties have separate fields and don’t need to be all within “description” UNICOM – D3.1: Gap and requirements analysis document Page 17 of 29 4.1.2 Organisation and Contacts Organisations and contacts in the current eAF are used in several sections e.g. to include a person for a manufacturer, MAH, responsible persons for various obligations. The new tool will introduce improvements. The detailed representation of an “Organisation” and its locations” will be described only once preferably based on mandatory selection from OMS. This will avoid administrative effort when entering data. Contact persons will be mainly structured in a “Contact lists and attributed with their role rather than scattered throughout different sections of the form. To enable a list of different types of contacts RMS has created a contact type list and FHIR a section for medicinal product contacts. 4.1.3 Manufacturers The list of fields used to describe a manufacturer will be standardised, so that all types of manufacturers have a similar level of information. The only difference will be that some have a link to another resource in addition e.g.: • substances – substance manufacturer • package – package manufacturer • device –device manufacturer There will no longer be a different section for each manufacturer, but one consolidated section containing all manufacturer described by their details and manufacturing activities (or “Operation” as it is named in FHIR). 4.1.4 Ingredient The concept of “ingredients” is defined by the IDMP standards. The list of ingredients can be compared to “qualitative and quantitative composition” in the current eAF. IDMP standards enable a more specific description of the eAF content: • A more specific strength definition for each ingredient, whereas the current eAF has limitations. • It allows both a “low” and a “high value” to be specified, upper and lower range, as well as a comparator for each value, whereas in the eAF the comparator is used to depict only one of these options. • Enables to specify a reference strength and an active moiety, whereas the eAF allows for either a base strength or an active moiety. • There will now always be a presentation strength and in addition, a concentration strength can be specified as well UNICOM – D3.1: Gap and requirements analysis document Page 18 of 29 Figure 4 IDMP Ingredient represented in FHIR #R5 4.1.5 Manufactured item and Pharmaceutical product Pharmaceutical products are administered to the patient in contrast to the manufactured item, which is the way it is produced and contained in a package. The current application forms are not able to distinguish these two elements (manufactured item and pharmaceutical product) and usually only describe the manufactured item, although the header is called “pharmaceutical product” (see eAF MAA section 2.6). ISO IDMP standards introduce a more detailed concept to distinguish between the “pharmaceutical product” and “manufactured items”. This required split could be considered as additional information in relation to the current NtA form, or as another way of representing current information. In case the product is administered as it is manufactured, the ingredients (see chapter 4.1.1) will be linked and reused and the content is the same as for the manufactured item. In other cases there will be individual compositions defined. What is missing in IDMP standards and the EU IG is a more refined grouping of ingredients into logical parts to depict e.g. capsule core, capsule shell, printing ink as a composition group, as it is used in the eAF today. UNICOM – D3.1: Gap and requirements analysis document Page 19 of 29 Figure 5: Composition comparison eAF / IDMP 4.2 Transformations in the content backbone The content of the eAFs is stored in an electronic data format. This underlying technical structure is formatted in XML with a schema definition that is called “Data Exchange Structure (DES)”. This architecture allows regulators to consume the data content in an automatised way. The full eAF content can be provided to IT systems using a PDF native XML export. Applicants can utilise this technique and input data into the form by populating the XML backbone with data from applicants’ IT systems. The syntax of the XML validates against the DES that is being published by the eAF maintenance group on an EMA website. Both the data format definition DES and the resulting XML export have the disadvantages of containing a lot of PDF specific and unnecessary elements, they do not always reflect the order of fields and have no continuous naming, - or structure convention. To overcome these drawbacks the future tool will be based on a new underlying data structure. The new format will utilise the concept of FHIR resources and resource bundles. The resource definitions are published and documented extensively online on the FHIR website8. The new backbone design follows the decision made by EMA to use FHIR as an exchange standard in the EMRN. FHIR is being used for IDMP and SPOR implementations9 and is therefore the logical consequence for the new application forms’ backbone. 8 See http://build.fhir.org/ (draft version) 9 See SPOR API under https://www.ema.europa.eu/en/documents/regulatory-procedural-guideline/substances-productsorganisations-referentials-spor-spor-api-v2-specification_en.pdf UNICOM – D3.1: Gap and requirements analysis document Page 20 of 29 The next table compares the future FHIR based structure with the legacy DES backbone: FHIR based backbone DES based backbone • International standard supported by a wide community • It is easy to present information in an IDMP compatible structure • FHIR has a resource relational concept which allows for reusing identical information • FHIR is used across business domains • Publicly available FHIR servers for training and testing purposes • FHIR allows for extensions, but they are only known within the specific business domain • New data elements to the standard require time consuming ballots and can be rejected • FHIR foresees key/value pair concepts for attributes and lists, but having different lists for the same field can make automatic data extraction complex • A code able concept or a reference can contain different elements only known at runtime making automatic data extraction complex • Lose coupling of data standard and user interface • FHIR supports validation against publicly known schemas and project specific profiles • • Proprietary standard for application forms, based on PDF specifics • Applicable only in Europe, no community forums to support implementers • Not compatible with IDMP standards • The standard doesn’t support relational concepts10 • The user interface of the application form needs to copy identical data across sections • DES contains duplicate elements because the PDF User interface requires it • No standalone validation methods are available for IT systems, validation is possible within the PDF user interface • DES is only used within regulatory activities within authorisation and lifecycle management of medicinal products Table 4: Comparison FHIR / DES based backbones 10 (e.g. For centralized products, when several products are populated in the form, it is not possible to determine which packages are associated with each product) UNICOM – D3.1: Gap and requirements analysis document Page 21 of 29 4.3 Possible content extensions derived from additional business cases As described above the content of eAFs is defined by legal and regulatory needs under the responsibility of NtA based at the European Commission. Content extensions can only be made with NtA agreements. However, since the new tool is also intended to support additional business cases the challenge is to find a way to both comply with this restriction and to make an extension technically possible. The current business cases are the following: • Initial applications for marketing authorisations • Variations of marketing authorisations • Renewal of marketing authorisations Future potential business cases might extend the current usage of the web forms and underlying data backbone: • Utilise the data content to also populate SPOR PMS, Article 5711. and the Union Product Databases (veterinary domain) The SPOR Taskforce has published a stepwise approach to replace the current XEVMP format by the eAF data backbone12. • Further Post-Marketing data related activities (e.g. availability reporting, MAH transfer,…) Supporting “electronic Product Information ePI” It is out of scope of UNICOM to realise the support for further business case but the fundamental architectural concepts will consider the future needs. The implementation will be organised by separate projects driven by business needs and the EMRN strategy. 4.3.1 Potential extensions The following business cases will trigger extensions of the defined eAF context Potential extensions in the context of Article 57(2) of Regulation (EC) No. 726/2004 EMA plans to replace the XEVMPR format with a FHIR based messaging. Additional data elements for the Art. 57 (2) are necessary compared to the eAF relevant scope like • Indications are currently not in scope of the electronic application forms. At the moment indications are only contained in SMPCs and national texts. They are also part of the Art. 57 database, in accordance with Article 57(2) of Regulation (EC) No. 726/2004. • Marketing authorisation holder's contact email address and telephone number for pharmacovigilance enquiries. Context of the implementation of the Veterinary Medicinal Product Regulation (EU) 2019) Although the veterinary domain is not directly included in the UNICOM project synergies with the human domain were identified and if possible, will be implemented. The veterinary domain will also utilise the new tool with additional data elements. 11 This database is defined by Article 57(2) of Regulation (EU) 726/2004. See also https://www.ema.europa.eu/en/humanregulatory/post-authorisation/data-medicines-iso-idmp-standards/data-submission-authorised-medicines-article-57 12 https://www.ema.europa.eu/en/human-regulatory/research-development/data-medicines-iso-idmp-standards/spor-masterdata/substance-product-data-management-services#eu-idmp-implementation-guide---version-2.0-section UNICOM – D3.1: Gap and requirements analysis document Page 22 of 29 4.3.2 Technical approaches to consider extensions This section describes how extensions are made possible under the condition that the official eAF is conserved in its current format. User experience The user interface will enable the applicant to enter additional data needed for further use cases. These data elements will be marked and special business rules will apply. Technical backbone The technical data structure of the eAF message can evolve in future releases to include additional FHIR resources needed to carry information for other data consumer e.g. PMS or Art.57. eAF representation used for submissions in regulatory submissions The official eAF representation in human readable PDF used for submission in regulatory submissions will only include data content as defined by NtA. 4.3.3 Indications Indications are currently not in scope of the electronic application forms. At the moment indications are only contained in SMPCs and national texts. They are also part of the Art. 57 database, in accordance with Article 57(2) of Regulation (EC) No. 726/2004. EU Implementation Guide v2 Mandatory (at least one language) FHIR R5 Optional eAF content Not available Conclusion: As this is foreseen as a major change it is not part of the first implementation of the new IDMP/FHIRbased application forms. UNICOM – D3.1: Gap and requirements analysis document Page 23 of 29 5 Data authoring process 5.1 General AS-IS process Application forms are currently available for download via the EMAs website13. Applicants have to make sure that the latest versions are used After entering application data into the application form (eAF) the authoring process will be “finalised” by adding a signature scan (picture) into the PDF. The applicant has to include the eAF in the relevant dossier for submission, either inside eCTD module 1.2 (human) or inside the vNeeS dossier (veterinary). The following section describes the AS-IS process and the planned process changes when entering data. 5.2 General TO-BE process In the future scenario all application forms will be replaced by online web forms14. These web forms will only be accessible by a unified application platform provided by EMA. This platform requires personalised user credentials which can be acquired with EMAs identity management system. The underlying registration and access process is harmonised and in line with other existing similar use cases. Once the user is logged in to the application platform, they can select the appropriate application dataset type and create new or continue with existing datasets. The submission of the PDF representation of the finalised dataset within dossiers is the same as the AS-IS process. 5.2.1 Details Variation Forms AS-IS The current variation form is split into four parts: 1. procedural information, 2. basic product masterdata 3. product changes (variation classification and product changes) 4. section about paediatrics and orphan The information given in the “procedural information” section defines the type and classification of the variation and limits the selections that can be made in the “product changes” section. The variation classification defines the scope of the changes and is based on the classification guidance15. The “basic product masterdata” section contains the main attributes of the concerned products of the variation. Key values are used by data importing tools at regulator level to automatically identify products, which are relevant in this variation. Additional attributes are mainly used for plausibility checks, to ensure that the correct products are included in the variation application. The “product changes” section allows for the input of the current product masterdata values and the input of the proposed value of a change (present and proposed concept). These values are free text with one exception. It is possible to select an organisation from SPOR OMS or even add a graphical information. 13 http://esubmission.ema.europa.eu/eaf/index.html 14 The result is a FHIR message. The definition will be published to enable creation by IT systems (e.g. RIM from applicants). 15 https://ec.europa.eu/health/sites/health/files/files/betterreg/pharmacos/classification_guideline_adopted.pdf UNICOM – D3.1: Gap and requirements analysis document Page 24 of 29 In case of groupings, the change is described once and is then relevant for all products mentioned in application form. The last section “about paediatrics and orphan” is only available for type II of IB variations. 5.2.2 Details Variations Form TO-BE In the future the applicant will be guided through the form to: • First, select the concerned products. The section “basic product masterdata” will no longer be asking for manual input of product data, but prompt to select the concerned products from the product management repository, SPOR PMS, and automatically depict its masterdata. There may be restrictions on who can select which product, so the login credentials would be forwarded to the SPOR system, and the product list may be limited accordingly. The selection of the products will also have an impact on the change section. • Second, specify the changes by selecting the variation classification and their respective variation types. This selection of the variation classification will set the context of further steps and will dynamically define relevant product data elements, which have to entered. The selection of the variation classification will limit the number of product fields shown and display only the relevant data input and its context • Third, the system will be able to derive the procedure type, the domain and the grouping/worksharing information based on the selected products and variation classifications • Finally, the user will describe the changes to the products or the marketing authorisation This section will no longer only have free text fields for present and proposed data, but will reuse the official product information from SPOR PMS and display it if it is available. This data will be changeable in a structured format to indicate the proposed value. In summary the following will be implied: • Rather than free text there will be structured data input elements for text, numbers, dates, RMS controlled term list select choices and OMS/SMS/PMS based master data. • As PMS is a system that is being developed stepwise, there will be free text changes in the variation form in the beginning, which will be replaced with explicit data fields once they become available in PMS. • Legacy data from SPOR PMS will show current data in variation forms with all impurities that exist today. If these are not cleaned before utilised in variation process, they could very likely be changed within the variation, changing more information than initially intended. This will be a challenge with variation classifications and fees, but will ultimately clean the legacy data of the Article 57 EMA / MAH database, which is the source for PMS. • There will be separate data input elements per change for each selected product. This is in contrast to having one shared input element for all products per selected variation topic in the current form. Currently the data propagation to each product is done manually at the receiving end, at regulator level. The future process will shift this to the applicant side, minimising errors due to misunderstanding and ensuring that the application form contains all data already propagated correctly. This means that the relationship between the requested data change and the product is already specified during input. For example, changing a package size for two products will show all packages for both products and the applicant will update the relevant content for both products. There may be sections where the change can be propagated automatically but in most cases UNICOM – D3.1: Gap and requirements analysis document Page 25 of 29 the applicant has the duty, but also the ability to indicate the exact location of the change for every product. • A delta view on the data elements subject to change and their present information will be generated for the regulators to indicate what has been updated for which products. • The variation form content can be used to maintain SPOR PMS content with the MAH applicants providing the application dataset and NCAs validating and assessing the submitted content. Starting the variation procedure, products will be selected directly from SPOR PMS and once the application form is validated, this information can be used to update all information systems. This would substantially improve data quality for EMA and the network. • Finally, the time it takes to fill in the form will be substantially decreased due to o Seeing mandatory fields right away with online validation on leaving a field o 3rd party tools like auto complete for forms o A generally leaner structure to enter data o Improved performance to open and manipulate the forms 5.2.3 Details Initial Marketing Authorisation and Renewal Form TO-BE The MAA form today is a rather large PDF form containing several hundred fields. Due to the change in technology to a web frontend, there are some aspects on validation and performance, which will improve the productivity of filling in the form. In the future, the MAA, renewal and the variation forms will share the section describing the medicinal products (basic product masterdata). The future MAA and renewal forms will also benefit from selection from PMS to include reference products 5.2.4 Line Extensions Currently there is no plan to rework the process of line extensions in the first release of the project although we are discussing an improvement to the data authoring process. The suggestion is to split the different types of line extensions into two groups: 1. Line extensions that change an existing product (e.g. adding a route of administration) 2. Line extensions that create a new product (e.g. adding a strength) Ideally the first group what use the variation form to provide the suggested updates to the product and the second group would use the MAA form to specify the details of the new product. 5.3 Utilising RIM systems to create application datasets As some pharmaceutical companies have all the necessary information for an application dataset in their respective IT-systems, the data does not have to be manually drafted in the new web form. Applicants will be able to reuse data from their respective IT-System to create FHIR compatible data. To provide applicants with the means of validating against business rules and creating the human readable PDF representation a tool will be provided that follows the same validation rules as the online webform.