Overview
This guide 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
-
Read the online guides
-
Watch the videos for users
-
Try out the online demo version
-
Try out the virtual machine and look 'under the hood'
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. |
| Linux is not necessarily required, but we have not tested the implementation on other operating systems. |
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)
-
-
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
-
How can local data elements be mapped to EMERSE study tables
-
How will data be moved to the study table in EMERSE, and with what frequency?
| Importing IRB study data is optional, but a good idea. |
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)
-
Consider how many environments are needed (testing, QA, production), which may be important for when upgrades occur
-
Consider backup and recovery options, which may be needed if an index becomes corrupted (re-indexing million of documents from scratch can take days, potentially causing the system to be offline for a while).
Identify local expertise in technology management
-
Linux management
-
Oracle management (minimal SQL is needed)
-
Apache Solr familiarity