The eCTD summit

Recently, I was providing some training to a GlobalSubmit client and one of the participants asked me about an xml document that was present in a folder along with the sample eCTD that we use for training.  The document was called “porp.xml”.  I explained that GlobalSubmit’s VALIDATE product can transform eCTD into RPS and when it does, it produces the XML backbone used for RPS, which is called porp.xml.  This is a single xml document that replaces eCTD’s index.xml, regional xml, and study tagging files.

The next question was “Why in the world is it called porp?”  I couldn’t answer that one.  But recently, I attended several training classes held by the font of all RPS knowledge, GlobalSubmit’s CTO Jason Rock.  I took advantage of that opportunity to gain insight into what is different about RPS xml when compared to eCTD xml.  [For the record, it’s called porp.xml because it had to be different than eCTD – and porp is a combination of po, the business domain within HL7, and rp for regulated product.]

But on to bigger topics.  I, along with most other remotely technical people who have dabbled in eCTD for years, am pretty comfortable with eCTD xml.  I can create the xml for a sequence by hand, and I can look at a sponsor’s xml and figure out what it represents and what is wrong with it.  But when I look at the xml for RPS, all bets are off.  Jason walked us through the xml in our training class and here are some of the observations that I made:

• With RPS, any pretense of representing the xml as “human readable” is over.  New code systems and levels of indirection make this almost impossible.
• The table of contents is not readily apparent.  It’s created by combining a content code and keywords to determine placement within the TOC or tree.  For example, the location of a drug substance specification would be determined by a code representing its document type and then several keywords representing substance name and possibly manufacturer - not by nesting the document within a TOC section.
• Everything is referenced by ID.  For example, a Context of Use (sort of the replacement for a leaf) contains references to the ID of a content file, as well as any keywords necessary, such as a code representing a specific route of administration or species.  Instead of just looking at something like a study ID, you see a code representing the study ID which you must then locate.
• IDs themselves are more complex.  With RPS, IDs must be either an OID or a GUID.  An OID is formed by taking a unique numeric string (e.g. 1.3.5.7.9.24.68) and adding additional digits in a unique fashion (e.g. 1.3.5.7.9.24.68.1, 1.3.5.7.9.24.68.2, 1.3.5.7.9.24.68.1.1, etc.).   A GUID is a 32 character hexadecimal character string, such as {21EC2020-3AEA-1069-A2DD-08002B30309D}.  Either way, they are much less easy to identify visually that the simpler IDs used by most of today’s eCTD publishing tools.
• Many new concepts are introduces such as “Sets” (the equivalent of version trees in a document management system), explicit ordering of elements (a concept not present in eCTD, although many people assume it is), and status (active vs. obsolete, applies to keywords as well as documents).

The bottom line is that RPS XML is only for the brave.  Most of those intrepid souls creating XML by hand for eCTD will have to give up that practice, and everyone will need to ensure that they have a publishing vendor who is highly knowledgeable concerning the standard and who is able to produce very high quality software.

For those of you who would like to see what RPS xml looks like, check out Example RPS Code:  BLA Multiple Sequence along with other Informational Documents (i.e. Plans, Rosters, RPS Technical Walkthrough, Implementation Guide, etc. on the RPS wiki.  

Our posting this time is from Jason Rock, GlobalSubmit CTO and Chair of the HL7 RPS Specification Development Group.

The Draft Standard for Trial Use (DSTU) ballot of the Regulated Product Submission Release 2 standard barely passed ballot on Monday January 11^th. The ballot passed by two votes with a result of 53 affirmative and 33 negative.

Even though the ballot passed, the process is not over. Every comment must be evaluated. This process can take months. Most projects try to resolve comments to the satisfaction of the commenter, but this is not a requirement.

One of my responsibilities as Chair of the HL7 Specification Development Group is to manage the ballot process. In that role, I have already compiled all of the comments. There are over 180 comments in total. Each comment has a proposed resolution. Nearly 150 of the comments were accepted or accepted with minor alteration. It is the last 30 comments that will be most difficult to resolve. I believe that the comment evaluation should run smoothly though, and not hold up the process.

Of the 150 comments that were accepted, some were related to words that addressed two-way communication which is not supported at this time. These words were originally added for release one, but will now be removed. The vast majority of comments were updates to text, either in relation to correcting typos or offering suggestions to help make the text more clear.

I expect that the ballot will be altered with the text changes, but that the model will not change. I also expect the FDA to start testing at the beginning of the third quarter, 2010.

The RPS (Regulated Product Submissions) Working Group met last week in Atlanta.  The main discussion points were around ICH requirements, multi product submission, facility submissions, linking to other applications, multi regulator submission and how should the project be managed going forward.

All current ICH requirements were reviewed. Most of the requirements are already met. Some more requirements need to be addressed.

I expect both Europe and Japan, in regards to human pharmaceutics, to submit new requirements in the next 3-6 months either through ICH or directly. I would not expect these requirements to be ground breaking.

Device attendance was lower than I hoped; but they were present. To gather more support within the device community, the device folks would like to have a joint project with ISO TC 210 Quality management and corresponding general aspects for medical devices. This is different TC that the human pharmaceutics folks are accustomed to work with, namely, ISO TC 215 Health Informatics.

There was a small change to the management process; that is, less phone calls.

The next milestone for the project is the January DSTU ballot. I would expect the FDA to test the draft standard, and depending on the test results, implement.