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 planning to support 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 customers 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 marshall and unmarshall 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 some 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?
I 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 doctor's offices; 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.
However, 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 the data while being 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 while at rest, in the database, 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 the user changes their password.
This approach means that the end user has 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 them access.
There are many other levels of security in Tolven. This response provides a glimpse at how serious Tolven is about protecting health information.
- The Tolven Institute
- License Agreement
- Products & Services
- Architecture Briefs
- Frequently Asked Questions
- Useful Links
- Complementary Projects
- Contact Us
Rely on the Tolven support team to help resolve problems during any stage of your application development lifecycle, deployment or implementation.