Meeting Minutes 8 March 2011

Notes from RPS R3 WG Teleconference 08 March 2011

1. REDRAWN R3 MODEL

The latest version of the model was distributed just prior to the meeting. Jason pointed out that it has been rearranged, thanks to Joel Finkle, in a significantly more readable form though it does take up more space. Several members stated that it was a great improvement.

2. PROJECT PLANNING

It was agreed that we are going to try to complete all the work necessary to ballot RPS R3 by the middle of May. A list of tasks is to be prepared.

3. EU REQUIREMENTS

Jason reviewed the additions to the model to accommodate the submission of EU grouped-workshare variations. These comprise:

(a) A new submission group class on a pertains to relationship with submission; this uses an id value to join several submissions into a common group. A submission may be part of more than one group.

(b) A new submission reference class on a pertains to relationship with context of use. The default condition is that a context of use instance applies to all submissions (and applications) that pertain to the submission unit; however, when an instance of this submission reference is present it acts to exclude the context from the submission(s) identified by the id value(s) it carries. It may only identify a submission instance (not a reviewable unit or an application instance), and its exclusionary operation is indicated by the negation indicator (set to true) on the pertains to relationship.

In discussion it was determined that there is no US or JP application of this concept. Jason reported that, based on discussions with those familiar with the EU usage, even there 90% of documents would apply to all pertinent submissions.

4. DOCUMENT MODEL REVIEW

Jason gave a brief recap of the document model. The following points were noted in the questions and discussions that follow:

(a) The component(s) of a document are identified by their id carried in a document reference class.

(b) A document instance is subject to an exclusive or condition explained in a note on the model, which restricts instances either to include a text attribute identifying a file or to include one or more component documents.

(c) A simple document instance, one that identifies a file, could be made a component of another document, which would be placed in context, or it could be placed in context itself.

(d) A code attribute is not required on a document instance (either a simple document representing a single file, or a compound document made up of multiple components).

(e) A code would be required to represent the same information that study file tags currently represent; other uses might be permitted by specific implementation communities.

There was a discussion of rules, such as that mentioned in (b) above, which are not enforceable in the XML schema, but can be enforced by Schematron statements. It was noted that the XML Schema in not covered by the HL7 ballot, and it was proposed that ICH might ‘standardize’ the RPS schema and basic Schematron statements.

5. PRODUCT INFORMATION

Jason outlined the product information present in the model and explained that it was a very small subset of CPM (Common Product Model). In response to a concern that the device community had not considered this in detail, Jason noted that it did include the device definition act from CPM.

6. IMPLEMENTATION GUIDE

There was some discussion about specification for the values of various data elements (e.g. 4 digit sequence numbers), and it was recognized that we should be keeping a list of these items for eventual inclusion in an IG. Keith will collect those emailed to him and set up a place to post others on the wiki.

Jason suggested that it would be best if we could ballot an IG for DSTU and asked for volunteers. Marc agreed that it would be good to have one. It was pointed out the DSTU period would produce many changes and that it was not strictly necessary to ballot the IG.

Joe reported that ICH will be working on an overall IG, which individual regulators will flesh out with their own more detailed requirements. ICH would expect to have this in place for DSTU, and plan to use our RPS IG as their starting point.

7. NEXT WEEK

Review storyboards and start documentation review.