This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Difference between revisions of "RPS R3 Project Scope Statement"

From HL7Wiki
Jump to navigation Jump to search
(New page: ==Project Scope Statement Document== The following documents are the working versions of the RPS R3 Project Scope statement: ==Project Scope (section 4 - version 0.9 - January 4, 2010...)
 
 
(5 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Project Scope Statement Document==
+
[[Category:RCRIM]]
 +
Return to [[Regulated Clinical Research Information Management|RCRIM]] main page | [[Regulated Product Submissions]]
 +
 
 +
=Project Scope Statement Document=
  
 
The following documents are the working versions of the RPS R3 Project Scope statement:
 
The following documents are the working versions of the RPS R3 Project Scope statement:
  
 +
http://gforge.hl7.org/gf/download/docmanfileversion/5403/6784/HL7ProjectScopeStatementRPSR3v0-92.doc
  
 
+
==Project Scope (section 4 - version 0.9 - January 5, 2010)==
 
 
==Project Scope (section 4 - version 0.9 - January 4, 2010)==
 
  
 
The RPS R3 project scopes builds on the scope defined in RPS R1 and RPS R2.  RPS R2 incorporated medical device and international requirements, but the focus was on the United States Food and Drug Administration (US FDA) requirements to meet Prescription Drug User Fee Act (PDUFA) IV electronic submission commitments. RPS R3 expands on the R2 requirements and aims to complete the definition of the message standard to support the following global regulatory product submissions* activities:
 
The RPS R3 project scopes builds on the scope defined in RPS R1 and RPS R2.  RPS R2 incorporated medical device and international requirements, but the focus was on the United States Food and Drug Administration (US FDA) requirements to meet Prescription Drug User Fee Act (PDUFA) IV electronic submission commitments. RPS R3 expands on the R2 requirements and aims to complete the definition of the message standard to support the following global regulatory product submissions* activities:
Two-way communications (including interagency (multi-regulator) communications, and expansion of current two-way communication activities) – This includes “threaded discussions”, dividing and tracking regulator information requests and the responses into individual items.  
+
* Two-way communications (including interagency (multi-regulator) communications, and expansion of current two-way communication activities) – This includes “threaded discussions”, dividing and tracking regulator information requests and the responses into individual items.  
Referencing (e.g., application to application, submission to submission, etc.) – This will include requirements for referencing applications/submissions not “owned” by the submitter (e.g. Master Files).
+
* Referencing (e.g., application to application, submission to submission, etc.) – This will include requirements for referencing applications/submissions not “owned” by the submitter (e.g. Master Files).
Lifecycle management
+
* Lifecycle management, including the complex relationships of documents in European regulatory processes (management of the Mutual Recognition Procedure and the new Variation regulation that allows single submission units to be submitted that contain changes for multiple products) and other requirements brought forward by stakeholders.
Additional information about the submission (e.g., product, sender/recipient, document/element/leaf metadata)
+
* Additional information about the submission (e.g., product, sender/recipient, document/element/leaf metadata), building on the R2 set by aiming to achieve an aligned information set that can be used on an international basis.  This will include a review of the Common Product Model elements that might be used in an RPS message.
Hyperlinking (i.e., Broken Link) – This includes management of document links within and across documents and/or submission units.
+
Hyperlinking issues that have been identified. This includes the issue that has arisen from eCTD experience known as the “Broken Link” issue but is really associated with the fact that active links between documents exist even after the target document has been updated.  It is acknowledged that this issue may not be resolved by a purely technical solution within the RPS message but be an artefact of the use of PDF files within the message.  However, the intent is to provide a better resolution to this issue through technical and/or process means that can be implemented on a global basis.  Other linking or information relation requirements may also be identified.
  
* Currently, the product submission areas included in the scope are conventional and biological human pharmaceutical products, medical devices and veterinary medicines.  Additional product areas may be included with appropriate participation in requirements gathering and development by representatives from those product areas.
+
(*) Currently, the product submission areas included in the scope are conventional and biological human pharmaceutical products, medical devices and veterinary medicines.  Additional product areas may be included with appropriate participation in requirements gathering and development by representatives from those product areas.
  
 
Specifically for this project, the scope will include the full definition and inclusion of the international requirements brought forward by the ICH as part of the development of the eCTD Next Major Version for submissions in the human pharmaceuticals area.  The project will also include updates and requirements from other stakeholders in the healthcare community, as notified to the project.
 
Specifically for this project, the scope will include the full definition and inclusion of the international requirements brought forward by the ICH as part of the development of the eCTD Next Major Version for submissions in the human pharmaceuticals area.  The project will also include updates and requirements from other stakeholders in the healthcare community, as notified to the project.
  
 
It is noted that by including the global requirements, there will necessarily be some fairly diverse regional requirements brought forward that must be consolidated within the overall scope of the standard developed.
 
It is noted that by including the global requirements, there will necessarily be some fairly diverse regional requirements brought forward that must be consolidated within the overall scope of the standard developed.
 +
 +
The RPS R3 Domain Analysis Model will also be balloted as part of the DSTU package for compliance with the BRIDG v3.

Latest revision as of 17:36, 5 January 2010

Return to RCRIM main page | Regulated Product Submissions

Project Scope Statement Document

The following documents are the working versions of the RPS R3 Project Scope statement:

http://gforge.hl7.org/gf/download/docmanfileversion/5403/6784/HL7ProjectScopeStatementRPSR3v0-92.doc

Project Scope (section 4 - version 0.9 - January 5, 2010)

The RPS R3 project scopes builds on the scope defined in RPS R1 and RPS R2. RPS R2 incorporated medical device and international requirements, but the focus was on the United States Food and Drug Administration (US FDA) requirements to meet Prescription Drug User Fee Act (PDUFA) IV electronic submission commitments. RPS R3 expands on the R2 requirements and aims to complete the definition of the message standard to support the following global regulatory product submissions* activities:

  • Two-way communications (including interagency (multi-regulator) communications, and expansion of current two-way communication activities) – This includes “threaded discussions”, dividing and tracking regulator information requests and the responses into individual items.
  • Referencing (e.g., application to application, submission to submission, etc.) – This will include requirements for referencing applications/submissions not “owned” by the submitter (e.g. Master Files).
  • Lifecycle management, including the complex relationships of documents in European regulatory processes (management of the Mutual Recognition Procedure and the new Variation regulation that allows single submission units to be submitted that contain changes for multiple products) and other requirements brought forward by stakeholders.
  • Additional information about the submission (e.g., product, sender/recipient, document/element/leaf metadata), building on the R2 set by aiming to achieve an aligned information set that can be used on an international basis. This will include a review of the Common Product Model elements that might be used in an RPS message.
  • Hyperlinking issues that have been identified. This includes the issue that has arisen from eCTD experience known as the “Broken Link” issue but is really associated with the fact that active links between documents exist even after the target document has been updated. It is acknowledged that this issue may not be resolved by a purely technical solution within the RPS message but be an artefact of the use of PDF files within the message. However, the intent is to provide a better resolution to this issue through technical and/or process means that can be implemented on a global basis. Other linking or information relation requirements may also be identified.

(*) Currently, the product submission areas included in the scope are conventional and biological human pharmaceutical products, medical devices and veterinary medicines. Additional product areas may be included with appropriate participation in requirements gathering and development by representatives from those product areas.

Specifically for this project, the scope will include the full definition and inclusion of the international requirements brought forward by the ICH as part of the development of the eCTD Next Major Version for submissions in the human pharmaceuticals area. The project will also include updates and requirements from other stakeholders in the healthcare community, as notified to the project.

It is noted that by including the global requirements, there will necessarily be some fairly diverse regional requirements brought forward that must be consolidated within the overall scope of the standard developed.

The RPS R3 Domain Analysis Model will also be balloted as part of the DSTU package for compliance with the BRIDG v3.