Product RR RPS
Product Brief - Regulated Studies: Regulated Product Submissions (RPS)
- 1 Product Brief - Regulated Studies: Regulated Product Submissions (RPS)
- 2 Product Brief- Regulated Product Submissions (RPS)
- 2.1 Product Name - Regulated Product Submissions (RPS)
- 2.1.1 Topics
- 2.1.2 Standard Category
- 2.1.3 Integration Paradigm
- 2.1.4 Type
- 2.1.5 Releases
- 2.1.6 Summary
- 2.1.7 Description
- 2.1.8 Business Case (Intended Use, Customers)
- 2.1.9 Benefits
- 2.1.10 Implementations/ Case Studies (Actual Users)
- 2.1.11 Resources
- 2.1.12 Relationship to/ Dependencies on, other standards
- 2.1.13 Links to current projects in development
- 2.1 Product Name - Regulated Product Submissions (RPS)
Product Brief- Regulated Product Submissions (RPS)
Product Name - Regulated Product Submissions (RPS)
- Regulated Product Submissions (RPS)
- Health Information Exchange Standards
Normative, ANSI Standard
ANSI/HL7 V3 RPS, R1-2008
The Regulated Product Submissions (RPS) HL7 standard was created in response to the FDA’s PDUFA (Pharmaceutical Drug User Fee Act) and FDAAA (FDA Amendments Act) requirements to streamline processes, permit two-way electronic communication, and reduce dependence on paper. This was proposed to be a standard message which could be used by all FDA divisions, compared with the existing ICH eCTD standard which is only applicable to Drugs and Biologics.
In addition, limitations of the current eCTD standard in terms of handling life cycle of documents, relationships to other applications and submissions, and dealing with changes in metadata and granularity indicated that a major revision was needed to that standard. The desire of ICH in revising eCTD is to use a standard developed by an international standards body. In 2009, ICH indicated that RPS would become the next major version (NMV) of eCTD.
The RPS standard was created by HL7’s Regulated Clinical Research Information Management (RCRIM) WG in response to the FDA’s need, although the first release did not include the facility for two-way communication.
Regulatory agencies are in need of a standardized means of receiving documentation for regulatory activities such as product approval applications, master file submissions, etc. The ICH eCTD standard is not sufficient to task for regulatory activities not substantially similar to the Common Technical Document, making it limited to human drugs and biologics as its XML structure is strictly labeled with the hierarchical headings of the Common Technical Document.
The RPS message provides a structure for Regulatory Agencies to define sets of Context of Use codes. These codes correspond to the headings in which documents would be structured. By using controlled lists instead of explicit XML tags, the RPS standard is significantly more flexible.
RPS adds to the current hierarchy of submissions the eCTD uses, of “Application” and “Sequence.” Instead it has “Dossier” (replacing Application), “Regulatory Activity” (referring to groups of submissions for initial approval, variation, supplement, annual report and so on), and “Submission Unit” (replacing Sequence).
RPS uses unique IDs (in UUID or OID format) to identify the Context of Use items, the files they refer to, and the keywords that differentiate sets of documents (e.g. active substances within a product, studies, indications, etc.). This permits them to be referenced through the entire life cycle of the product or product family, and can be replaced or related to in subsequent messages.
The message includes a status code indicating the state of the regulatory activity (e.g. acceptance, approval, withdrawal, etc.).
- The Purpose of the RPS Message
The purpose of the RPS message is to facilitate communication of documents relating to, and the status of, regulatory activities associated with regulated products, between regulated product sponsor companies and regulatory agencies. It is intended to:
- Provide a structured XML message to serve as an envelope for exchange of documents and changes to those documents’ life cycles and metadata
- Facilitate creation of new electronic submission types for regulated product agencies worldwide
- Meet and exceed the capabilities of the ICH eCTD standard for drugs and biologics
- Permit changes in document granularity, e.g. have a single document replace several previously-submitted documents, or have a granular set of documents replace a previously-submitted document
- Permit changes in document metadata, e.g. change the name of a manufacturer, or change the indication a study is submitted under, without having to delete previously-submitted documents and re-add them to the application
- Permit referencing existing dossiers (and their component documents) by the sponsor or other sponsors, without requiring knowledge of the file storage structure at agencies
The most recent version, Release 1, which received ANSI approval in May 2008 is available for purchase at the HL7 bookstore at www.HL7.org as a part of the current v3 Normative Edition
Business Case (Intended Use, Customers)
Following the development of the standard, the message format will become available to product sponsors that have regulatory activities that are sent to regulatory agencies. Initially, this is expected to be used for companies sending product approval applications, investigational applications, amendments, supplements, master files, annual reports to divisions of the Food and Drug Administration, and will be adopted by other ICH participating countries shortly afterward. The standard is sufficiently flexible to be used for any regulated product by any agency worldwide.
The standard provides a common means of exchange of documentation and status between product sponsors and regulatory agencies, most of which do not currently have standardized electronic formats. For drugs and biologics, the message format provides benefits beyond the current eCTD and NeES standards by permitting two-way communication, multiple recipients, and changes to granularity and metadata.
Implementations/ Case Studies (Actual Users)
US FDA, for Foods and limited use for Drugs
- See more at http://www.hl7.org/implement/training.cfm
Relationship to/ Dependencies on, other standards
- RPS R1 can carry other messages and structured documents (such as SPL), but is not dependant on other standards.