Monday, October 27, 2008


Last month I attended the Boston Area CDISC Users group meeting (BACUN). All of the presentations were interesting and useful. However, I found that the one by Lisa Chatterjee on BRIDG stood out as particularly informative.

The BRIDG Domain Analysis Model is a representation of protocol-driven biomedical/clinical research.

One of the goals of the effort is Semantic Interoperability - I don't think that this means that "following the model" guarantees semantic interoperability, but rather that BRIDG constitutes a starting point from which a semantically commensurable system can be built. The bridge team appears to view the model as a foundation for other more problem specific representations (CDISC/HL7 etc.). The idea being that if you can map BRIDG <-> HL7 and BRIDG <-> CSDISC the HL7 <-> CDISC mapping is (relatively) straightforward.

There is no question that BRIDG represents an excellent starting place for using data in an interoperable fashion.
All in all it shows a very inclusive approach
-- and a surprising openness to modifying the model to ameliorate difficulties encountered in use.

The core modeling language is UML and spreadsheets are used to track much of the mapping (there already is a draft version of a spreadsheet that maps the BRIDG R2.0 model to RIM2.18).

From the presentation:


I have to admit that I haven't examined the model in complete detail. However, from what I've seen almost everything that you need for the target domain is there and the level of abstraction feels right: low enough to be relatively easy to implement, but high enough so that you don't get wedged into a corner from the get-go.

I did look in a bit of detail at the adverse event model,which is represented in the Bridg Release 2.0 Static Elements report.RTF.

What we see in Figure 5 : View 4 - Adverse Event is ~ 90% of the complete domain model with a number of classes added in support of recording adverse events and tracking their eventual analysis/resolution.

Since adverse events raise some issues about semantic interoperabiltity that I want to talk about in detail I will cover them in my next post.

BTW on my mac, the only application that could open the .rtf file with the figures was open office 3. MS word 2004 elided the figures.

Monday, October 13, 2008

Seam: the ftl advantage

I finished the first pass schema for the flexible drug discovery framework and pointed the most recent (2.02) GA release of Seam at the database.

My hope was that it would produce pages with the latest ajax-friendly table sorting headers -- sadly it didn't. In addition, this version retains the practice of generating pages that use labels and column headers wired to a particular language (English) rather than allowing the headers to be language dependent messages, even though the pages fully support localization (via language specific files in the resources directory).

I was in the process of fixing these issues manually via emacs using these instructions (I find that emacs makes it easier to select the files that I want to edit -- Netbeans picks up too many files and deselecting 70 or so "extra" files is too much work). While making these changes, I was discussing a new system with one of my clients and recommended that they consider an open source solution since they could change it (or hire somebody to change it) if at some point they encountered something that they didn't like. I thought this better than the alternative of waiting for a potentially unresponsive vendor to pay attention to their problem.

As was saying this, I thought to myself: "Seam is open source, maybe I should try to fix the code rather than edit the result." I'm usually hesitant to go down this path. Sometimes it works, but my a priori estimate is that the process of understanding the code structure, getting the build environment running etc. costs a day (or more) before anything productive comes out the other end.

However, as a proof of principle, I thought I should give it a try and see how it went.

I'm very happy to report that given a combination of good architecture and good tool selection on the part of the Seam team, making these modifications was almost trivial.

Let me explain why, and encourage you to "do this at home."
The core reason is that the seam generate-entities command operates in a number of phases, one of which generates the .xml and .xhtml files using freemarker template files (.ftl). This allows the required changes to be made without either looking at the java involved or developing any understanding of the calling structure, etc.

The .ftl files (in ./seam-gen/view/) are pretty much self-documenting (which is handy, given the level of documentation included in the files) and very easy to change -- errors thrown by the freemarker engine are clear and easy to work with.

A couple of (minor) caveats
  • The .java files in the src/action will need to be removed between runs of seam generate-entities.
  • I think it is a good idea to point the seam generator at a different target directory (specified by ./seam-gen/ -- "workspace.home") while debugging so that you don't accidentally overwrite edits that you've already made (oddly I thought of this BEFORE I ran the generator)

In summary, if you find yourself making a lot of changes to seam generated files, change the .ftl files instead; it can be much, much easier.