Magazine Article | August 12, 2011

Introducing RPS – Taking eCTD To The Next Level

Source: Life Science Leader

By Joel Finkle

By now, regulatory teams and IT departments within pharma companies have grown used to the precise demands of the FDA and equivalent overseas authorities when it comes to submitting dossiers in support of new drug license applications, amendments and updates, and product labeling. Rates for compliance with the current electronic common technical document (eCTD) standard are impressively high in the United States, which leads the way globally in electronic submissions. The eCTD standard dictates how documentation must be published and structured, to make it as easy as possible for the regulators to review. Unsurprisingly, since the standard originated here, the U.S. market was the first to make it mandatory for pharma companies to use the specification for electronic submissions. Other territories are following suit, but adoption rates across Europe, in particular, vary considerably.

Preparing For What Lies Ahead
The new refined version of the standard offers even greater efficiencies to the pharma industry. eCTD in its original form has been around for a long time now. Version 3.0 was issued in October 2002. Since then there have been only minor tweaks, until the arrival of eCTD version 4, that is — the new regulated product submission (RPS) standard, which aims to take eCTD to the next level.

Pharma organizations should not be alarmed by the emergence of what may at first seem to be further hoops to jump through. Particularly where companies are still in the early stages of eCTD adoption, advance awareness of the RPS specification offers an opportunity to refine processes as they go, knowing that the benefits are likely to outweigh any additional work that has to be done.

The emphasis of the new RPS standard is to build on the original goals of eCTD, adding more flexibility and robust capabilities, in recognition that the original eCTD standard has a number of limitations. The eCTD format is limited to human pharmaceuticals, for example. This has created inefficiencies for regulatory authorities such as the FDA. Currently, there are different electronic standards for each division, and not every division even has an electronic standard. The situation is costly for the FDA, which has to allocate staff to manage and maintain each of those systems. A single system covering all of the divisions — comprising food additives, medical devices, human therapeutics, and veterinary medicines — would simplify things considerably.

There are technical limitations, too, involving tagging and the way additional information is supported by eCTD, with differences emerging between different regions in the way that content gets handled, despite the standard having been designed to be international in scope. Similar restrictions apply to the way documents are managed across the lifecycle of a product, as amendments get made and old information is superseded.

The RPS standard has been in development since June 2007. The refined version, RPS Release 2, was released in January 2010. This has undergone extensive testing by all major user groups — sponsors, agencies, and software vendors — to ensure it meets everyone’s needs.

One change expected with the next release is simplification of the way information changes get made at the metadata level. For example, when an ingredient manufacturer changes its name, the sponsor must revise a vast number of documents, and there are metadata associated with each of those documents. In the current eCTD, there is no way to change the metadata associated with documents — you would have to mark each one as deleted, then add a new section to the submission with new metadata. In RPS, the document can just be marked as revised with the new metadata.

Something that emerged from testing of Release 2 is the need for a common interpretation of the way the RPS model has to work, in order to ensure all systems implement the model the same way, and to avoid scenarios where one agency’s review system might accept something that may be rejected by another. The current goal is to approve Release 2 as an ANSI standard late in 2012, with ISO approval sought immediately following.

Closing The Communications Loop
The enhancements offered by RPS makes it easier to expand the eCTD’s capability. This is good news for pharma organizations, creating the ability to handle bundled supplements, to correct attributes, and to cross-reference with previously submitted information. With RPS, a sponsor with a supplement affecting, say, five applications would need to create only one submission.

One of the primary benefits of the RPS is the opportunity for two-way communication, which would enable the regulator to communicate to the applicant by using the same standard in the applicant’s correspondence, preferably through the electronic gateways such as those currently at FDA and being developed at EMA.

For most users, assembling an RPS-based submission will look much the same as the current version of the eCTD. Fears that there will be broad changes in the format or the table of contents or how the submission is structured are unwarranted. While RPS will look different at the back end, regulators still expect exactly the same documents and datasets.

One of the differentiating aspects of the RPS development process is that it is open to everyone — regulators, sponsors, software vendors, and consultants — and that openness has enabled groups from around the world to contribute thoughts and ideas. Ultimately, the goals are maximum flexibility and expandability.

When, later, the RPS format itself undergoes further enhancements, these will require only simple updates to a table of codes rather than major software changes. There will be fewer software cycles and fewer updates will be required to meet regulatory requirements. As a result, companies will be subject to fewer demands on time and personnel, leading to reduced costs.

It is expected the FDA will start accepting RPS messages for drugs and biologics some time late in 2013. There will be a transition period too, during which the agency will accept both the current version of the eCTD and eCTD version 4, or RPS, and no date has been set to require RPS submissions. Other FDA divisions — those without electronic capabilities today — may adopt it sooner.

Taking Early Action
The best advice to life sciences companies today is to make themselves aware of the additional measures covered in the RPS, so that any work they are undertaking currently will help them toward this later goal. A good place to start is to participate in discussions with the standards body, Health Level Seven (HL7), so that organizations are fully up to date with what’s coming, and what this will mean for them in practise.

As with today’s eCTD standard, measures are all to do with the way content is organized, having the right document management system and workflow technology in place, and being able to cross-reference easily between related materials. By making sure they are producing ‘submission-ready’ documentation, which can be converted to PDF files, with hyperlinks between different summaries, full reports and raw data, for example, companies will be moving in the right direction. Preparing for RPS compliance should not create more work; rather it should make life easier still, allowing even more sophisticated content linking, through advanced use of metadata.

Since RPS is ultimately still eCTD in essence, eCTD compliance remains the way to go.

With the help of experts experienced in electronic submissions to guide them, there is no reason why the transition to version 4 further down the line shouldn’t go very smoothly.

Implementation of the RPS will happen, so the sooner that life sciences companies factor this latest development into their process and system plans, the better off they will be come 2013.

About The Author
Joel Finkle is senior strategist, regulatory informatics within CSC’s Regulatory Solutions Group (formerly ISI). In his current role, he is working to find novel ways to solve regulatory software and service processes for customers, as well as providing the focal point for industry standards and regulatory guidance.