Neuron Health: Building Clinical Applications On An Open Source Platform

Four reasons the Tolven Platform helped us succeed

The open source Tolven Platform really does what a platform should; it allows a developer to focus on creating function, not building foundation.  Further, Tolven’s plugin design and standardized user interface components make it easy to encapsulate and share clinical functionality.  Finally, and perhaps best of all, the information architecture of the entirely open source stack leverages current tools and implementations, which makes application development accessible to a large segment of today’s technical talent.

Brady MathisHere are four reasons building on the Tolven Platform can benefit healthcare application development, along with lessons learned through the experiences of Roberts-Hoffman Software.  Our team created the clinical functions of an inpatient EHR, many of which are available as open source plugins to Tolven under the Neuron Health project.  This project was our first entry into the open source community after having developed healthcare applications in-house since 1996.

1.  Project velocity for small teams:  build functions, not components

The Tolven Platform incorporates virtually all the fundamental components necessary for a secure, scalable, browser-based application.  By building on Tolven – and mentoring with Tolven team members – the Roberts-Hoffman team was able direct our efforts to end-user functionality and thereby achieve an unprecedented quick-start on our inpatient EHR project. 

No, this was not accomplished by a 20-man Hotshot crew of engineers.  Rather, we averaged a bootstrapping core of 5 members:  architect, project manager, and three engineers.  Our clinical steering team was formed in partnership with an inpatient hospital in rural Colorado, where we worked closely with clinicians from each department throughout the design and implementation. 

Neuron Health Encounter OverviewWe started with zero functional modules when we selected the Tolven Platform at OSCON in 2010.  Following this, we developed our basic medication order module and deployed this to production in five months. After the initial production deployment, we charged forward toward ONC 2011 certification and achieved this milestone in 2012, a mere 14 months later.  Furthermore, the inpatient facility using the EHR system was successfully able to attest to Stage 1 Meaningful Use three months after certification.

The Gist:  The Tolven Platform provides a robust foundation that is readily extensible, and selecting Tolven allowed the Roberts-Hoffman team to focus on end-user functions and implementation resulting in accelerated product delivery.

The numbers tell the story.  A team of 5 successfully builds and implements an inpatient EHR – from zero to Meaningful Use in under two years. Oh, and, we did it for under $1 million.

Food for Thought:  Participating as early-adopters in an open source project requires investment.

If you are considering participation in an open source project to extend and create something new and exciting, prepare yourself to invest both the time and dollars to make it work.  The Roberts-Hoffman team faced challenges and needed assistance.  Unfortunately, the community support was not able to keep pace with our requirements.  In order to overcome this impediment, we contracted to purchase special attention from Tolven, which we used for design, co-development, optimization, and more.  This expenditure was valuable for two reasons.  First, direct mentoring for our team helped maintain project momentum at a critical time.  Second, interaction with Tolven engineers augmented the skills of our core team and increased effective production.

2.  Clinical datastore:  configuration without compromise

Roberts-Hoffman believes that patient care should direct the information workflow, not the other way around.  Consequently, the workflows needed for optimum data quality and user satisfaction are as diverse as the people and care settings they serve.  This reality demands systems that are capable of better data dexterity than the heavy-footed database of yesterday.

Having witnessed the disproportionate complexity that resulted from simple customizations in a proprietary EHR system, the Roberts-Hoffman team was shopping for a smarter solution.  We saw too many examples of customized entry forms that dumped data into an isolated SQL table, without reintegrating to the patient’s core chart.  This form of configurability may provide the data capture function, but ultimately undermines the correctness of the data stored elsewhere.

Neuron Health Medication Drill DownEnter the Tolven NoSQL Data Model.  Tolven’s Templated Reference Information Model (TRIM, based on the HL7 RIM) makes up the core of document storage.  The RIM-based format supports all relevant clinical data – and then some, while providing mechanisms for coded and discrete data elements in every clinical event.  In addition to TRIM, the Tolven datastore can also be made to consume raw HL7, CCD, CCDA, or any other format you require.  Beyond this, Tolven created a meta-data defined index layer that facilitates a consolidated and correct set of attributes for each defined clinical event.

The Gist:  The Roberts-Hoffman team was able to define data objects with relevant  and coded attributes for events appropriate to our customer.

Furthermore, we were able capture that data anywhere in the application and maintain the indexes via the powerful JBoss Drools engine (more on this in the next section).  For example, you may collect a patient weight in the ER, you may collect a patient weight during an office visit, or even as part of an intake assessment for an inpatient stay.  Each of these three events is relevant to the patient’s history (stored as clinical documents), but as of today, the patient only has one weight (stored in the index).

Food for Thought:  The Tolven data model and the information architecture are far from pablum.

Before you jump into creating clinical modules, take some time to become familiar with the core concepts.  Without this solid foundation, your designs may force you to back up a bit and make corrections later on (as we did).

On the Tolven Platform, Roberts-Hoffman was able to build a system that supports the customizability required in today’s increasingly unique healthcare settings, while maintaining both the quality and correctness of clinical data.  Be aware that the Tolven Platform itself only provides metadata and clinical intelligence examples, and limited production-ready implementations.  However, the free plugins included in the Neuron Health project incorporate a higher degree of sophistication and specialization.   That is, our clinical team members provided real-world workflow and attributes coded for interoperability (using SNOMED-CT, LOINC, CPT, ICD-9/10, and more) to create plugins that they use in their facility.

3.  Information architecture:  the tools to scale from simple to complex

Getting started with information processing in Tolven is fairly simple. A clinical event is stored as a RIM-based document. That information is extracted, reasoned over, and stored as index data for quick access, as in the prototype lab order plugin. However, what you really want to know is how the framework performs in the complexity of real-world clinical contexts, where clinical events don’t wait their turn and making workflows simple for users means building complex, intelligent systems. 

Our experience with platforms, frameworks, and rapid development tools is that these systems provide the most value for creating basic components, but, on the other hand, a platform can be burdensome when elaborate functionality is required. The team at Roberts-Hoffman put Tolven to the test with our consolidated CPOE plugin and found that, in the right hands, Tolven can be leveraged to harness the chaos of clinical information.

Neuron Health Staff Messaging ListThe Roberts-Hoffman team took the prototype Tolven information flow to the next level by creating a plugin that combines lab, radiology, therapy, and any other type of order into the same TRIM document.  Further, we equipped clinicians with a context-aware, dynamic order entry wizard that lets users build a palate of orders for a patient on the fly, complete with conditional validation and alert messages. Should we send these orders to their respective ancillary systems electronically? Yes, sure. Well, perhaps we should just send the inpatient orders to the lab, but not the outpatient. OK, no problem.  And, we should make sure that the nurse knows that there are new lab orders and verify that he or she has seen them. Alright, got it.

In addition to the robustness of the TRIM document format (mentioned above), the Roberts-Hoffman team relied heavily on the power of JBoss Drools to make the magic happen for a complex workflow, such as CPOE.  Not only will Drools support reasoning over information in its own dialect, it will also let you execute Java code on the server, which opens the door to practically limitless information processing.

Finally, the icing on the cake is the well-designed Tolven UX.  The components of the platform gave us the ability to customize content, while simultaneously presenting this content in a consistent format throughout the application.  For example, we customized the vitals summary to aggregate data and show the most recent measurement in each of nine standard observations.  In this same view, we also used in-line Expression Language (EL) to display out-of-range values in red.  Even with these enhancements, our custom window into the vital observations appeared seamlessly on the canvas of the patient chart alongside all of the other views.

The Gist: Tolven’s standardized UX components and rules-based flows give developers the means to cut through the Gordian challenges facing clinicians today.

Our goal was to make a system that was smart enough to perform complex functions, but did not require a 5-day training course for clinical users.  The Tolven Platform helped Roberts-Hoffman create a cohesive experience that lowered the barriers to user-adoption without restricting performance.

Food for Thought:  Be prepared to build your improvements into the platform core and maintain them – indefinitely, if need be.

A few of the high-value user features we built required adjustments to Tolven core code (e.g. displaying images in lists, complex EL functions, commingling data objects on lists).  Not all of your improvements will be consumed by Tolven.  We elected to fund the inclusion of some changes into Tolven core, which may or may not be practical for all open source contributors.  On the bright side, Tolven’s plugin architecture will allow you to modify and build your own versions of core plugins.  Just be sure to plan for merging changes into future releases of the core code.

4.  Integration with third party tools:  Lexicomp drug database, Mirth, and Jasper reports

Our experience integrating our clinical applications on the Tolven Platform with third party tools was not exceptional, and that’s a good thing.  Any decent platform should certainly support such interactions, and Tolven does.  The plugin-based design was a convenient mechanism for segregating functional modules.  Also, the REST API supports a tighter integration by exposing internal functions to authenticated users.

For example, we were able to build a plugin that includes appropriate libraries to use the Lexicomp API for drug searches and real-time interaction checking, both of which rely on a pooled connection to MySQL server. Also, we integrated with Mirth to both send and receive HL7 for patients, encounters, orders, results, charges, and more.  Finally, we used PostgreSQL (the standard datastore for Tolven’s open stack) to create stored procedures that facilitate interactive Jasper reports for Clinical Quality Measures and Meaningful Use attestation.

The Gist: Tolven lacks no significant features expected in a platform…

Food for Thought:  …except detailed technical documents.

As might be expected from an open source project that is just beginning to fledge, technical documents that describe the operation of Tolven’s REST API were few.  Our team made headway in using the API by experimentation, reading code, and interrogating the Tolven team.

Conclusion

Building on the Tolven Platform was instrumental in the success of Roberts-Hoffman’s EHR project.  The skillful design of Tolven is evident throughout the platform components and is demonstrated by their performance.  The forward momentum we gained from the RIM-based NoSQL datastore, the capable information architecture, and the nimble plugin structure outweighed the investment of time and resources to become Tolven-savvy.  Though we encountered difficulty adjusting to the open source environment and engaging in the Tolven project specifically, our persistence and commitment eventually resulted in a positive outcome.  It is our objective to continue to participate in the open source community in healthcare with our plugins and experiences through the Neuron Health project.