Here are the Clinical Trials vision documents for review. The documents can be downloaded from the following links:

Vision Document (Word, 237K), Annotated diagrams (Word, 233K)

A PowerPoint document is also available that summarizes some of the content of the vision document along with the appropriate diagrams: Clinical Trials presentation (377K)

comments:

Mostly General Comments --David Kane, Wed, 16 Feb 2005 17:11:47 -0500 reply
Folks,

Here are my comments on the Vision document. It is also a chance to try out the Wiki comment feature to see if it will work well for us.

• I understand that the document is supposed to define a project vision for caSPR and caPRI, but I think it would be helpful if there was a crisper statement of the specific visions for the caSPR protocol and the caPRI tool.
• The beginning of the problem space section (Paragraph 1.4) seemed to be describing the planned solution, not the problem. What makes developing tools in this space hard? What are the obstacles that have prevented tools like these from being developed in the past? There is a great deal of good descriptive information about the clinical trial protocol life-cycle, but it was hard to find where this was expressed as a problem to be solved.
• In Figure 1, should there be a stage in the life-cycle for Site Recruitment? I know this isn't an issue for many cancer-center directed studies, I would expect that the protocol would need to support studies that involved more than one site, and there are steps involved with getting the various sites involved in a study -- notably, it usually requires the IRB at each site to agree to participation.
• In Section 2, be clearer about what is insufficient about the existing standards.
• I was unsure what is supposed to be involved in year 1. Figure 2, suggests that the protocol touches all many aspects of the clinical trial life-cycle. Section 2.3 suggests that only the areas identified in year 1 are in scope. Does this mean that the definition of the protocol will not include the attributes to support tasks 3-13 until years 3 or 5? If the plan is to try to have a complete 1.0 version of the protocol in year 1, make this clearer. If the plan evisions completing the standard in stages (e.g. level 1 with some core features in year 1, a level 2 with additional features later, etc.) then make this clear. If the plan for evolving the standard is as of yet undefined, a section should be included to explain how you plan to arrive at an answer to this question.
• Section 2.2 mentions the existance of "two use cases." I suspect that these are really two areas in which many use cases could be defined to describe the features in each.
• Also in Section 2.2, if I understand the document correctly, caSPR defines not a system, but a protocol, i.e. something static. If this understanding is correct, it might be useful to make it clearer that the use cases referred to in Section 2.2. are use cases of other caBIG systems that happen to involve exchanging protocol information.
• Figure XX (I think this is currently 2.5), which pieces of this figure represent caSPR? The scope that defines caSPR is not included in the figure.
• Section 3.2, Are there any tools that have been identified as consumers of the protocols described by caPRI? What are the adopters of caPRI expected to do with their protocol descriptions once they have them?
• Figure 3 caption, is there a reason XMI is being considered as an exchange format?
• Figures 3 and 4, what do the boxes to the right of caPRI represent?
• From a naive point of view, caPRI is just a specialized XML editor. What are the major features that are needed in caPRI that are beyond what you'd expect a specialized XML editor to provide?

Additional comments --harrison, Tue, 01 Mar 2005 22:20:44 -0500 reply
I generally concur with David's comments above. Here are a few additional thoughts.

• The vision and general approach described in the document appear to be compatible with caBIG architectural plans. That said, the document is primarily vision and architectural compatibility will hinge on implementation details. The only other issue related to compatibility that perhaps should be addressed is the likelihood that CaSPR will be able to use existing caBIG object models and CDEs.
• Though it may not be an issue at this relatively high conceptual level, the diagrams of the protocol lifecycle could be more accurate. In particular, patient management, reporting and administration, and billing/financial actually occur in parallel during the implementation phase of a protocol and are not independent. This may have implications for the design of a protocol representation.
• It would be of interest to have a bit more description about the envisioned relationship between CaSPR and existing or envisioned production systems that will manage clinical trials. For example, is CaSPR an external representation of the data (a transport format) or is it envisioned as internal to these systems?
• Is CaSPR just an object model or both a model and a specific representation (eg, XML)? The comments regarding working with HL7 suggest the latter.
• CaPRI isn't well-characterized in the paper. Is it possible to provide any more information about its envisioned design and inputs/outputs? Is it an XML editor as David suggests or does it manipulate an object model with any alternative representations as secondary issues? In the PowerPoint presentation, there are a lot of arrows going to and from CaPRI but what they mean isn't really clear.
• It may not be reasonable to cast CaPRI as both an editor and as a middleware object server for protocol representation (my interpretation of all the arrows in the diagrams). I suspect the latter might be a separate project. In the meantime, you might find that an XML editor that is configurable for specific input (such as Jaxe, http://jaxe.sourceforge.net/) might provide useful flexibility and serve your initial testing purposes if the focus is testing a standard XML representation through manual data entry.

Questions/Comments - Vinay Kumar --Vinay Kumar, Wed, 02 Mar 2005 12:09:44 -0500 reply
Few quick comments/questions:

• Does the CT lifecycle workflow shown in Figure 2 reside entirely within one organization on a single server?
• If caPRI implements a distributed workflow that encompasses multiple organization domains then do we need to represent the CT lifecycle workflow using a Grid aware workflow language?
• It seems the CDE Tool from NCICB provides a "formsbuilder" app where one can drag-and-drop (so to speak) different CDE's into a webpage to create XML forms. Is this tool useful here?