For the first time in two years, EMA (there are enough acronyms here that it got distracting defining them all – see the table at the bottom) has updated their Implementation Guide for eCTD version 4, which is based on the HL7 RPS standard, and has been advanced through ICH Step 4, meaning that it’s OK to implement.
A quick recap: eCTD version 4 solves one of the most painful things about the current eCTD format: every time a new document type or metadata is introduced for inclusion in the table of contents for a dossier for marketing approval, master files, clinical trials, etc., it usually requires new versions of software to support it. This is because the XML DTD has to be updated. The RPS standard was first proposed by FDA to reduce that burden, and to make something generic enough to handle all of FDA’s products, not just drugs and biologics. Marketing applications for medical devices, food additives, in-vitro diagnostics, etc., have very different tables of contents, and would need entirely separate DTDs (I’ve said that if the definition of a product in eCTD 4 were a little more flexible, the FCC could use it for approval of new smartphones and the Pentagon could use it for reviewing aircraft carrier plans).
Although the RPS Release 2 standard was approved in 2014, there hasn’t been a big rush to implement it. Japan has started an initiative to permit an online assembly of submissions in eCTD 4 format, so that companies that cannot afford eCTD publishing software can still use the format. However, they have not announced a schedule for acceptance of the new format. The US nudged their pilot program forward a year – we were expecting it to happen in 2017, but now it looks like we’ll be able to start testing in 2018. Europe has been particularly quiet: after their initial Implementation Guide was released in 2015, there hasn’t been any clue, and that makes some sense given the amount of resources that IDMP is taking.
So I was quite surprised when EMA released a new version of their implementation package on May 22, 2017. There still isn’t a schedule for implementation, but there’s a call for comments… and I have quite a few.
The first is an editorial one: Somehow, EMA’s typesetting algorithms have been infested by weevils. See the image from the first page of content of both versions (ignore the size difference, I clipped them from adjacent monitors, and magnification doesn’t change the problems). But there’s no reason why the kerning should be so awful – and this is far from the worst example. Reviewing 104 pages of this was quite painful.
The most positive changes in the Implementation Guide since the 2015 edition are items that show that EMA are paying attention to other developments and making sure they’re integrating with eCTD. For instance, organization identifiers explicitly reference the IDMP SPOR project and its Organization Management System. OMS identifiers will be used for the applicant (sponsor/market authorisation holder). This directly parallels FDA’s use of the DUNS number in the same spot. Note: EMA isn’t using DUNS numbers because they do not have the authority to require the use of a 3rd-party database.
Similarly, the recent Policy 70 requirement for labeling documents as containing commercial or patient data that must be kept confidential is included in the new Implementation Guide. This will be done with a Confidentiality element on the Document object in eCTD 4.
The guide contains some head-scratchers though, where it appears that the authors – or at least some of them – were not 100% familiar with the RPS standard on which eCTD 4 is based. The biggest problem is related to what’s called the “Primary Information Recipient” which is part of the Context of Use – that’s the XML element which is the table of contents entry that points to the specific document, metadata, and the code for the location in the TOC. The Primary Information Recipient element was designed to permit some documents in a submission, sent to multiple regulators, to be targeted for one particular regulator – the label, for instance. Section 10.1.3 of the guide specifies exactly that. However, section 9.4 says that the Primary Information Recipient should be used to identify the Reference Member State for a Mutual Recognition Procedure or Decentralized Procedure. This is wholly impractical, as this field is specific to each document, not the submission as a whole. Unfortunately, the RPS standard does not seem to include an appropriate field to label the Reference Member State. There is a repeating “Information Recipient” element in the Submission structure – and each member state in the MRP and DCP is listed there (it doesn’t help comprehension when the Recipient is part of the Author structure – but the agency is the author of the review). But there is no classification of the role for each member agency.
The only solution I can suggest for this problem is to use the “Extension” attribute for the ID of each Information Recipient in the Submission structure, to optionally label an agency as the Reference Member. Otherwise, the RPS standard will need revision.
Another misinterpretation of the HL7 standard can be found in the “Submission Reference” element, also on the Context of Use. The Implementation Guide specifies that it is to be used only by the agencies, to indicate the related regulatory activity when they send a response. Again, this is something that should be related on the submission level and not the table of contents level – and that already exists. The agency responses should use the same submission ID values as the sponsor. The Submission Reference element is instead to be used for excluding one or more regulatory activities from a grouped submission. Again, the example in section 10.3.2 may get it right, although it doesn’t use the “negation indicator” that says the content is being excluded from the referenced submission.
There are a few other typos, and small suggested changes, and a couple relating to code lists. FDA does not require a “reason” to reference another application, but EMA does, and requires a reason for references for generic applications, and informed consent. The controlled vocabulary EMA provided only lists items for bioequivalence and the data protection period – both of which are related to generic applications. There are no reason codes for informed consent. The other code list item is related to confidentiality on documents, which Europe requires for Policy 70 as described above. However, they did not provide a vocabulary for that, merely tacking on “PPD” (Protected Personal Data) above the list of standard HL7 confidentiality codes (Low, Moderate, Normal, Restricted…) in an example in the guide.
EMA will accept comments through September 30, 2017. Let’s make sure this becomes a clear, definitive guide for using the next major version of eCTD. As always, please contact us if you have any questions or would like a briefing on how eCTD 4 will impact your processes.
|EMA||European Medicines Agency|
|eCTD||Electronic Common Technical Document, the format for submitting regulatory dossiers with an XML table of contents|
|HL7||Health Level 7, a standards agency accredited by ANSI|
|DTD||Document Type Definition – the predefined structure of an XML file. Mostly superceded by Schema (.xsd) files.|
|RPS||Regulated Product Submission|
|ICH||International Council for Harmonisation|
|FDA||US Food and Drug Administration|
|FCC||US Federal Communications Commission|
|SPOR||Substances, Products, Organizations and Referentials – the Master Data Management environment for IDMP at EMA|
|IDMP||Identification of Medicinal Products… but that’s another show|
|OMS||Organisation Management System, one part of SPOR at EMA|
|DUNS||Data Universal Number System, issued by Dun & Bradstreet|
|MRP||Mutual Recognition Procedure – a means of having a product reviewed by one country and accepted by many in Europe|
|DCP||Decentralised Procedure – A means of submitting a product to a subset of the EU nations for approval|
|RMS||Reference Member State – the primary reviewer in an MRP or DCP|
|PPD||Personal Protected Data – Regulations in EU to limit exposure of personal information in documents|