Tolven-The “Unified Platform” that Delivers All-in-One EHR/PHR/HIE

Brady MathisIt is hard to miss the fact that the healthcare industry in the United States and other countries are finding that their existing health IT solutions are not interoperable and are simply unable to distribute, or even acquire, critical patient information. There are two fundamental approaches to fixing this problem. First try to bolt on capabilities that will create kludge systems that have partial interoperability capabilities, or start from scratch with a fully unified platform that has all the interoperability capabilities built-in from the ground up. That would be the Tolven Platform, and that is what this article examines.

As I commented in my previous article, the Tolven platform is capable of supporting applications across the spectrum of patient care and health information exchange. The Tolven team has created a complete health information ecosystem that can be configured as an electronic health record (EHR), a personal health record (PHR), or an health information exchange (HIE), or as a unified platform that can do all that all at once. Tolven embodies the very concept of “platform thinking” that would characterize a health technology revolution as outlined by Tim O’Reilly during his keynote speech at the O’Reilly Open Source Conference in 2010 (OSCON 2010).

So, how exactly does the Tolven platform support a personal health record (PHR) for patients, an electronic health record (EHR) for clinicians, and also a health information exchange (HIE)?  It turns out that the answer lies in rethinking health informatics for the wired world. 

The earth shrunk, everything became connected, and most every human is now the proud owner of an ever-expanding portfolio of personal, digital information (whether your healthcare provider recognizes your ownership yet is another matter). Tolven has embraced the reality of a true personal health record by designing a framework that allows implementers to manage clinical data in connected world, while maintaining a strong emphasis on the patient’s control over their own data.

At OSCON 2010, Dr. Tom Jones outlined the bedrock of Tolven’s adaptable informatics engine, as he discussed “designing for the ecosystem.”  Specifically, Dr. Jones spoke with clarity about how a patient’s health information is the fundamental element that binds together the PHR, EHR, and HIE systems; and that’s how he designed Tolven. 

As an illustration of this design tenet, he shared a case-study about how the Tolven platform was successfully implemented in Europe where patient consent and access are more strictly enforced. Tolven’s fresh take on personal health data helped the platform rise to this challenge. 

It is clear that the health information ecosystem must be viewed through a new lens in order to create systems that truly serve the patients and providers. We need to move away from the traditional silo-and-portal information architecture that only allows patients to “peek” at health information held by another entity. Instead, applications must be built on top of secure, consolidated banks of readily-shared health data - controlled by the patient him or her self.

Tolven as a PHR

Here’s how the Tolven infrastructure can be configured as a personal health record (PHR). The versatility of the platform in this area is largely due to a particular mechanism called the account. In Tolven, an account is a tool used to segment the data that exists in the datastore. In their own words, “Tolven’s strongest security boundary, including encryption-based security, is enforced between accounts. In other words, information in one account is not accessible from another account.”  The account boundary is what enables a single Tolven instance to permit a person/patient – or a family – to view only their health information. 

Consider the following use-case:

An account for the Smith family is created and the parents are granted access to this account.  When the doctor sees Mr. Smith’s lab results, he or she can share that information with Mr. Smith by telling the system to put that data in Mr. Smith’s account (think bank account).  In addition, rules can be defined to determine what is shared and when, or the clinical staff can share specific pieces of information (read more about the benefits of JBoss Drools in our case study). The account boundary ensures information privacy for all parties; no unauthorized parties have any access to health information.

Let us continue this use-case at the Smith home.  Mr. Smith logs into his PHR account and can view the lab results as well as his doctor’s comments.  This of course is natively available in Tolven because the entire user interface is rendered in a browser window with no component installation necessary.  What’s more, the web configuration is thoroughly hardened against common attack vectors, so everyone can be confident that their information remains private. 

Now that Mr. Smith can easily view his health data at home, what level of detail is appropriate for Mr. Smith; what does he need to know about his lab results? Mr. Smith and his doctor need not have the same view of the clinical data in the system. The application security model of Tolven allows an administrative user to configure what components of the user interface are visible to the end-user. Thus Mr. Smith can see the information that is meaningful to him without any impact on what is or is not visible to the clinical team. 

Following this, Mr. Smith would like to report his personal health metrics to his doctor.  He logs into his PHR account and enters information about, say his allergy to latex, in the allergies section. Having completed this, he then directs the system to share this data with his doctor. When the doctor logs into the clinical account for his practice, he or she sees the notification that Mr. Smith has shared new information. The doctor can choose to incorporate this data into the health record as appropriate. 

Tolven Provider

Now that we have both personal and clinical information stored in "peek-free" Tolven accounts, and the authorized parties can securely access this data from their web browser, let us move on to discuss the connection between a person’s PHR and other health information sources. 

In Tolven, this connection is created by a provider.  The provider concept is necessary to support exchange of data between accounts (in Tolven-based systems) and direct information to specific clinical staff (i.e. one's primary care physician). 

First, the Tolven provider object is not permitted to access PHR accounts, but PHR accounts are permitted to look for providers that publish their availability outside of the account boundary. Think of a person searching the phone book for his or her doctor; the person finds the doctor(s) they are looking for because they are listed in the directory. 

Second, the provider is linked to a user (e.g. one's doctor) within a clinical account. The connection between person and provider requires mutual assent that mirrors the real-world relationship between the two. It is this association that supports secure two-way sharing of health information between a person and his or her doctor/health provider or coach. The Tolven provider concept acts as a bridge between the personal health record and the practice or facility health record.

Certified EHR right out-of-the-box

When one starts with the Tolven Platform and its prototype plugins, one gets a set of clinical applications that can accommodate the basic functions of intake, ordering, and documentation in a clinical setting. This data is stored in a manner that anticipates the need for analytics as well as information exchange. If an adopter has a simple set of use-cases, the prototype plugins from Tolven may suit them just fine. If, on the other hand, and adopter needs more complex workflow or customized data elements for their medical facility, then they need to use Tolven's more advanced capabilities.

Configuration Options

If an adopter wants to go beyond the basics, and start customizing Tolven, they will need to be conversant in XML. The application configuration relies heavily on XML-based documents to define data structures, layout, and behavior. The benefit here is that XML is an assumed dialect for most technical people, so it is not hard find people with the expertise. Also, adopters can use the existing configuration documents as a guide for simpler changes. 

Armed with an understanding of Tolven metadata and information architecture, one can handle some basic changes, such as rearranging wizards, adding items to drop-down selections, and so on.  For example, say a user wants to to add a data element, say a field to capture a patient’s preference for reminders: email, SMS, or telephone.  One can accomplish such a change by making XML changes to several areas, but one will also need to have firm grip on the concepts of TRIM and placeholder.

Being familiar with the HL7v3 RIM will get one by for simple changes like this one.  However, adopters need to be aware that when working on more sophisticated workflows, ignoring the subtleties of HL7 descriptors of clinical events can get them into trouble. 

Adopters that want to collect entirely new data elements or build custom data views, have the option of building their own plugins.

Building on Tolven

While adopters can use our guides to get a Tolven instance running in about half a day with their own development environment, that is only the tip of the iceberg in Tolven plugin development. Tolven has an ingenious mechanism-called the Tolven Plugin Framework (TPF)-that allows custom-built plugins to override metadata and workflow in the core of the platform. 

This is one of the hidden gems buried in Tolven.  If adopters don’t like how the default functions work, they can build their own plugin and include it in the manifest. The Tolven assembler will sort it all out and use the features that they build.

Sounds easy, right?  Speaking as someone who has used frameworks and rapid application development tools in the past, Tolven really is well designed for building their own features and plugging them in to the platform infrastructure.  But – there is always a but – but, getting a plugin built requires a comprehensive knowledge of the Tolven architecture. 

To aid developers in this effort, Roberts-Hoffman Software has assembled a resource page for Tolven that includes some requisite reading on this topic. To be frank, Tolven is an advanced system and understanding it is no small task. If one is looking for the shortest distance between themselves and their first Tolven plugin, I suggest to do what we did; buy some help. It really will save time in the long run and help adopters avoid costly refactoring. Again, take a look at our case study of building on Tolven to get an idea of what one can do with the platform.

Exchange and Ecosystem

Tolven’s original architecture team did not lack vision when they conceived the purpose behind this platform. Without a doubt, Tolven was engineered to fill the role of Health Information Exchange, and further, to unify PHR and EHR to form a complete ecosystem. 

Tolven's design follows closely the recommendations of ISO Technical Report 20514, which describes the characteristics of the Integrated Care EHR (ICEHR).  In Tolven’s thorough white paper, Using Tolven to Establish an Information Ecosystem, the foundation is laid for secure and useful information exchange. More than this, the Tolven platform as PHR, EHR, and HIE creates the potential for a marketplace of application developers and implementers. I’ve included some of the high points of why Tolven makes a strong HIE. 

Exchange and Incorporate

Tolven recognizes that exchange of information is only part of the picture. To share a CCD document between systems is a great start, but if the information within that document is not placed in context with the other data stored in the health record, then it is of limited use. It is for this reason that the majority of Using Tolven to Establish an Information Ecosystem is focused on explaining the technology that Tolven has created to make exchanged data useful. 

Using impressive terms like semantic normalization and truth maintenance, Tolven builds a strong case for their technology model. Simply stated, a Tolven-based HIE will not only exchange the health information, it can extract meaningful pieces of data and relate them to relevant data already stored in a patient’s chart.

Sound Use-Cases

The following sections of Tolven’s HIE white paper expound several use-cases that incorporate a large section of HIE use. They cover patients accessing their own health information securely as well as patients providing additional personal health information to providers. 

The use-cases also address the vast array of sources for clinical information that must be reconciled in the context of an HIE. 

Finally, Tolven ties the application developers marketplace neatly together with the growing number of information sources and new viewing requirements.  That is, with Tolven as the platform, any number of new and improved applications can make use of all the information stored therein, as well as define and contribute new information.

Sound Architecture

To make all of the integration and scalability possible, Tolven uses a strictly modularized component stack. The lack of close coupling between these tools allows essential flexibility for implementers. Basically, adopters can swap out nearly any part of the Tolven stack for something else that meets their requirements. Beyond this, the core of Tolven’s application is already equipped with APIs that are ready to be used or extended.

There is a great deal to be said for the difference between an application that was built to perform a function, and then had an API added to it, as compared to an application designed to be an API. The Tolven platform is the latter. What this means for the application developer is more function, less complexity.

Security and Performance

In addition to all the clinical and functional credentials presented in Tolven’s paper, it is concluded by answering two oft-overlooked questions. How secure is this data? and, Will it be fast in production? In short, the answers are quite and probably.  Tolven takes a proven, layered approach to encryption and data protection. And, to the credit of the designers, the implementation has some configuration with regard to what data is encrypted and what is not. 

Again, one can observe the difference between an application that had web-based communications added on later in life versus one that was engineered to communicate securely over the network from the beginning. Once more, Tolven is the latter. As far as performance is concerned, Tolven took the time to carry out a benchmark using ubiquitous Amazon Elastic Cloud resources and published the results. 

Having this baseline performance metric is a great way to start measuring one's own instance of Tolven, but it is no guarantee of performance. As Dr. Tom Jones of Tolven once said to me, “Tolven is not a toy.” When using a system that has vast configurability, one can always find a way to degrade performance. Tolven has taken great pains to attest to the performance of a properly configured system, but your mileage may vary.

Conclusion

In conclusion, Tolven has taken a fresh look at health informatics and engineered a platform to allow providers and developers alike to focus on the patient, as an individual and the owner of their own data and personal health and wellness requirements. This fundamental shift in the health information ecosystem - specifically person-focused platform thinking - is beginning to gain traction. 

This concept, and approach, has just been validated by VetAdvisor, the the nation’s expert in veteran-centric holistic care. VetAdvisor wanted to expand their outreach and services for military veterans re-entering civilian life. They needed a platform that would enable them to accompish this. After extensive study of case management tools, as described in this article, they found out that "like most early EHR/EMR solutions, the case management systems excelled at collecting, storing and reporting on data, but lacked many of the engagement mechanisms we needed."

According to Paul Handly, CTO of VetAdvisor, "we wanted a platform that would help us build and maintain a personal relationship with the veterans that we serve." He adds that "we quickly determined that Customer Relationship Management suites (CRMs) are at their core personal relationship management systems designed to get customers to buy products and services, and to facilitate customer engagement, would be perfect in a coaching context."

VetAdvisor selected SugarCRM, an open source leader in the CRM sector as their core engagement platform. According to Handly, "because SugarCRM is open source, we were able to quickly change the sales focus of the workflows and reports to better fit our social services mission." He says that "within a few months of the project start, we were able to stand up a fully functional coaching platform that acted as the central node in a web of services chosen specifically for their ability to safely and efficiently support our veteran focused coaching services." The platform, which VetAdvisor calls the Veteran Relationship Management platform (VRM), has allowed them to achieve "significant operational efficiencies with the adoption of a systems approach to coaching," allowing their coaches "to save hundreds of hours each year which directly translates to several hundred additional veterans receiving coaching with the same number of VetAdvisor coaches."

Holistic care projects, like VetAdvisor, coexist perfectly in the ecosystem envisioned by the Tolven team. Clinical data captured in the specialized front-end applications, can be securely stored in the Tolven database by means of the API. Person-focused apps that store data in Tolven effectively supercharge the clinical information they capture with useful longitudinal consolidation, interoperability, and vast analytical potential.