RPS Structure and Linking Discussion

Regulated Product Submissions | RPS Structure and Linking

Please use this page for discussion. Do not delete other authors entries, but feel free to comment. When mature, this should become part of the story boards and business requirements. Use the signature --~~~~ to mark your own text.

File and Folder Rules

• File and folder specifications would aid in converting RPS messages into NeES-like submissions --Joelfinkle 22:33, 16 July 2009 (UTC)
• This should be left up to the individual regulators, and is out of scope for the RPS message --Joelfinkle 22:33, 16 July 2009 (UTC)
• I agree that it may not be 'necessary' but I want to be able to use one. I have many purposes for re-use. Agencies have systems that utilise file structires and will not want to have to redevelop their systems and so in Europe I would expect that they will 'want' us to use a folder structure. I thereofre do not want RPS to define that we cannot use a folder structure and if an implementation wants to define a mandatory -or even preferred - structure then it can. --AndrewMarr 11.25, 31 July 2009 (UTC)

Hyperlinking

• Eliminating between-document hyperlinking would eliminate any need to specify file and folder structure --Joelfinkle 22:33, 16 July 2009 (UTC)
• Eliminating between-document hyperlinking would slow down review --Joelfinkle 22:33, 16 July 2009 (UTC)
• Between-submission-unit hyperlinking currently requires that assembly tools "know" how submission units are stored relative to each other. --Joelfinkle 22:33, 16 July 2009 (UTC)
• Most proposed solutions to reroute "broken" or "updated" links would require Acrobat plug-ins or server-side redirectors, which is out of scope for the RPS project -- we can create specifications, but not enforce them. --Joelfinkle 22:33, 16 July 2009 (UTC)
• One alternative would be that the RPS message must include all between-document link information, so that a review system can construct the necessary links. This would remove the need for betweee-document links in the documents themselves, but would still require the review system to have enhancements. --Joelfinkle 22:33, 16 July 2009 (UTC)
• With regards to XML-only content then I suggest you forget it for this release of RPS and any one within the next 10 years. We are just bginning to consider this as a possibility at ICH and I would say that it might be two years minimum before we might even consider having it as an option and I do not believe that it would be made the sole format within 10 years. There are still companies yet to move to PDF. Moving to XML is likely to be more complex. What we are looking for in Europe is to make sure that RPS has a good chance of being implementable and the more 'technical' it gets, the more likely it is that it will be difficult to implement. Technically a vendor solution might be able to support but one of the main issues with putting eCTD out to local affiliates it the level of technical understanding that they need to be able to use it. I'm very afraid that RPS will require more technical understanding and hence be more difficult. Whether you like it or not PDF will be around and will have to be used - so it will need to be fully supported. --AndrewMarr 11.26, 31 July 2009 (UTC)

Example Implementations

Here is an example of a possible way to do link updating using current technology at the implementation level.

• Every hyperlink in a document would generate two elements in the XML backbone message: One at the "source" end, which gives it an ID, and one at the "target" end, which references the ID.
• When a document is replaced, its "source" links may be added to or removed. A link which went to an incorrect document should be removed and a new one added in the backbone.
• When a document is replaced, its "target" links list should indicate which ones it now "attracts."

In other words, if I update a clinical study report, it should say, "I'm still linking to the protocol just fine." and "The link from the ISS to the previous version of this document should now go to me." This should provide sufficient information for a review system to be able to re-route links through web server or Acrobat plug-in technology.

Another plausible solution would be to embed context of use information within the PDF file for every external link. An acrobat plug-in would be able to detect this, and display the various editions of that context of use entry (or rather their files) to which to jump to. --~~