Magazine Article | October 1, 2009

When Will RPS Get Here, And What Will It Bring?

Source: Life Science Leader

By Joel Finkle

Just as regulators and life sciences companies worldwide are coming to grips with electronic common technical document (eCTD) tools, formats, and requirements, the standards group Health Level 7 (HL7) and the FDA are taking the submission process to yet another level by developing a new standard called Regulated Product Submissions (RPS).

This new standard for communicating between regulated product manufacturers and regulatory agencies seeks to solve a number of existing problems with electronic submissions for drug manufacturers and will enable other regulated product types, such as food additives, medical devices, cosmetics, and combination therapies, to enter the electronic submission age. But while the new standard will benefit the FDA by allowing reviewers to use a single review tool across all divisions, drug makers may be wondering what benefits RPS will hold for them and how the new standard might impact their current investment in eCTD transition.

With RPS Progress Come Concerns
Looking for a way to bring all regulated product review standards into the electronic age, the FDA asked HL7 to create a new message standard that would enable reviewers to use a single format across all divisions, including food additives, medical devices, human therapeutics, and veterinary medicines. In May 2005, HL7 began work on this new standard, called RPS, with the goal of providing a generalized structure that would be adopted worldwide and lead to the more efficient processing and review of all types of regulatory submissions. But while this new standard holds notable advantages for regulators and product manufacturers, RPS transition will be a measured process likely to take years to complete.

In late September 2009, RPS took another step forward as HL7 held its 23rd Annual Plenary and Working Group Meeting in Atlanta, where much of the discussion was focused around the process of making RPS the next key eCTD upgrade. Participants reviewed nearly 200 requirements from the International Conference on Harmonisation (ICH) that will facilitate the move for RPS to become the next major version of eCTD within five years. The meeting also set the scope for the third (and likely last) development cycle of RPS Release 2, which is scheduled to complete testing early next year.

One concern of life science executives, however, is how this new standard might impact their investment in eCTD conversion. Also, industry insiders worry the push for a new standard at this time might slow down the adoption of eCTD, as companies already slow to make the move might take a wait-and-see attitude as RPS looms on the horizon. However, RPS does address some of the gaps in the current eCTD model without changing the content of eCTD submissions. Experts say vendors will do most of the work in software development, and end users will likely be able to convert submission packages with a simple mouse click on an “RPS” check box. In any event, implementation is not coming any time soon as the FDA has yet to release the guidance documentation that will allow vendors to start building RPS solutions.

How It All Started
The life sciences industry is in the midst of its third major upheaval in the process of submitting new drug approvals. In the early 1990s, companies would bend over backwards for a reviewer to create custom computer-assisted new drug applications (CANDAs). These could range from a laptop full of documents converted to the reviewer’s word processing application, to client-server workstations with data visualization tools. This was an unmaintainable environment, however, requiring the FDA to support random equipment and sometimes forcing drug sponsors into a “shiny toy” arms race. The primary outcome of this period was a better understanding by agencies of the tools and environments needed for electronic review.

The second wave came with the advent of Adobe PDF as a de facto standard for electronic documents. The FDA was the first to issue guidance permitting waiver requests to eliminate paper case report form and patient tabulation submission sections, which are the largest and least-read portions of a submission, in favor of PDF versions. In 1999, this was expanded to permit the entire submission to be in PDF form (with the exception of signed forms), using hyperlinked tables of contents to navigate between documents. This was heartily adopted and has resulted in significant improvements in review times. The move also was accompanied by hefty user fees to upgrade the FDA computing infrastructure and supplement review staff.

The current electronic submission format wave is the eCTD. Approved in 2003 by the ICH, the eCTD replaces the PDF tables of content with an XML (extensible markup language)-based backbone file that identifies all of the documents in the submission by their document category, making it possible, among other things, to search for and reuse content across submissions and applications. It also includes life cycle information that indicates that a previously submitted file has been replaced, appended, or is removed from the submission. The eCTD currently is the required electronic format at the FDA and is gaining traction elsewhere as the EU has mandated all centralized procedure applications in the eCTD format by the start of 2010, and other regions are beginning to require regionalized versions.

The current standards, though, are not sufficient for all needs. The life cycle attributes mentioned above are very coarse: They cannot indicate the difference between deleting an appended document and deleting the original version, and they cannot replace one file with several or several with one. A bigger factor for regulators, though, is that the eCTD standard cannot accommodate regulated products outside of human drugs and biologics. This is because the eCTD standard has “hard-coded” labels for each section of the common technical document and no place to put anything else — much like buying a spice rack with preprinted labels and having no place to put the cardamom.

Why RPS?
The goal of the RPS message is to facilitate the processing and review of submissions across all FDA divisions. Several of these divisions have existing standards for product submission similar to the 1999 FDA guidance, and the Center for Devices and Radiological Health has an eCTD-like submission format for in vitro testing devices. Although the general requirements of all regulated products are the same, each of these formats requires its own review system and must be processed separately by the FDA electronic document room. From the FDA’s viewpoint, a single submission standard has a huge value in cutting down the number of systems they must support, the number of training systems required, and the number of staff needed to support such environments. A hope of the regulated industries is that standardization would reduce — or at least reduce the increases in — user fees.

On June 1, 2007, the RPS team of HL7 approved Release 1 of the RPS standard. It’s quite a different animal from the eCTD; rather than the “prelabeled” approach of the eCTD, where there is an XML element for every possible location for drug and biologic product approval documents, RPS uses a single element named “Context Of Use,” which offers nearly 2,000 tags to identify the type of document, from “cover letters” to “literature references” — and that’s just for drugs and biologics. This enables the RPS message format to serve as a wrapper for any kind of submission, so long as the sender and receiver have an agreement on what context of use codes are to be used. To date, there are experimental codes for drug, biologic, and device submissions, but none of them have been issued as official guidance by the FDA. The context of use also can point at keywords defined by the submission, so that a single RPS message can encompass the concepts of the eCTD study tagging file by referring to study numbers, animal species, drug substances, and other areas where duplicate sections appear in the eCTD.

Increased flexibility is just one advantage RPS has over the eCTD. Another important benefit is the identification of a “submission unit,” which is one bolus of files sent to an agency (or sent back — RPS can be used for two-way communication). In the eCTD, a submission sequence number starting a new supplement is not distinguishable from an informational amendment or update in manufacturing. Without eliminating the existing concept of a submission sequence number, the submission unit data in an RPS message makes it clear that a submission sequence belongs to a particular submission type, such as a labeling change or additional indication, which in turn belongs to the application (such as an IND [investigational new drug], NDA [new drug application], or BLA [biologic license application] annual report).

The third major advantage of RPS over the eCTD is the manner in which document life cycles can be represented. One of the annoyances of the eCTD is that if a set of documents is submitted in one location, say Rheumatoid Arthritis, and needs to be moved to Osteoarthritis because it was misfiled, every such document needs to be marked as deleted, and also re-added to the submission. In RPS, this is accomplished by simply indicating that the context of use for a file has changed. Because a context of use covers a set of files, a granular, multifile report can replace a report that was previously sent as a single file. Similarly, a change of manufacture of an excipient that uses fewer processes can specify that a set of four files replaces a previous set of eight.

To enable this, RPS uses unique IDs for every file, for every context of use, and for the submission and application themselves. This enables product sponsors to refer to files in previous submissions as well as to files in other applications. For instance, an NDA should be able to refer to the IND application as well as the marketing application for each component in a combination therapy. Current submission formats require knowledge of how the agency stores documents in order to refer to the files themselves, rather than the identifiers of those files (note that this does not address the issue of hyperlinking between such applications, only the identification of files as amended, deleted, or replaced).

When Will Change Come?
As discussed above, the biggest benefit to RPS adoption is for the FDA — if their processes can be standardized, training and maintenance costs reduced, and the costs of new systems amortized over several divisions, tax dollars and user fees will be better spent on reviewers and enforcement. The FDA’s initial priorities for implementing RPS target food additives and combination therapy products, but it is unknown whether there is a budget in those centers. The agency’s objective is to have a system available for all centers by late 2011 or early 2012, but they are unlikely to require the use of RPS for at least a year after that point.

The bigger issue, though, is the cost to product manufacturers. Drug and biologic manufacturers saw improved approval times with the move from paper to electronic submissions, but there is not much expectation of this kind of cost savings with a switch to a new electronic format. At the same time, it has been only in the last couple of years that those same companies have invested in processes and systems to handle the eCTD.

RPS Release 2
In May 2008, HL7 began the RPS Release 2 project which, in part, took steps toward making RPS the next major eCTD version upgrade. Though change is taking place at a deliberate pace, the project team currently is taking a methodical approach to RPS development to ensure that obstacles are identified and needs met at each development step so that problems do not pile up during the implementation phase.

Initial testing has been completed, and second phase testing has started this summer. Changes made thus far include:

  • more descriptive information about the submission in the XML backbone
  • multiple products per submission (critical for medical devices)
  • multiple submission recipients (critical for European agencies)
  • exchange of data in more directions: agency to sponsor, sponsor to sponsor, agency to agency.

The third phase began requirement development in August 2009 and will be looking to support drug and active substance master file management, backwards compatibility issues with existing review systems, and solving the problem of hyperlinks pointing to outdated documents.

Looking Forward
Submission standards in the life sciences industry have made significant progress in the last 15 years, bringing benefits for industry as well as regulators, but the evolution is by no means complete. While RPS has enormous potential to improve the FDA’s processing of electronic submissions across all divisions, without international support, and without a clear migration path for drug and biologics sponsors, it will get very slow adoption in the biopharmaceutical industry. And because many life sciences companies are just now making the transition to eCTD, the industry isn’t likely to embrace the more complex format of the RPS model unless mandated — something that is unlikely to happen for several years yet.

However, RPS is coming, and within the next five years, sponsors submitting to the FDA and elsewhere will be forced to begin the migration toward the next evolution in electronic submission standards. The good news for life sciences companies is that RPS will upgrade eCTD capabilities by expanding functionality and improving communication, and the vendors will take care of most of the transition by upgrading existing submission building tools. The good news for other regulated product manufacturers currently unable to leverage eCTD capabilities is that RPS will open the door for them to finally enter the electronic submission age.


About The Author
Joel Finkle is the director of regulatory informatics at life sciences consulting/software firm ISI. He is also author of An Introduction to RPS: Regulated Product Submissions. He will be speaking at the Drug Information Association conferences in San Diego on Nov. 18-19 and in Vienna, Austria on Dec. 3-4.