DSTU Technical Q&A

Return to main Regulated Product Submissions Page

Return to main RPS R2 DSTU Technical Team Page

Overview

A number of questions have been raised on the DSTU Forum. The DSTU team met on August 3, 2010 to review the outstanding questions and resolve them in order to move forward with product development and testing. Each forum topic has been updated with the results of the discussion and the questions and discussions are consolidated here.

Approval Status

Question

Is there a list of the status codes for the Approval object? We've got status codes for Submission, Contact... but not Approval. Are we just using the HL7 statuses of aborted, active, cancelled, held, new, normal, obsolete, and suspended?

Answer - 3-Aug-2010

The Controlled Vocabulary team has not provided values for the Approval element’s status code, because the FDA does not intend to use the Approval element. The Submission element will include the approval information, and status codes have been defined for the submission element in the controlled vocabulary. It is believed that the approval element will be used in the EU since that allows for differentiation by country. This varied approach to agencies including approval status could introduce additional complexity in the development of message creation and consumption tools. The approach for each region will need to be explicitly documented in order to prevent misinterpretation of messages between tools. This topic should be further explored by the R3 team to determine if a harmonized approach can be developed. For the purposes of the DSTU testing, status will be captured in the Submission element’s statusCode attribute using the values defined in the controlled vocabulary.

Administrative Information – Product Name

Question

The DSTU controlled vocabulary (and US & EU M1 eCTD specs) includes information to differentiate the product name as proprietary, established, code, chemical, (or in the EU inn, invented-name). Is this application-level product information included as a general keyword the same way the CoU keywords are defined or is there another location for this product information?

Given that an individual submissionUnit may not include Drug Product information; there is no guarantee of reference by a CoU to the product keyword in every submissionUnit. The model implies this type of information belongs elsewhere, since keywords are specifically used to further elaborate CoU's: in its definition of the keywordDefinition, "A keyword definition contains name value pairs that are used within the context of an application. Each keyword is an item of information that provides context for the document(s) in a context of use. Keywords are used only to further define the context of a ContextOfUse, and the Keywords, by themselves, have no intrinsic value." Can the appropriate location in the RPS XML be defined?

Answer - 3-Aug-2010

In the original model, this information was to be captured in the Submission/Subject/Approval/Subject/CMET element. However, the Approval element may not be used in all situations. Applications such as DMFs and INDs do not receive approval; therefore the Approval element is not applicable. A place to include general product name information and other administrative-level information, such as what is currently captured in the administrative/envelope elements in regional XML for eCTD submissions, is needed. This should be reviewed by the R3 team to determine if an update to the model is necessary to capture this information within the Application or Submission Element, independent of the approval element since this information is for ease of reference only, and not the specific subject of approval. For the purposes of DSTU testing, vendors can choose to either omit this high-level product information, or include it in the Approval/Subject/CMET element. The approach taken should be documented when providing sample messages so the approaches can be compared.

Correcting ContextofUse Code

Question

During the technical team meeting, we discussed the ability to change the section under which a contextOfUse is associated. In the technical walkthrough, there was discussion, but no resolution on the appropriate to do this; for example, if a contextOfUse was accidentally submitted with code="RPS-2-3-s" but should have been "RPS-2-3-p". There was disagreement as to whether the same id root value can be used in the new submission unit, or if that violates the overall uniqueness constraint. Can the proper way to perform this operation be provided and incorporated into the implementation guide? … How do we lifecycle and track changes to the metadata?

Answer - 3-Aug-2010

The intended implementation allows re-use of the same ID with the new ContextofUse code. The SubmissionUnit/PertainsTo sequenceNumber attribute is incremented with each submissionUnit, so consumption tools would identify the latest submissionUnit by the sequenceNumber value and display the contextofUse related to that latest submissionUnit. In this approach, the value of the sequenceNumber attribute is not, necessarily unique, and can be duplicated for submissionUnits within an application that are submitted at the same time, or as a result of 2-way messaging. This approach will require consumption tools to have awareness of this type of situation and in a current view display only that contextOfUse related to the latest submissionUnit according to the sequenceNumber attribute. However, the definition of the sequelTo element’s typeCode attribute includes the value ‘UPDT' (update) that could be used to explicitly update the value with a new contextOfUse ID that points to the incorrect value via the relatedContextofUse. This alternative would allow for tracking the change as a lifecycle update and may be worth evaluating prior to implementation.

ClassCode and TypeCode Attributes

Question

Many of the elements in the RPS message include the HL7 classCode and/or typeCode attributes. Depending on the specific usage, the allowable value lists for these attributes vary. The model shows the root generalized values (e.g. ActClassRoot, root="ACT"). In many cases the class definition/relationships and the schema also show the specialized values associated with these general values which could also be used to generate valid XML, however many seem outside the scope of an RPS message.

The sequelTo typeCode will definitely need to use the specialized terms (primary reference=SEQL, generalizes: APND, RPLC, REV, UPDT, etc.) to indicate lifecycle. Can any other locations/elements where the specialized value(s) and not the value shown in the model be defined?

Answer - 3-Aug-2010

The SequelTo typeCode is the only attribute that will use the more specific values defined. All other instances of typeCode, classCode, moodCode and determinerCode will be updated from the <= syntax to just equals and use the generalized values depicted in the model.

Referencing Multiple Applications

Question

The forum included an extended discussion on the proper method to indicate submissionUnit pertains o multiple applications and whether the pertainsTo/applicationReference is the proper method to indicate this information.

Answer - 3-Aug-2010

The applicationReference is not the place to indicate a submissionUnit is relevant to multiple applications. Instead, the pertainsTo/application hierarchy is repeated within the XML. The referenced component/file elements are included under the first application element and considered global. They are not repeated under the subsequent application elements. These subsequent application elements include their appropriate ID and code child elements, but no component/file elements.