Tolven Documentation 

Below are architecture briefs and FAQs that provide in-depth technical and functional (clinical) information. You may also find help in our community forums.

Architecture Briefs

  • Data Flow – A high-level view of the primary data flows and shows where data comes to rest. This brief explains how Tolven exploits healthcare informatics standards like HL7 RIM and ASTM’s CCR, while at the same time providing high-performance abstractions for operational use.
  • Components – Brief descriptions of the system components used in a typical Tolven installation. It also covers some of the interchange formats and technologies used between components.
  • Provenance and Clinical Context in Tolven Systems – This paper describes the features in Tolven that support the identification of origins of clinical data.
  • Integrating data using Tolven – This paper describes an approach to integrating enterprise data using a Tolven Ecosystem.
  • Invitations – The mechanisms for inter-account communication and end-user notification.
  • Clinical Data Definitions – The contents of documents that can be extracted using the Tolven rules functionality are stored in the Tolven platform and are normalized, whenever possible, utilizing the HL7 Reference Information Model (RIM)
  • Metadata – The Tolven metadata mechanism and how significant aspects of Tolven applications are configured. It includes details of AccountType, MenuStructure, CSS, and other application-specific configuration information.
  • Widgets – The browser-based widgets used by Tolven wizards and drilldown forms.
  • Templates – The mechanism underlying Clinical Data Definitions. Called “Templated RIM” (TRIM), the mechanism provides fine-grained representation of atomic and composite clinical elements (blood pressure, vital signs, assessments, etc). This paper assumes the reader has at least a passing understanding of HL7 v3 and the Reference Information Model (RIM).
  • Web Security – Mechanisms that Tolven uses to mitigate security risks in the Web applications. It is presented as a point-by-point review of the OWASP top-10 security vulnerabilities for Java Enterprise Applications.
  • Encryption – Encryption of documents at rest in Tolven with some high-level coverage of cryptography. Contrast with SSL which covers encryption of information in transit between system components. Document encryption is just one of the levels of security provided by Tolven. Also covers document signing.
  • Rules – More details about the Tolven rules component. Rules operate in the context of an account (and usually a specific user and/or patient) when adding a new document (message) to the database.
  • UML Models – Key Tolven entities and processes are rendered as UML diagrams.
  • SSL – The Secure Sockets Layer (SSL) brief covers the very important ability to securely communicate between system components. In Tolven, system components require mutual authentication. Communication between components is encrypted, even when the components are running on the same host.
  • Java 5 – Since Tolven exploits the newer features of Java, this brief covers some of the more significant features of the Java 5 language. Links are provided to examples in the Tolven source code.
  • EJB3 – Tolven’s enterprise-class architecture depends on the new and dramatically improved Enterprise Java Beans v3 (EJB3) specification. The EJB3 architecture supports local calls for best performance, remote RMI/IIOP calls, JMS, .NET, and Web-services topologies. EJB3 persistence provides database independence while at the same time it integrates with Java security and transaction architectures. The extensive tutorial in this brief covers many of the features of EJB3 persistence using a very simple business model. Links at the bottom of the tutorial provide access to the source code.
Back to the top

Frequently Asked Questions

Q: How does Tolven store messages?
A: Tolven stores messages (or structured documents if you prefer to think of them that way) exactly as received, without modification. Tolven’s ability to do something useful with a given message, such as to index it for display on lists, depends on the format of the message and the availability of a “rule” to make the extraction. Tolven is supports CCR-based messages and HL7-RIM-based messages. Other formats are under consideration.

Q: How are rules used in Tolven?
A: When a document is added to Tolven’s document database, a background process applies rules to the document. Tolven’s rules will extract necessary information from documents/messages for clinical and patient application components such as appointment lists, disease-based patient lists, results-review lists, and the like. We expect Tolven partners will add rules to suit their specific needs.

Q: What kind of documents can be stored in Tolven?
A: Almost anything, short of large streaming video files (and that we’re working on!). There are two main techniques for getting a document into Tolven:

1) For example, the file upload servlet in the preferences window to upload a photo of yourself, the image is loaded into memory or into a temporary file depending on its size, and then loaded into the database.

2) Marshalling is the process of converting between an object structure in memory (often called a graph) and a serialized form, most often XML, that can be stored and transmitted. This serialized form includes HL7 messages and CCR documents. Technically, Tolven has a document type called (generically) XML. In addition to consuming and producing raw XML, this object knows how to marshal and unmarshal XML to objects in memory that can be used for various purposes, including evaluation by rules and for input and display. Tolven then has two specializations of the XML document type: one for ASTM’s CCR and the other for HL7′s RIM.

Q: How does Tolven store and process RIM-based messages and documents?
A: HL7 has dozens of RIM-based message definitions. Each message definition imposes domain-specific semantic constraints through prose or GELLO. and syntax via XML XSDs. All of these domain-specific messages are based on the RIM, which unifies the syntax across domains. From an implementation perspective, it would be prohibitively expensive and time consuming to deal with each of these domain-specific message types independently. Creating rules to process dozens, perhaps hundreds of different messages in different circumstances for different application purposes quickly would get out of hand. Some level of abstraction is needed.

Fortunately, in the case of HL7, abstraction of all these messages is not only possible, it is easy. Since all messages are based from the RIM, that is the abstracted model; there is, though, no RIM-level XML representation. So Tolven created one. This is not a new model. It is a RIM-based XML syntax, largely identical to the domain-specific XSDs that provides a simple and common representation of all possible HL7 messages.

Again, Tolven can store any document in its original fidelity, no matter what it is, and rules can transform one document into another document. Therefore, Tolven can receive and store HL7 v3 messages. Rules (or a simple XSL transform) can be written to transform each of those different messages into the generic RIM format. The generic format allows other rules to deal with a huge number of messages generically. Tolven applications, or any other application, can also generate generic RIM documents, skipping the domain-specific representation if that is desired.

Q: Is Tolven a Healthcare Integration Engine?
A: It was not our intent to simply develop a Healthcare Integration Engine, but Tolven does have many of the attributes of an integration engine. Two examples should help explain.

First, when a rule processes a new document, it can use information gleaned from that structured document/message to populate other data structures useful for efficient display by end-user applications; however, a rule can also create new documents (or messages). The rule can use information it gleans from the original document as well as other information in the database. Tolven’s architecture allows one message format, say an HL7 v2 message, to be “transformed” to a RIM-based format (or any other format). In so doing, the transformed message is then subject to the same rules as if the message had arrived originally in that format.

The second example explains why Tolven works this way. In healthcare, it is often the case that one-to-one transformations between formats are difficult or impossible. Let’s say you have a certain stream of messages that for whatever reason are much richer than other streams. If you had a “standard model,” then you would be faced with a choice of supporting the richer messages or dumbing down the model to accommodate only the simplest message. Tolven does not want to impose such a barrier. So we always store messages in their original fidelity, whatever that is, and let the rules decide what they can use and what they can’t use. This means that rich data stored in Tolven as structured documents but ignored by current rules can still be harvested in the future.

Q: Why don’t I see HL7 RIM elements in the Tolven database schema definition?
A: Tolven is careful to avoid a common problem in healthcare: provider-specific customization in the database. This is often at the core of what prevents one provider from being able to talk to another provider or what makes such an effort expensive. While the HL7 RIM is a very good model, it is not the only reasonable model. Tolven does not want to impose the unintentional model limitations that are common with many software products: software vendor X supports version Y of standard Z. If we were to “memorialize” a specific version of a specific standard, our users might have to modify the schema to handle special needs and that would lead to compatibility issues, migration issues, etc. Tolven “abstracts this problem away” with the consequence that no specific standard shows up in the core data model. One way you might look at it is that Tolven standardizes at the XML schema level rather than at the database schema.

Q: Does Tolven use SSL? How is data in Tolven secured?
A: We should first point out that storing patient information on a server in a secure data center is far more secure than storing it on laptops, on departmental systems or in a doctor’s office – the equivalent of keeping your money under a mattress (or in the case of a laptop, equivalent to keeping your money in a money belt).

Virtually all browser-based applications that carry sensitive information use SSL, including Tolven. SSL is used when accessing your bank account on-line or purchasing a book online. For an application such as Tolven, the entire session is encrypted using SSL, not just during registration. In other words, whatever one does regarding their health, Tolven considers private. You’ll notice that in the Tolven system, the padlock icon in the browser extends through the entire session. Tolven also uses a data center with strict physical, hardware, and software measures.

It is important to understand what SSL does and does not do.

What SSL does
1. SSL authenticates the identity of the server. This reduces the likelihood that some other system can pose as your server in order to gain private information from you.
2. SSL protects data transmitting between your browser and the server. SSL is similar to encrypting a phone conversation to prevent eavesdropping.

What SSL does not do
Once data arrives at the server, the information is decrypted and is once again readable. This means that in most cases the user must trust anyone “at the other end of the line” to not intentionally or unintentionally disclose that information without the user’s permission.

So, while SSL protects data in transit, Tolven goes on to protect data once it arrives at the server (the data at rest). Why? Because no matter how hard the operations staff works at protecting data at rest (in a database), it only takes a momentary breach to lose a lot of information, even when the user is not logged into the system.

The ways that a database can be the subject of information theft or unintentional disclosure are too numerous to list here. What is important to know is that if in the unlikely event that personal data is accessed in an unauthorized way, Tolven software provides a last-line of defense.  The most sensitive data is encrypted in the database while at rest in such a way that only users of the Tolven account the data belongs to can actually read the data.

In other words, even if someone could gain access to the database or acquires a backup copy of the data, they will just see encrypted gibberish. To break that encryption, the “bad guy” would have to acquire the password of each Tolven account in the database. Since passwords are never stored by Tolven, this would be an arduous task, further spoiled if users changes their passwords.

This approach means that end users have complete control over who can see their data. Unlike most systems, Tolven prevents even the operations staff from accessing protected data unless the end-user grants access.

There are many other levels of security in Tolven. This response provides a glimpse at how serious Tolven is about protecting health information.

Back to the top