Frequently asked Questions

From CaisisWiki

• Is Caisis really free? Yes. Caisis is freely downloadable from the downloads page on this web site.

• Why do you give it away? Caisis was built to address problems in cancer research and promote collaboration using large, standardized sets of validated data.

• How do I install Caisis? Caisis is a web based system built in ASP.NET/C# using Microsoft SQL Server 2008/2010 database. The system can be installed anywhere from a laptop to a enterprise server farm. For the best security and performance the recommended configuration is one web server and one database server. Assistance from someone knowledgeable in web based systems is typically required for proper installation. Technologists from BioDigital Systems can provide consulting support when needed.

• Can Caisis be used to manage data on diseases other than cancer? Yes. The Caisis architecture provides a platform that can be easily extended to support almost any disease. Recent extensions to AIDS and osteoporosis found few additional fields were required to manage data on these diseases.

• Is Caisis HIPAA compliant? Caisis contains a robust security model, comprehensive auditing, and other features to address many of the requirements for HIPAA, but we have never had the system reviewed and certified by a HIPAA consulting firm. There is no true certification process, so in both HIPAA and CFR regulations, it is just a matter of having documentation from an independent 3rd party. The system was reviewed and validated by an independent web security firm in 2009.

• Is Caisis CFR Part 11 compliant? Most requirements in Caisis are addressed via audit logs and documentation, but it has not been formally reviewed by a 3rd party. We are working with a Clinical Trials management consortium who plans to manage FDA track trials, so 21 CFR Part 11 will be fully reviewed and documented for that group in 2011.

• At most sites, data feeds are established to pull demographic, scheduling and laboratory data into CAISIS from clinical systems to reduce costly manual data abstraction and data entry.” Is there an ETL/SSIS tool available for this or do we need to develop our own? In most instances, the data feeds are too different from site to site to allow the sharing of SSIS tools / scripts. We are happy to review our process and scripts with you. Please note that the next release of Caisis will include a new HL7 API, which may make this process much easier.

• How frequently and how radically does the data model change – will we have to examine and perhaps re-work etl and feeds into and out of the system on a regular basis or does what’s there generally stay there, in that ‘one model for them all’ – do you typically only add fields to the existing model between data model versions? With the release of version 4.0, we made some major changes to the datamodel so that it would more easily scale, without making radical changes to the "core" tables. While fields and even tables for new diseases are constantly being added, the majority of what's there, and what you would likely be mapping to from other systems will remain stable.

• Would we need to think about ‘business logic’– rules validations etc. – so that we can maintain data-integrity when feeding data into the system or is data manipulation fairly straightforward. If not are these rules well documented for the purpose of setting up feeds into the system-instance. Have other sites done this? Although there has been no uniform approach to feeding data into Caisis, it is fairly straightforward. The rules, such as unique database constraints, have intentional been left rather loose because we have not been able to find rules that consistently work well across insitutions. That said, we do think it would be very valuable to add rules/validation in the near future that could be easily configured according to the needs of each institution or even service/user group.

• How does the CAISIS team go about addressing situations where two sites wish to use different form flows/‘conversations’, or simply use the same variable/ui element labels for different things. What about different programs – eg. breast oncology cf. urology: would they have to reconcile and standardize on variable definitions. Or do ‘use-cases’ typically get represented one-to-a-screen. If so, won’t there be duplication and data integrity problems as well as deeper and deeper navigation problems as more and more programs are incorporated. Will we get to a case where all have to fit the application? We are working towards using vocabulary standards. Version 5.0 allows filtering of terms based on the "disease" a user is working within. Other than complaints between services about there being too many too many irrelevant terms, which we hopefully started to address in v 5.0, I have not heard of any reconciliation issues between services. In terms of user interfaces, we usually have a more generic interface, like Procedures or Diagnostics, that applies to any service, followed by an interface specific to the current users needs; i.e Prostatectomy Details. A major area of our current work is to allow system administrators to create interfaces that match data collection workflows (eForms). Creating eForms currently requires some programming, but we will release an "eForm Builder" that requires no technical expertise in the near future.

• Can ‘screens’/frames be bookmarked and/or put on a dashboard or do they have to be selected by navigation in context? Within the "Patient Data" tab there is currently no way to bookmark screens (but good idea). We used to have "workflows" built into that section, but we expect that the admin generated dynamic "eForms" mentioned above, will be the best of both worlds.

• Are field definitions/variables versioned when/if they are changed in the model … Would ‘views’ for previous versions of the data model in newer models make sense to preserve the integrity, reproducibility and extensibility of prior analyses of data? Much of the data analysis so far has been based on datasets exported from Caisis, but the actual analysis is usually done outside of Caisis. The exported dataset is therefore available for reference, even if the underlying data model changes (although I don't think the changes to the model so far would significantly impact results). We have plans to add more analytics within Caisis in the next release, so your thoughts may play a more relevant role and whether its through the use of views or other, definitely something we should keep in mind.

• Upon upgrade, do established meta-data tags get preserved. What happens if meanings shift or eg. two programs use the same variable to mean different things – how might meta-data annotation, etl and/or upgrades conflict or be affected? Upon upgrade, we provide the option to use the new meta data and vocabulary added to Caisis since the last release. The script is created so that it will not overwrite local modifications to either meta data or vocabulary. Ideally, we would go with some third party standard that allows local synonyms to minimize conflicts and facilitate collaboration.

• If simplified custom forms or other types of forms were developed, eg. for community sites and these not folded into the main development branch how would software upgrades be impacted – that is, how modular is the system: can we plug-in our forms or would we need to weave this in to the new source? The system was designed with this in mind; there are "Core" parts of the applications that when modified are difficult to integrate upon upgrade, and there are modular parts of the application that are easily maintained between upgrades. The form architecture was designed so you can add in your own interfaces. There is also support for "plugins": independent pieces of functionality that can be embedded in existing forms. A couple examples are the PSA graph and File Upload plugins. Typically if you create a new form or make an enhancement, that change is desirable to the whole community and we will do our best to roll it into the main branch for inclusion in the next release.

• How fine grained can access be and how do these translate to custom reports from the system? Currently group access is limited to the "Tabs". Within tabs there are more granular permissions to control user activity. There are plans to extend make access more granular, so within tabs views of data, reports, etc can be controlled at a lower level.

• What protections are there/will there be against destructive sql in custom admin reports? We use parameterized SQL wherever possible to prevent injections. If you have a malicious admin that has the abillity to upload destructive SQL statements to your web server there is not much we can do. In 2009 the system went through a thorough review by a prominent security consulting firm which found minimal threats. All findings have been in addressed in version 5.0.

• How well might data elements in CAISIS map to some common standard that we can use to translate from one system to another, eg. caBIG common data elements, HL7 vX, …? We will be creating an HL7 interface in the next release(post 5.0) and will be working towards CaBIG Silver level compliance. The previously mentioned Prostate Consortium will also lead to the development of utilities to move data from one instance of Caisis to another.

• What skill capacity might we need to work up to actively develop, integrate and productively adapt CAISIS for use more broadly across departments? Relational database experience, SQL, and some knowledge of programming in C# (easy transition from Java) would be essential. HTML, XML, Javascript are helpful.

• Would CAISIS scale for use across the campus, or would it make more sense to tailor individual instances on a department by department basis? Caisis scales for use across campus and is the recommended setup. There is a "dataset" concept built in, which allows you to segregrate populations of patients and users. Datasets can be defined by a variety of criteria, but the one used most often is department/service.

• Although subjective, how well written is the code. Is there a clear separation of concerns – would it lend itself well to ‘plugin’ development, can the functionality be accessed programmatically via api/across ‘grid’ nodes, how tightly coupled is the view code to the logical data model? Caisis lends itself very well to plugin or development of entirely new “modules” of functionality. Modules and plugins can be joined to the system via Xml configuration files. There are currently no services built into Caisis, but the API in the next release will hopefully be a step in the right direction. The code is constantly evolving and improving. The middle and data access tiers have been entirely rewritten to make the system more scalable and abstract complexities from the UI developers. These tiers are now very clean. There are parts of the UI tier that are remnants from before we knew all the scenarios in which Caisis would be used. The requirements, especially regarding extensibility changed, and this code could use refactoring, or in some cases a total rewrite.

• Would branching the code and maintaining it make sense? We found that groups who branch the code for local customizations have difficulty keeping pace with new releases. Its definitely an option, but trying to coordinate development with the main team and have those changes integrated in the trunk tends to work better.

• How straightforward would it be to incorporate validation (including cross-field validation) and conversion in forms? There are a number of ways to approach this with varying degrees of complexity. Happy to discuss based on needs.

• Is going to ‘caBIG silver’ on the project timeline? Yes we initiated the process in 2008 and hope to find time to move forward in 2010. As with any of the other items above, help to meet these goals is welcome and appreciated.

• Who owns Caisis? To protect the source code and limited liability the copyright to the Caisis source code is currently held by the Caisis Foundation established solely for this cause.

• I need help. Is dedicated support available? Yes. As an open source effort, you are free to use any vendor, contractor, or consultant, but technologists from BioDigital Systems have been leading the programming since the project began in 2002 and can provide dedicated support at whatever level needed.