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
Learn about the major components that need to be installed
-
EMERSE application (WAR file)
-
Apache Tomcat
-
Apache Solr
-
Database (several databases are supported such as Oracle, SQL Server, Maria DB, Postgres, and more.)
| In general we assume that most installations should not require modification of the source code, although it is available through our Github Repository (if you would like to be given access to the repository, please contact us ). |
| The database (DB) does not store documents, only user information and application details such as audit logs. Solr stores the documents in its own data store. Thus, the DB does not generally need to be very powerful or large. |
| Linux is not necessarily required, but we have not tested the implementation on other operating systems. |
Ensure browser compatibility
-
Most standard-compliant modern browsers should work, but extensive testing has only been done with Chrome. 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
-
local accounts in EMERSE tables
-
Mix of both LDAP and EMERSE tables
-
Understand the purpose of the Attestation page
Identify processes for extracting documents from their sources
-
Custom solutions will be required for this
-
API, Webservice, SQL, Pentaho Data Integrator (PDI), FHIR, 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, Sex, Race, Ethnicity.
-
How will data be moved to the table in EMERSE, and with what frequency?
-
Consider how patient medical record number splits/merges will be handled
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
-
2-3x additional empty space beyond the size of the index, is needed for index optimization (needed for cleaning up deleted documents, etc)
-
Server requirements
-
Spinning 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
-
Database management (minimal SQL is needed)
-
Apache Solr familiarity