EMERSE Architecture Guide

The EMERSE application process is a Java based application. It is a standard J2EE web application that requires deployment in a Java servlet container such as Apache Tomcat running inside a Java Virtual Machine. We recommend using Apache Tomcat, as we have the most experience using it, but others such as Jetty could be used. Details on supported versions of Java, Tomcat and Solr are provided in the installation guide.

EMERSE leverages the Apache Solr project to enable searching of documents. Solr is a popular open source toolkit that enables fast searching and text retrieval by creating specialized indexes from documents. The EMERSE application uses these indexes exclusively to display, search and highlight documents. Therefore, to use EMERSE, a process needs to be implemented that will take documents from wherever they reside (e.g., electronic health record, document repository, clinical data warehouse, etc.) and send them to Solr for indexing. For more details on this process, see the Indexing code, below.

The Solr project umbrella includes REST based web APIs for querying, monitoring and admin tools, as well as the APIs for indexing and removing/deleting documents when necessary.

The database stores audit information, user searches, patient lists, patient demographics, and some configuration data. The database does not contain the clinical documents or the index. Thus, searching and highlighting of documents occurs without the use of the database; rather, these features are mainly enabled through the use of Apache Solr. Additional information can be found in the Installation Guide.

In order for EMERSE to highlight and search, documents need to be sent from their source locations to Solr for indexing. Because this process is likely to be highly dependent on local circumstances such as the location of the documents, it is not a core part of EMERSE and will have to be set up separately. Solr supports many mechanisms for receiving documents to be indexed, some of which are described in the EMERSE Integration and Indexing Guide.

At Michigan Medicine, a small Java application was created that pulls documents from various sources, then pushes them to Solr via the SolrJ API. Additional information on integrating your organization’s data with EMERSE can be found in the Integration and Indexing Guide.

EMERSE runs within a web browser, and although it may not seem like this point requires much consideration, it may be the case that your institution limits what browsers are available for use. EMERSE has been extensively in Chrome, and Chrome is the browser that we recommend using with EMERSE. It will likely work well with other modern standards-compliant browsers, but has not been tested. One important point to note is that institutions may sometimes have a 'compatibility mode' turned on with browsers like Internet Explorer so that it can work with older applications. In that case EMERSE may not work properly.

A document repository is recommended for EMERSE data integration, but not required. Documents get pushed to Solr for indexing, so from Solr’s perspective it does not matter where the documents come from. A document repository is not needed at run time for EMERSE, since EMERSE stores its own local copy of the documents (thus there are no real-time calls to the EHR or document repository when EMERSE is running). Nevertheless, having a document repository will be important if it becomes necessary to rebuild the indexes, or for comparing existing notes within EMERSE to any new notes that have been generated by the EHR. The structure/design of the repository will depend on local requirements, and some small amount of custom code will be required to retrieve documents from a repository and push them to Solr. Thus, the documents can exist almost anywhere, such as in a local data store, in the cloud, in a Hadoop cluster, etc. As long as there is a way to push those documents and relevant metadata to Solr, the actual source is unimportant.