Category Archives: Tolven Platform

Generate 2048-bit RSA keys for Neuron

As you most likely know, most modern browsers will no longer render a page encrypted with less than a 2048-bit RSA key.  For those of us who use the auto-generated self-signed certificates in Neuron for our test and development environments, this means we’ve got to upgrade.  There are a couple of options for generating new keys.  If you are deploying a new instance from scratch, it’s actually pretty simple to get your key length and algorithm up to snuff.  On the other hand, if you have an existing development instance, there are a few other steps you need to follow.  Don’t worry, the intrepid engineers working on the Neuron project have already traversed these shark-infested waters, and we have a few tips that should help you out.

In the more recent releases of the Tolven framework, the install process has become largely automated.  This is a great thing – for the most part.  It turns out that the ant scripts that deliver the automated SSL certificates are using the default key algorithm and key length, which results in a 1024-bit DSA key.  Though it has been some time since the CA/Browser Forum updated the requirements for SSL, most browsers still rendered pages using certs that didn’t meet the requirements.  However, recent updates to Firefox and Chrome changed that easy-going modus operandi.  Now, pages encrypted with anything less then 2048-bit RSA won’t even be loaded.  So, if you try to login to your Neuron instance, and instead of the login page you get an error message, it’s time to upgrade your SSL certs.

Cut the chat, what’s the syntax!

Let’s cut to the chase, then.  If you want to generate new keys for your app, here’s the keytool command to get you there.

keytool -genkey -alias tolven -dname “dev.example.com, ou=services, o=tolven, c=US” -keystore newKeystore.jks -keyalg RSA -keysize 2048 -storepass tolven -keypass tolven -validity 7300

Of course, you must replace dev.example.com with your local instance name.  Now that you have a cert that your browser will like, you need to propagate this to your JBoss configuration.  If you want more detail about how to make your Neuron instance use these new keys, jump on down to the The Handy Guide to Upgrading (below).

Generating Keys for a Fresh Neuron Instance

Now then, since the Tolven team worked so hard to automate the initial deployment of these certificates, you might also consider making use of that mechanism to simplify things.  If you need to deploy a new instance of Neuron, you can make a few modifications to the right ant script and the automated generation will take care of generating the certs and distributing them to the other components for you.

First locate the build.xml file.  Look here:

snapshots\V21_20140314_ONC_snapshot\tolven-installer\

Then, find the following ant target.  It should be about 170 lines down.

<target name="create-common-keystore-src" if="${createCommonKeystoreSrc}"> <keytool args="-genkey -alias tolven -dname &quot;cn=${tolvenDomain}, ou=services, o=${keystoreOrg}, c=US&quot; -keystore ${initialComponents.commonKeystoreSrc} -storepass ${password.commonKeystore} -keypass ${password.commonKeystore} -validity 7300" /> </target>

Having located the create-common-keystore-src target, just insert the -keyalg RSA -keysize 2048 arguments right before the -storepass argument.  Save this file, and continue with the install as normal.  The ant script will handle the rest for you, and your browser will be happy.

The Handy Guide to Upgrading

Those are the easy options.  Chances are, you have an existing Neuron instance that needs to be upgraded to work with the browser restrictions.  Here’s a guide for getting this done.

1. Backup the existing keys and certs

This section is like the fine print at the bottom of the rental agreement for a jet ski.  “Dear user, if you hurt yourself with this toy, it’s not our fault.”  Check out the following location, and make backup copies of the keys therein.

[tolven_home]\tolven-config\credentials\dev.example.com\

As usual, replace dev.example.com with your instance name.

2. Generate a new key pair

Once you have backed up the existing cert data, go ahead and generate a new key pair using the keytool command shown here.  Execute this command from the key repository folder (above).

keytool -genkey -alias tolven -dname “dev.example.com, ou=services, o=tolven, c=US” -keystore newKeystore.jks -keyalg RSA -keysize 2048 -storepass tolven -keypass tolven -validity 7300

3. Rename the keystore

Now rename the newKeystore.jks file to keystore.jks.  This should overwrite the existing keystore (containing the 1024-bit DSA key) with your new keystore that contains the browser-pleasing 2048-bit RSA key.  Keeping the file name, keystore.jks, simplifies the integration process since many of the components expect that file name.

4.  Get the new key into the trust store

Getting the key into the trust store is a two step process:  export and import.  While there are openssl commands that will accomplish this task, we’ve taken to using Portecle for this type of thing.  You can use the Java Web Start option, or you can download the jar files from SourceForge.  Either way, fire up Portecle and open the keystore (keystore.jks).  Use this tool to export the key pair from the keystore.  Pick decent file name and use the default file type since you will use Portecle in the next step to import the key.

Now, using Portecle, open the trust store, which is called cacerts.jks.  Import the key that you just exported from the keystore a moment ago.  There will already be a keypair with the alias tolven in the trust store.  That’s OK.  Overwrite the existing alias with your new keypair.  That’s the idea here, we want to update the alias known as “tolven” with a 2048-bit RSA key.  With this, and all other key manipulation steps, use the password “tolven” when prompted.

5.  Generate keys for PostgreSQL

Most of the components of Tolven will reference these files, but we need to create another set of files for PostgreSQL, following the same steps you’ll find in the install guide.  Make sure you are in the key repository.

[tolven_home]\tolven-config\credentials\dev.example.com\

Then run the commands that follow.  First make a PKCS12 key.

keytool -importkeystore -srckeystore keystore.jks -destkeystore keystore.p12
-srcstoretype JKS -deststoretype PKCS12 -srcstorepass tolven -deststorepass
tolven -noprompt

Next, prepare the certs for PostgreSQL.

openssl pkcs12 -in keystore.p12 -out server.key -nocerts
openssl pkcs12 -in keystore.p12 -out server.crt -nokeys
copy server.crt root.crt

Now, copy these new files to the PostgreSQL data folder.  These commands assume that you have followed the install guide for your system and therefore you have an environmental variable called PGDATA that points to the PostgreSQL data folder.

copy server.key "%PGDATA%"
copy server.crt "%PGDATA%"
copy root.crt "%PGDATA%"

Finally, jump over to the PostgreSQL data folder, and remove the password from the server.key file.

cd "%PGDATA%"
openssl rsa -in server.key -out server-nopasswd.key

Now, delete server.key and rename server-nopasswd.key to server.key.  Modify the properties of server.key and set it to read-only.  Done!

If everything worked according to plan, you only need to restart the component services of Neuron and you are off and running with 2048-bit RSA keys.  Restart OpenDS, PostgreSQL, and finally JBoss.

Neuron Health Upgrade Beta Release

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.

Head over to the Neuron Health project page or to the SourceForge project wiki for more information.

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.

The best health application platform you’ve never heard of

Seabiscuit

The press reports that there is a major crisis in the healthcare industry as a result of major expenses in electronic health record (EHR) systems that lack usability and interoperability and have depleted the cash reserves of more than 40% of the hospitals in the United States. Solutions are being proposed, but they all assume that the EHR market is sewn up by a handful of very expensive EHR platforms, in particular Epic, Cerner, and Allscripts. But as history shows time and again, races sometimes have surprising endings. One of the most famous literary passages comes from Benjamin Disraeli’s novel The Young Duke (1831). Disraeli’s protagonist, the Duke of St. James, attends a horse race with a surprise finish: “A dark horse which had never been thought of, and which the careless St. James had never even observed in the list, rushed past the grandstand in sweeping triumph.”

Is there perhaps a “dark horse” in the EHR field, just poised to challenge the overhyped, slow, clumsy, and expensive leaders of the EHR heat? All the troubles with lack of interoperability and usability of proprietary EHRs have suddenly put the spotlight on what may be the EHR dark horse, the open source Tolven Platform. What makes Tolven stand out from the crowd? In a word, design. Take a closer look at Tolven and you’ll find craftsmanship and architecture that make this EHR framework a contender.

In a Nutshell

In a nutshell, Tolven is a platform that can support a vast array of clinical information and applications.  Many of the prototype features are geared toward an electronic health record (EHR) feature set.  Moreover, the browser-based front end makes an easily accessible personal health record (PHR).  Lastly, Tolven’s strict attention to data quality and interoperability can be leveraged to deliver health information exchange (HIE).  All these components bundled together in a single platform?  Too good to be true, you say?  If you will permit me, dear reader, I’ll tell you how Tolven was built to be so versatile.  This article is part of a series that began with a case study about how our team built an inpatient EHR on Tolven, and will continue with a discussion of how Tolven can fill the EHR, PHR, and HIE roles.  The Tolven team has created a system that embodies Tim O’Reilly’splatform thinking” that will characterize the health technology revolution he predicted in the OSCON 2010 keynote.

In addition to all that, the Tolven Platform is open source. It can be installed for a fraction of the cost of proprietary EHR systems, and there are no recurring licensing fees. In fact, Andy Oram reported that the University of Chicago studied open source information systems in healthcare and found implementation cost savings can be as much as 60%.  Moreover, healthcare systems that implement the Tolven Platform own the platform, and they also own and have full control and ownership of the data. They have the freedom to configure the platform to work the way they want it to work, and test it for not just functionality, but also for patient safety.  Once doctors and nurses experience the simplicity of Tolven design components (more on this later), they can easily get more involved in building screens and workflows that are more meaningful to their own work.  Add these perks to the growing list of reasons why open source is working for healthcare.

Tolven’s Intent

The organization and the software that share the name Tolven began in California in 2006 with the vision of rethinking the purpose and use of health informatics.  A core team with impressive health and technology backgrounds conceived an information platform to eat up the world’s health data.  Vendors would build apps on it; clinicians would document and exchange care data with it; patients would control their own information in it; and researchers would gain meaningful insight from it.  Consider the design precedent set by this substantial objective.  If you look under the hood you will find that each Tolven component has been built to live up to the noble ideas of its creators.  Consequently, Tolven is one of the most powerful health data tools available today.

Designed to Scale

tolven-scalingA notable example of how Tolven’s design makes a better system is its message-driven and service-oriented architecture.  Each service component is decoupled from the others to make the most effective use of distributed, virtualized hardware, or even Platform as a Service (PaaS).  These modern notions of computing were built right in to the Tolven platform from the beginning.  So, there are no add-on modules required to run this system in your server room, your offsite data center, or your Amazon EC2 cluster.  The primary benefit here is that when you build clinical functions on Tolven they can be deployed to nearly any platform at any scale.

Designed for Real Data

Tolven_Flow_DiagramJust like its technical design, Tolven’s clinical data architecture was built with today’s informatics standards baked in.  Case in point, the basis for Tolven’s templated reference information model (TRIM) document structure is the HL7v3 RIM.  In addition to TRIM, the Tolven NoSQL datastore can also be made to store raw HL7, CCD, CCDA, or any other format you require.  Beyond this, Tolven created a metadata-defined index layer that allows you to maintain a consolidated and correct set of attributes for each clinical event.  The resulting value of Tolven’s architecture is that it accommodates all the expected data for clinical quality.  Plus, the structure stretches to capture the additional data that is relevant to your specific care setting.

Designed for the Web

tolven-componentsFinally, Tolven’s user interface gives developers the building blocks to create intuitive applications.  The screens are clean and data is well organized.  The presentation code makes proper use of Cascading Style Sheets (CSS), so you can refine the look of your application without invasive changes.  Specifically, the essential graphical design elements, such as colors, fonts, and component sizing, can be changed by simply switching out a CSS file; no code changes are required.  Tolven’s framework includes components that display summary, list, and detail information, along with wizard style data entry.  When implementing Tolven, system designers can put all these pieces together to create the workflows they want.  What’s more, because the User Interface (UI) is completely browser-based, clinical functions can be accessed from any platform and nearly any device.  Tolven’s UI emphasizes light-weight deployment and accessibility by requiring zero ActiveX controls, plugins, or browser add-ons for it’s core feature set.

Versatile and Useful

These are just a few examples of how the Tolven platform has breathed new life into health informatics and clinical application development.  For more depth, take a look at the Tolven Resource page.  I think you’ll find the platform has been engineered to meet the growing requirements of healthcare information systems.  Further, the combination of coherent design and modern technology makes Tolven well suited for a wide array of clinical applications.  In short, the platform is versatile and useful, as its designers intended.

The Tolven Team

To really grasp the scope of Tolven’s design, you should take a moment to appreciate the individuals who brought their considerable experience to bear on the project.  The cumulative depth and diversity of know-how on the Tolven team is what makes the platform extraordinary.

Dr. Tom JonesChief Executive and Chief Medical Officer, Tolven, Inc.

tom-jonesDr. Jones is among the patriarchs of healthcare informatics.  Initially, as a lauded professor at the University of Chicago’s Medical School, he pioneered systems to integrate clinical knowledge with emerging information technology.  Moreover, at Oacis Healthcare Systems, Dr. Jones was involved with the founding members of the HL7 organization.  Still further – adding a broad perspective to an already robust career – Dr Jones joined Oracle as a clinical leader in the Healthcare Strategy group.  His experience developing the Healthcare Transaction Base at Oracle took Dr. Jones around the world, and connected him with organizations representing the full spectrum of global health information.  Finally, as a founding partner at Tolven, Dr. Jones stands at the helm to fulfill Tolven’s vision of facilitating secure and modern healthcare systems.  Hear Dr. Jones for yourself as he speaks about open source and data privacy at OSCON in 2010 and take a look at his speaker bio.

 

John ChurinChief Technology Officer, Tolven, Inc.

With over 30 years in the IT industry, Mr. Churin brings a similar breadth of knowledge and experience to Tolven.  He filled the role of Chief Architect at both Oracle, in healthcare product development, and at Oacis, delivering clinical data on the web.  In addition to healthcare, he has developed solutions in finance, publishing, manufacturing, infrastructure and telecom.  Mr. Churin has a strong foundation in the fundamental technologies that are supporting information technology today.  In addition, having worked on many large-scale projects, his experience has made Tolven’s scalable design an architectural reality.  I’ve had the pleasure of working with Mr. Churin personally, developing and optimizing the Neuron Project plugins.   His profound insight and unwavering focus on security, performance, and maintainability helped us avoid some pitfalls and create better code.

Steven WeinerChief Operating Officer, Tolven, Inc.

Mr. Weiner contributes an extensive understanding of the healthcare industry gained from over twenty-five years in academic medicine, provider, health plan, and consulting organizations within the United States.   Mr. Weiner is also a founding partner of Tolven.

Neil CowlesBoard of Directors

Mr. Cowles is a founding partner of Tolven and served as CEO until 2012.  He is now an active supporter of Tolven on the Board of Directors.  Mr. Cowles is recognized as a thought leader in healthcare business and technology development.  He has delivered the keynote lecture at a number of international healthcare conferences.

Why we selected Tolven

In June and July of 2010, our team configured a Tolven instance to evaluate the platform.  Many of the attributes that I have just shared with you were not readily apparent as we first experienced the system.  Though we didn’t fully grasp the potential and power of Tolven right away, there were two notable qualities of the platform that hooked us and drew us in for a closer look.

First, the document-based data store presented itself as a well-conceived and elegant solution to a problem that Roberts-Hoffman had encountered when working with a proprietary EHR.  Specifically, the increased complexity on the back-end created by simple front-end customizations resulted in disjointed datastores piling up in isolated SQL tables.  The proprietary system allowed the flexibility that the end-user needed at the expense of the quality and cohesion of the clinical data.  However, the architecture in Tolven is ready for this challenge.  It refuses to compromise data quality, while still allowing the system to be agile.  Tolven’s document structure – based on the HL7 RIM – is elastic enough to accommodate the data elements our customers want.  What’s more, the metadata-defined index layer knits the individual clinical events events of a patient’s chart together and incorporates the setting-specific data as needed.

The second attribute of the Tolven Platform that was attractive and meaningful was its technology stack.  Tolven is built on industry standard components that are widely used.  To me, that means security, stability, accessibility, and longevity.  There is a wide pool of technical talent available to work in tools like Java, Javascript, and PostgreSQL.  Of course, no technology is immune to criticism, yet I simply observe that these technologies work, so people and organizations use them to solve problems.  With the support of such a vibrant community, these open source components will continue to provide what the community members expect; quality.

A Personal Connection

In addition to the considerable technical merits of the platform, we were also influenced in our decision to select Tolven by a fortuitous meeting with Dr. Jones.  As we began to explore the open source communities in healthcare, Vickie Hoffman (our CEO) and I attended the O’Reilly OSCON in July, 2010.  Dr. Jones spoke at this gathering (as mentioned previously) and also attended the more intimate Birds of a Feather (BoF) sessions after the scheduled program.  It was at one of these BoF sessions where Vickie and I first met Dr. Jones.  He was gracious enough to listen as we described our challenges and project objectives, and to share his own views and experiences in return.  As we discussed the state of proprietary EHR systems and the untapped potential of collaborative, open source solutions in healthcare, we realized that Roberts-Hoffman and Tolven shared a fundamental perspective on health technology.  More specifically, we agreed that vast improvements to proprietary EHR technology were needed, and that usability, data quality, and interoperability must take center stage.  We left Portland with a profound respect for Tolven’s heritage and the passionate people who brought it into being.

Over the following year, our team interacted more closely with the Tolven technical team and developed the first production modules included in Neuron Health.  Our success, and the momentum of the project, inspired us to return to OSCON in 2011 where Vickie, Dr. Jones, and I presented our work as a case study:  Collaboration – An Emerging Trend in the Healthcare Open Source Model.  In this talk, we highlighted the useful features that resulted from the collective efforts of our team, Tolven, the clinical team from our customer’s inpatient facility, and Lexicomp – all integrated into plugins for the Tolven Platform.  This case study provides tangible evidence for the viability of Tolven’s original purpose.  That is, facilitating better health informatics through collaboration on a shared platform.  Moving on from this significant milestone in the Neuron project history, we have had the privilege of continued involvement with the Tolven team.  Dr. Jones, Mr. Churin, and the Tolven team have demonstrated their commitment to ensuring that the platform meets the highest standards of quality, security, patient safety, and performance.  Rest assured, there is more to Tolven than a technical pedigree.  It is this human aspect, the personal connection and passionate investment, that can make the heart of a vibrant community.

So, what is Tolven?

While “careless St. James” has his eye on the power-house EHRs, a dark horse is emerging from obscurity.  Sadly, the over-priced proprietary systems that first engendered hope in the healthcare system are now demoralizing users and draining the resources of healthcare providers.  Nevertheless, hope is not lost.  Rather than focusing on the decline of the mighty, instead turn your attention to the west.  Just like the scrappy underdog from humble beginnings, Tolven has the moxie to be the Seabiscuit of open source healthcare platforms.  The synergy of passionate people, sound technology, and the need for affordable and useful solutions has set the stage for a surprise finish from the Tolven platform.