RPS Meeting Notes 08102010

Return to RCRIM main page | Regulated Product Submissions

Date: August 10, 2010

Time: 7:30 AM EST – 8:30 AM EST

HL7 Telecon: 770-657-9270 Participant Passcode: 745896

Two-way communication, included "threaded discussions".

Joel recalled that he had put together some ideas ahead of a Working Group meeting in Phoenix for R2. He will see if he can find them to recirculate.

However, in the discussion that followed, it appears that there is no real business requirement to build this capability at this time. There is still work to be done to get peole to use the eCTD, and there is a view that even "simple" two way communication models will take time to develop and understand. Therefore, it seems unlikely that we can really describe the "threaded discussion" process in sufficient detail, and get agreement as to what this is, to be able to accommodate this in the message.

Decision: Subject to any strong opinion from project team members, the Project Leadership Team will recommend that this requirement be removed from the project scope. The R3 release will only aim to maintain the two-way communication requirements identified in R2, which allow submission units to be associated with a submission and applicaiton for display purposes (i.e more of a means to group the submission units of the submission interaction for display purposes, rather than a more complex threaded relationship of the content within submission units).

Referencing, specifically mentioning content not "owned" by the submitter (Master Files).

With regard to the specific business scenario of Drug Master Files, the discussion highlighted that neither industry nor FDA were looking to build a means to link applications and Master Files, nor were they looking to develop an electronic authorisation to access the Master File from the submission. Gary pointed out that the FDA 356h form includes a field in which the applicant can identify Master Files associated with the NDA and the general agreement was that this would be sufficient and the maximum functionality needed within the message. The proposal is to include a "related-application" or similar metadata attribute of the application that can be used to identify the Master File reference number associated with an NDA. Other uses may be found for a "related-application" field but this would arise from regional requirements. In the end, any description about the use of a "realted-application" field would be on a region by region basis. Almost certainly, the data in this field would be used for simple handling and administyration purposes, any concerns about this information would be resolved by checking the content files of a submission unit (e.g. the 356h, other similar application forms, cover letters, letters of access, etc.) rather than treating this field as the definitive source of information.

Decision:This proposal will be documented and circulated to WG members. The Project Leadership Team will update the Project Plan description at the end of the requirements gathering phase.

A longer discussion took place about the needs for other sorts of referencing, particularly for multi-file "documents".

The question was asked if we are talking about referencing other application, other files, or something in between?

Everyone agreed that the principle of submitting content files only once and being able to point to them from other uses of the content (Contexts of Use, in the R1/R2 model) was a key principle to be upheld.

There seemed to be general agreement that "reuse" of (for example) a complete drug product section for a different strength of the same dosage form would be a tool solution as new Contexts of Use, with appropriate metadata values would need to be created and the lifecycle setup. This is seen as a building tool issue as the user wants to say "allow me to reuse this whole section, but just edit the metadata values", so the tool should handle the creation of the new CoUs and the addition of the appropriate metadata.

The major disagreement is the handling of multi-component documents. The argument is that when we think about the section of a dossier where we place clinical study reports (e.g. Module 5.3.5.1 of the CTD) we visualise a table of contents that just lists study numbers, e.g.:

Module 5.3.5 Reports of Eficacy and Safety Studies

  Module 5.3.5.1 Study Reports of Controlled Clinical Studies Pertinent to the Claimed Indication
     Study ABC123: A report on the use of Wonderpil in the treatment of confusion
     Study XYZ987: A placebo controlled study on the use of Wonderpil in the treatment of confusion

The argument continues that I should be able to manage the use of the study using just the study ID, which needs to be a physical element in the message. The argument continues that this means when I have a section like this in Module 4.2.2 (note the reports are multi component filesets with text and datasets).

Module 4.2.2 Pharmacokinetics

  Module 4.2.2.2 Absorption
     Study ADME123: A report on the absoption, distribution, metabolism and excretion of Wonderpil in rats, mice and dogs
  Module 4.2.2.3 Distribution
     Study ADME123: A report on the absoption, distribution, metabolism and excretion of Wonderpil in rats, mice and dogs
  Module 4.2.2.4 Metabolism
     Study ADME123: A report on the absoption, distribution, metabolism and excretion of Wonderpil in rats, mice and dogs
  Module 4.2.2.5 Excretion
     Study ADME123: A report on the absoption, distribution, metabolism and excretion of Wonderpil in rats, mice and dogs

that the study should be added and used in exactly the same way just by referencing the "study element", again understanding that the content should only be submitted once, but that there are means to point at the content from multiple locations.

The counter argument is that the occasions whe we do not want to use the study in an identical fashion drive the need to manage the content on a use by use basis. For example, Study ABC123 has been managed in an IND application and will now be submitted as part of an NDA. As an applicant I do not want to resubmit the content files that make up Study ABC123 but I also do not want to submit all of the files that were submitted as part of the IND into the NDA (i.e. I do not want to submit Study ABC123 in the NDA in exactly the same way as it was used in the IND). Therefore, the builder tool will give me the option to select StudyABC123 has an entity for ease of copying the CoUs into the NDA structure, but the user can then choose to say"use exactly the same way" or "I willedit this to meet a new need".

The counter argument runs further. There is no need to introduce a new element as the Study ID is a keyword applied to each CoU pointing to content, so this provides a way to identify the links back to the content. Furthermore, bviewing tools could be programmed just to display the Sudy ID and Title to give the "TOC View", but a link then gives the access to the component CoUs. Lastly, this management of a set of CoUs for each use of the study allows the lifecycle to be maintained separately for each use, where this may be necessary. Again, it is felt to be tool issue to manage the lifecycle in an identical fashion for each use.

Note: no one seems very happy that the report structure is managed as an extension of the dossier structure in the RPS R2 controlled vocabulary (i.e. that the file tags are additional "headings" defined in the CTD dossier controlled vocabulary list). There is general agreement that the management of studies should be done separately from the dossier structure, but there is no clear view on how this should be managed (keywords on the CoUs in a submisison unit or a a specific element/construct or some other solution).

Action: RPS R3 will need to review the management of study information. There is general dis-satisfaction with the handling in R2. Significant new proposals are sought for the better management of studies as a modular "entity", either a real XML element or based on metadata of COUs or some other option. Action: Joe Cipollina will send out a link to his description of the business requirements he has placed in the RPS Forum. Joe says that these support the initial argument and the need for a study element. Further discussion will take place through the forum on this issue.

Lifecycle Management issues, including multi application submissions.

The major area for discussion appears to be the multi-application submission (e.g. grouping/workshring variations across multiple MAs in the EU or bulk submissions in the US). The discussion identified that among the major challenges are: i. Managing the different sequences numbering identification for each application within a single RPS submission/submission unit (e.g. the variation is being submitted for Application A and Application B. In Application A this will represent sequence 0012 and Application B it will represent sequence 0025). ii. Another challenge is the association of content witrhin the submission unit to the individual applications. (e.g. in the example above, the variation will contain content that is applicable to both Applications A and B, but might additionally contain content applicable to only Application A and some applicable only Application B) How this will be achieved (new keyword on the CoU to identify the application it is used in?, other options?) needs to be determined iii. Lifecycle management of the RPS submission also needs to be considered as the submission can have a different lifecycle for each application. (e.g. the variation above can be withdrawn from Application B, but still continue to be reviewed for Application A. Or, the variation can be approved for Application A but rejectyed for Application B)

Action: Geoff Williams to circulate some discussion slides used in Europe to illustrate points within the EU Variation regulations.

Submission information and the link to CPM.

Discussion on submission administrative data is progressing through the ICH eCTD subgroup.

With specific reference to the need for a CPM (Common Product Model) CMET, the current view of all participants is that the amount of product information in the message is so limited that a CPM CMET is not required.

Decision: The Project Leadersip team will recommend that no further action be taken to develop a CPM CMET and that the RPS R3 Scope be updated to reflect this change..

Hyperlinking and the "Broken Link" issue.

The ICH eCTD subgroup has agreed to move any further discussion of resolution of the "broken link" issue to their technology review group, SENTRI. The business requirements for this have been defined by ICH and no further discussion is deemed necessary or constructuve.

Action: Circulate to RPS WG the ICH business requirements for Broken Links and close further discussion on this topic.

ICH eCTD NMV Requirements.

The ICH eCTD subgroup is close to finalising the ICH list of requirements. Earlier versions have been brought to the RPS project team and discussed and follow up clarifications provided.

Regional Requirements

Feedback at the most recent RPS R3 Leadership Team showed that the individual regions are all taking actions to define requirements and are aware of the end of October deadline.

ITS1 to ITS2 update

No further action is needed from the RPS WG at this time. The major issue experienced by other HL7 groups was compatibility forwards from ITS1 to ITS2. However, no issue is anticipated for RPS as there are no submissions that have been made and accepted to the R1 or R2 standards.

R2 DSTU Findings

The R2 DSTU team have documented findings as they have developed the test scenarios and will continue to do so during the test message preparation.

AOB

RPS is still not currently planning to organise face to face meetings at the HL7 Working Group Meetings in Cambridge, Mass. If any specific agenda items are brought forward then this will be revisited. A final decision will be made at the RPS R3 Leadership Team Meeting on Tuesday 31st August.