All posts by D.J. Jacob

Using Jenkins for Tolven Deployment and Continuous Integration

Jenkins is a common tool used for automating building and deploying software.  With a little configuration, Jenkins can be a powerful tool for developing on the Tolven platform (or the Neuron Health platform).  Building and deploying plugins in the Tolven environment is a time-consuming process,  so automating it can provide considerable time savings in the long run.  Plus, setting up a continuous integration instance ensures you always have the current code deployed, speeding up QA.  However, using Jenkins to deploy Tolven requires a little ingenuity and finesse.

dashboard

 

Before we begin configuring Jenkins with Tolven, you should have both installed (see our Installation Guide).  As part of the Tolven installation procedure, you should also be familiar with the ant scripts that are used in deploying Tolven.  Finally, to use Jenkins for continuous integration, you will need to have a version control system , such as Subversion, set up to contain your code.  Note that this code repository does not need to be on the same physical machine as Jenkins, but you will need to provide connection information, including credentials if required, to Jenkins when setting up the project.

First, make sure the Ant Plugin is installed in the Jenkins Plugin Manager.  This will allow Jenkins to execute the Tolven ant installation scripts.  Now we will need to create a Jenkins project to build the plugins being developed.  For continuous integration, the project should be configured to poll the source control repository on some interval and check out the entire development environment file structure (there are some supporting ant scripts that must be present for the build scripts to work).  We will use the “Invoke Ant” build step for each task in this plugin.  The project should execute the deploy-to-local-repository target for each plugin being built.  Note that you will need to specify the path for each build.xml file under the advanced section, since there are separate build files for each plugin.

deploy-to-local-repository

Next, the updateDevLib target from the plugin\managePlugins.xml build file should be triggered.  This target ensures the DevLib gets updated with the newly compiled code.

updateDevLib

Now each of the plugins has been built and is ready to be deployed.  Note that in some special circumstances, if you add new code to a plugin and a dependency on that code to another plugin, this build script will fail because the devLib is not updated after each plugin is built.  You could resolve this by adding the updateDevLib target between each deploy-to-local-repository target, but this would be overkill in most situations, and negatively affect the time required to complete the build.

For the second Jenkins project, we will be redeploying the Tolven application with the changes we just built.  It should be triggered by the successful completion of the first project.  Before this project can work, however, we need to perform some configuration on the Tolven instance.  Open plugins.xml in the tolven-config directory, and look for the properties “installLdap,” “configLdap,” and “installAppserver.”  They should all be set to false.  If the properties do not exist, add the following:

<property name="include">

     <property name="installLdap" value="false" />

     <property name="configLdap" value="false" />

     <property name="installAppserver" value="false" />

</property>

Now back to the Jenkins project.  The first step in the project is to shut down the Tovlen application, which should already be running.  If it’s not, it should be started manually prior to starting the automatic build.  Add a build step to execute either a batch command (Windows) or a shell script (Linux), then add commands to change directories to the tolven/tolven-jboss6/bin directory, and run the stopTolvenJBoss script (there are both .bat and .sh versions).

stopTolvenJBoss.sh

Next, add an “Invoke Ant” build step to execute the install-config-tolven target of the build file located in the tolven-installer directory under the current snapshot (for example, tolven/snapshots/V21_20140314_ONC_snapshot/tolven-installer/build.xml).  Note that this project can take quite a while to complete, so be patient.

With these two projects, you have the basis for continuous integration and automatic deployment with Tolven or Neuron Health.  These projects can be further expanded to include automatic unit testing, as well as other tasks you may wish to perform.  I would like to point out that setting up Jenkins with Tolven or Neuron Health on linux does require some additional considerations, mostly dealing with file permissions.  This will be a future topic of discussion.

Solving a Memory Leak Caused by the Default Tolven Configuration

For me, one of the major attractive features of the Tolven platform is its scalability.  In theory, Tolven can scale to handle anything from a personal health record for an individual or family to a large hospital, or even a network of large hospitals.  In practice, however, successfully scaling up can be a little tricky.  There’s some configuration to be done, and finding the magic combination is like finding a needle in a haystack.

As the number of users using our system grew, one major issue we discovered was a slow memory leak caused by the default EJB pooling configuration.  Out of the box, the JBoss application server comes configured to give each thread its own pool of Stateless Session Beans.  There are some benefits to this approach, such as a thread not having to contend with other threads for resources.  However, due to the way Tolven creates threads when processing documents, the number of EJBs in memory was growing boundlessly and crashing our system.  We resorted to periodic restarts of the application to prevent crashes until we could resolve the issue.

By switching to an EJB pool with a maximum size, we were able to prevent this unbounded growth.  Of course, with a maximum size pool, we had to consider the maximum value.  Setting it too low would create a bottleneck where threads were waiting for limited resources in the pool to become available.  Setting it too high could cause the same  problem we’re trying to avoid: running out of memory.   Fortunately, the default size of the pool we used has proven to be more than sufficient for Tolven, without even coming close to maxing out our available memory.

As usage continues to grow, we will continue to evaluate this configuration, as well as others, to ensure we can scale application performance to handle the load.

For instructions on how to configure the Stateless Session Bean pool, click here to visit the Roberts-Hoffman  forum.

Why Open Source Fits for Healthcare

A recent survey of open source software users conducted by Black Duck Software sheds new light on the state of the open source community.  Since its inception, the concept of open source has evolved and grown so that open source touches virtually every industry in some way.  As it has evolved, it has been molded to fit industries that have historically been resistant to open source software, such as healthcare.  Many of the reasons why open source fits for healthcare are obvious, but some may not be quite as intuitive.

 

8 out of 10 choose open source because of high quality

 

When the respondents in the Black Duck survey were asked why they chose to use open source software, eight out of ten said they chose open source software because of the high quality of software available.  Quality has become the most significant reason for selecting an open source product, surpassing even the low cost that has historically been associated with open source.  In the healthcare industry, where high quality software is critical to accuracy, efficiency, and productivity, this is great news.  Open source no longer represents an inferior, sub-standard, or incomplete solution.  More and more open source technologies are meeting certification requirements for healthcare, such as ONC Certification and Meaningful Use.

 

Open source has an inherent level of transparency that is not often found in proprietary software

 

Another concern vital to the healthcare industry is security.  Keeping patient health information secure is arguably the most important task of any healthcare software.  Open source software has long been viewed as vulnerable because anyone can access the source code and potentially exploit any vulnerabilities they find.  There has been a shift in this perception, however, as 72% of the respondents in Black Duck’s survey reported that they felt having many eyes on the code made it more secure, not less.  The idea is that there are more people to identify and address potential vulnerabilities.  This leads to much faster identification of issues and faster turnaround times for patches.  The recent announcement of the Heartbleed bug in OpenSSL is a great example of how an open source community can identify and fix an issue before any known attacks.  Open source also inherently has a level of transparency in development that isn’t often found in proprietary software development.  This means that it’s easy to verify that attention has been given to securing the software, and issues can’t be swept under the rug.

 

Perceptions have changed

 

Open source software has become a real and positive solution for healthcare.  Perceptions have changed; people now recognize that open source can deliver high quality, secure software.  Couple this with the historic benefits of open source, such as low cost and no complicated licensing agreements, and open source becomes an excellent match for healthcare.

 

Future of Open Source Survey Results Revealed webinar from Black Duck: http://advance.blackducksoftware.com/content/WRFoOS14

Integrating Mirth with Tolven

Roberts-Hoffman Software integrated Mirth Connect with Tolven as part of our inpatient EHR.  We use Mirth to handle our bidirectional HL7 feeds, managing messaging between live hospital information, lab, and radiology systems.

 Mirth can communicate with Tolven in a variety of methods.  For inbound communication, we implemented our interface with Tolven using Tolven’s Web Services API.  Tolven provides a sample Web Services Client that we modified slightly to meet our needs.  Mirth allows you to include jar files and instantiate java objects to use within your channels. We create an instance of this Web Services Client, which allows us to call Tolven’s Web Services API and submit documents to the document queue for processing.  Tolven also provides a RESTful API which can be called in much the same way.  The RESTful API is newer and more full-featured than Web Services, and is the Tolven recommended method for new interfaces.  We’ve successfully tested using REST to communicate from Mirth to Tolven.

We chose to use Mirth to translate the incoming HL7 v2 messages to TRIM, Tolven’s internal message format.  This way, Tolven already knows how to process them.  Tolven can also natively handle CCD and CCR documents, although in a more limited fashion.  However, you can create a document processor to process just about any type of document you wish to process in Tolven.  These document processors can easily be plugged in and give you very granular control of how the data is processed and stored.

For communication from Tolven to Mirth, we use Mirth’s SQL query functionality.  Depending on encryption settings, Mirth can query the Tolven PostgreSQL database to access the necessary data.  SQL views can be used if necessary to simplify and consolidate the data, as Tolven’s data structure can make direct SQL queries quite complex.

One source of difficulty in implementing the connection between Mirth and Tolven is SSL.  Making sure Mirth and Tolven can communicate securely can be tricky.  Installing Mirth and Tolven on the same server simplifies the process, as they can then share SSL certificates.  It is possible for Mirth to live on a different server than Tolven, but setting up the SSL certificates can be difficult.