UC Berkeley's informed consent wizard web application
The Consent Builder application is intended to improve the completeness and consistency of consent forms for human-subjects research by guiding researchers through providing study information and then generating a consent form that incorporates that information according to general guidelines.
Our goal was reasonable functionality in a reasonable timeframe rather than covering every possible use case. This meant that we did not try to implement features like a work-sharing model or question list maintenance within the application. We also aim for flexibility by generating an editable document; the application does not need to cover every extraordinary circumstance.
The existing solution was a set of consent form templates which interleaved suggested language and instructions for completing the form. Consent Builder improves on this by separating instructions, supplied answers, and template language, which simplifies instructions and reduces confusion.
There are two main user interactions with the application: answering questions about the study and requesting a Word (.docx) document download.
The questions are presented in the style of a “wizard,” one at a time and in a linear order. Based on answers to earlier questions, the application can skip some later questions as not relevant. Answers are saved progressively, and a returning user has the option to select an in-progress consent form and continue answering questions where they left off.
At the end of answering questions or from the application home page, a user may download a Word document which connects those answers in standardized language and order.
The questions, their order, and relevance are defined in an XML document that is maintained by a programmer and compiled into the application. The questions are presented one at a time with links to skip back and forward through the list.
The question maintenance could be improved by taking input from files maintained by a functional owner and transforming to the required XML; significantly more adaptation would be needed to update question definitions without having to re-deploy the application.
One possible UI improvement may be to add a navigation sidebar to the question view, allowing users to go directly to an arbitrary relevant question.
The Word document is created using a third-party library (docx4j). The document construction is defined in the application code and requires programmer intervention and re-deploying the application to change the document output. Inserting headers and paragraph text is straightforward, but developers wanting to include other Word features such as tables will need to be comfortable with WordML.
There may be options for allowing functional owners to work more directly on the output document, including use of Word Content Controls or a template language such as FreeMarker.
We use freely-available packages for data persistence (Hibernate), client-server communication (Vaadin), model/view/presentation separation (MVP4Vaadin), and Word document creation (docx4j). The question list is defined in Spring configuration, with question relevance checking that accepts either simple text-matching or Spring Expression Language expressions over the answers given by users to previous questions. Our own code is written in Scala, which provides some useful flexibility but also has some awkward edge conditions where it interacts with Java code in the supporting libraries.