Overview

This document is meant to serve as a brief checklist highlighting the major issues that will require consideration before implementing EMERSE. Additional details about these topics can be found in the accompanying technical guides. Any system that contains protected health information (PHI) and integration with a local IT environment will take careful planning. This checklist should help with that initial planning/scoping.

Familiarize yourself with EMERSE

Learn about the major components that need to be installed

  • EMERSE application (WAR file)

  • Apache Tomcat

  • Apache Solr

  • Apache ActiveMQ

  • Oracle database

In general we assume that most installations should not require modification of the source code, although it is available upon request.
The Oracle database (DB) does not store documents, only user information and application details such as audit logs. Solr stores the docmuments in its own data store. Thus, the Oracle DB does not generally need to be very powerful or large. There is nothing inherently specific about Oracle that EMERSE requires, so it is theoretically possible to use another database. However, the current DB build scripts and queries are built using Oracle.

Ensure browser compatibility

  • [ ] Most standard-compliant modern browsers are supported, including Chrome, Firefox, and Safari. Modern versions of Internet Explorer should work, but if you are using Explorer in a 'compatibility mode' so that is works with older systems, EMERSE may not work.

Determine authentication procedures

  • LDAP

  • EMERSE tables

  • Mix of both LDAP and EMERSE tables

  • Understand the purpose of the Attestation page

Identify processes for extracting documents from their sources

  • API, Webservice, SQL, Pentaho Data Integrator (PDI), intermediary custom code, etc.

  • Consider the native format of the document sources (plain text, HTML, RTF)

    • Consider document transformation to TXT or HTML (needed before pushing documents to Solr)

    • DB rows may need to be concatenated (also needed before pushing documents to Solr)

  • push vs pull

  • Frequency of updates (real time, nightly, weekly, etc.)

  • Consider need for development of an intermediate document repository (helpful for rebuilding indexes, scanning for changed documents)

  • Consideration for how documents will be pushed to Solr

  • Understand documents metadata requirements needed (how will it be mapped, labeled, etc.)

Identify source of patient/demographic information

  • First name, last name, DOB, Gender, Race, Ethnicity.

  • How will data be moved to the table in EMERSE, and with what frequency?

Identify source of study information from an electronic IRB system (optional, but a good idea)

  • How can local data elements be mapped to EMERSE study tables

  • How will data be moved to table in EMERSE, and with what frequency?

Spec out storage/server requirements

  • Space estimates for # of documents and formatting

  • Need 2-3 x space for index optimization (needed for cleaning up deleted documents, etc)

  • Server requirements

  • Disk vs SSD tradeoffs (speed, costs)

Linux is not necessarily required, but we have not tested the implementation on other operating systems.

Identify local expertise in technology management

  • Linux management

  • Oracle management (minimal SQL is needed)

  • Apache Solr familiarity

Regulatory considerations

  • SOPs for how users obtain accounts

  • SOPs for when accounts are turned off/disabled

  • IRB for the overall system (such as a 'repository' application)

  • IRB approval for each individual study as well (tracked through the EMERSE attestation screen)

Local training considerations

  • Help videos are already available online

  • May want to develop some local training materials

  • How to spread word to other users about how to gain access, IRB considerations, training, etc.