1. Comments from Univ Leicester Experience with caTissue Modifications University of Colorado Cancer Center Denver, Colorado June 22 nd – 24 th, 2011

2. Handout #2 Biomedical Research Informatics Centre for Cardiovascular Science, based at Glenfield Hospital, Leicester in the United Kingdom. We have recently gained funding from JISC (Joint Information Systems Committee in the UK) to generalize our approach and make it available as a software toolkit designed to provide support throughout the UK for joint NHS and University research teams working with tissue samples and anonymised patient data. Experience from Nick Holden (IT Manager) and Jeff Lusted (Developer)

3. Handout #3 CaTissue Customizing for a different locale. We still have problems with date formats which are expected by staff to be in the UK (or European) format: ie: ddmmyyyy or similar. A small but significant point. The upgrade process to 2.0. Is there some way to preserve configuration details across upgrades? re-set using caTissueInstall.properties - future upgrades need to allow for in-place upgrade to respect existing configuration settings. JSP. My experience is that complex ui's based upon JSP are difficult to maintain. Is there a possibility of using a more aesthetic approach not so dependent upon scripting? Eg. Wicket open source framework that we use within Onyx is highly sophisticated and maintains complete separation of HTML from Java code.

4. Handout #4 CaTissue Client API (1/3) Client API was used to develop another small web application which facilitated rapid data entry. The experience of developing with the client API was painful (sometimes very painful). The Hibernate lazy initialization problem was a frequent and annoying headache. We hand coded a set of wrappers around domain objects to overcome the problem. But it seems to me this would be better tackled by code generation of more intelligent “proxies” for the domain objects.

5. Handout #5 CaTissue Client API (2/3) Lack of transactional semantics. It seems each CRUD interaction with a domain object via the client API results in a standalone transaction of an SQL statement. This gave us all sorts of problems during development, and is really an undesirable aspect of the live system. We cannot guarantee rollback of a whole “unit of work” if we have an unpredictable failure.

6. Handout #6 CaTissue Client API (3/3) The client API is complex covering many domain objects, with quite a range of methods for each class. It is very difficult to develop another application using the client API which deals with authorization effectively. Can authenticate a user, but tripped up when one action (a method call) within a series of required actions does not come within the authorized role of a user. I do not think it is feasible for the API adequately to deal with the granularity of privileges in these circumstances, since the business model we use may effectively differ from the business model that drives the main application. Indeed it may not be possible to be consistent even if the two models matched exactly, since the main application does not (presumably) match every method call it makes to domain objects against a user role, whereas the client API seems to do exactly this. Development of a workable strategy would be useful indeed. I have some ideas, but what do others feel, and what is their experience?

7. Handout #7 Configuring caTissue when Installing Inconsistencies in configuration when installing CaTissue are frustrating – some items configured prior to build, some afterwards, some participant fields are fixed, others are configurable. Would suggest every field for participant and protocol objects (at least), even name fields, should be configurable, optional and perhaps even allow for additional fields at install time. Some of the configuration options in the xml do not in fact affect the deployed software despite the user guide and comments suggesting they do (site logo and associated URL were problems for us), which required amendment of the code post-deployment. This wasn't trivial.

8. Handout #8 Internationalization Three broad aspects: 1.Representation of some data (e.g. date) in different formats according to different locales, 2.Inclusion of relevant data elements (Social Security #, IRB / ethics approval identifiers or 'Race / Ethnicity' as examples) according to local ethico-legal and cultural context 3.Language translation of all interface elements.

9. Handout #9 Documentation CaTissue technical guide deals primarily with the use of the API to interface with CaTissue. Makes reference to a 'CaTissue Design' document ("This document describes the design of CaTissue"). That document deals with query design, the API and changes to the Object Model to facilitate multisite repository operation of CaTissue. If there is a Technical Design document?, dealing with the architecture design of CaTissue, the Object Model, the conventions and suchlike, it should be available within the NIC wiki or the Knowledge Centre for study. inconsistency in approach in relation to coding conventions (e.g. variable naming schemes, capitalisation) which leads to some inconsistent behaviour, especially in relation to the creation of database tables. Documenting such conventions is essential if the community is going to be encouraged to participate in development.