The team at Neuron Health has just published a beta version of a significant upgrade to the open source Neuron Platform. Check it out on SourceForge!
Release 2.3.0-beta1, codenamed Conundrum, is a major release that incorporates updates for several system components. Due to these changes in core components, Release 2.3.0-beta1 Conundrum is being released as a beta. As such, this release has known issues with certain Neuron plugins (see below) and several upgrade considerations must be evaluated before using this release. Therefore, Release 2.3.0-beta1 Conundrum should NOT be implemented in a production environment.
Java version 7
As of this release, both the Neuron application environment and the Neuron development environment require Java version 7. When installing this release, be sure to have the correct JDK/JRE installed. Also, ensure that environmental variables and configurations are set to use the appropriate version of Java.
JBoss Drools version 6
Neuron now includes the updated JBoss Drools libraries for Drools version 6. The underlying Tolven snapshot includes the upgrade for Drools. As a consequence of this change, all rules packages should be reviewed for compatibility and proper execution in this new runtime environment.
Tolven snapshot 20140314
Neuron is now deployed alongside the current Tolven snapshot (dated 3/14/2014). There are some core changes in this snapshot, including changes to the TolvenEJB plugin. As of this beta release, there are some issues that must be resolved between the Neuron plugins and the Tolven core. See Known Issues below for more information.
Roberts-Hoffman is pleased to sponsor the work of the Neuron Health project in open source for health IT. The community at Neuron is working to overcome the challenges faced by the open health IT community. Here’ a great example of the community philosophy that we think will help foster growth, engagement, and learning in health IT.
Why are we here?
Healthcare is about people. Yet, no two of us require the exact same prescription for wellness. Every person on the planet is wonderfully unique having different needs and goals for their personal well being. Consequently, we must be able to make technology that works on behalf of patients and care providers, as opposed to making patients and providers conform to the requirements of a monolithic care system. A one-size-fits-all approach to health information management simply will not work. While quality, security, and standards are a necessary foundation, the human interaction with that foundation should be as varied as the people that use it.
The Neuron Health project was formed to support a community that creates the technologies that truly enable meaningful care of people’s health.
What do we aim to accomplish?
The Neuron Health project has three core objectives:
- We want to demonstrate that open source projects will deliver optimal care technologies.
- We aim to make these technologies readily accessible to patients and providers.
- We will work to foster a growing community of open source developers, caregivers, and community participants.
How will we do it?
Open community will be the seedbed of collaborative development between enthusiastic professionals from clinical, technical, and administrative circles. Open source ecosystems have proven that quality, security, and governance can be achieved while still supporting creativity and diversity. By embracing open source ideals – and by integrating them with the critical needs of the healthcare markets – quality solutions can be custom designed to meet the needs of patient and provider in any care setting.
A strong open source presence in the healthcare environment in the US is only now emerging. The Neuron project is committed to helping this community thrive. We strive to fulfill our core objectives in the following ways.
From time to time, one may encounter an open source project where there seems to be little interest in answering common questions or providing guidance for new participants. Responsiveness is essential to the health and growth of our community. To this end, you will find direct email addresses for the community organizers posted on the neuronhealth.org site. Use them, we want to hear from you. Also, you will find the forums for our projects are freely accessible on the web, and our core team is committed to keeping them fresh.
One reason that open source has moved slowly into healthcare is the complexity of this domain. Developers must be familiar with sophisticated standards and regulations, as well as the vast array of health data sources and the systems that manage that data. These knowledge factors, coupled with the risks of patient safety, have raised the bar for competent health IT professionals who are paid to do their job – let alone volunteers in open communities.
The Neuron team has recognized this condition of complexity in health data and systems as a barrier to the adoption of open source solutions and the growth of open communities. We – the community as a whole – have only begun the process of fixing this problem. To help people become familiar with the Neuron project and its underlying platform, Tolven, we are continuing to assemble resources that are freely available on the web. We publish a growing list of guides for Neuron on our sourceforge site. In addition, we have compiled some of the best resources for the Tolven platform at our sponsor site, robertshoffman.com.
Clear Communication about Free and Non-free
Despite the explosive increase in public awareness about open source software, we still find ourselves working to overcome expectations that open source means free. Many people have become disenchanted with open communities when they discover that what they expected to be free components or services are not free. As we all know, and as the economist Milton Friedman said, “There’s no such thing as a free lunch.”
Deep down, people can understand this reality. The problem arises when projects or communities are unclear about which services or components are free, and which are not. The Neuron community makes every effort to be clear about freely available resources – anything published to the websites in the community is free. That means the source code, the pre-built code, the virtual machines, the install guides and documentation, and access to the forums and email.
Our time, on the other hand, is not free (though many of us freely invest a great deal of time in supporting the project). People and organizations contribute time and money to make this community possible. In order to continue to support Neuron, these people must derive revenues from the community. This revenue comes primarily in the form of fees for services, such as support, training, and development, and from licensing.
If people don’t know about the project, how will they participate? Some open source projects rely entirely on word-of-mouth and viral spread of information to promote their project. This might work very well for some projects, but in the complex, high-risk world of healthcare, we need a better approach to engaging and informing our markets. We must create resources that will educate customers, users, and developers. Further, we need to build networks of complementary projects and services that will coalesce into optimal solutions. Last, but not least, we could learn a lesson from traditional marketing efforts and use the power of content and branding to increase the public’s accurate awareness about open source. Inasmuch as selling means “communicating the right value to the right customer”, we must sell open community health IT.
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.
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.
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.
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="installLdap" value="false" />
<property name="configLdap" value="false" />
<property name="installAppserver" value="false" />
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).
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.