This standardized component provides user identity, including password validation. While Tolven includes openLDAP in its distribution, any LDAP component can be substituted. Also, since Tolven uses the JAAS standard for authentication, non-LDAP mechanisms can be substituted.
A user is associated with one or more Tolven accounts. This user object is not used for authentication, which is done by the application container using LDAP. Instead, a user object is simply associated with an LDAP UID. What this user object represents is the user’s participation in the Tolven database as the author of documents and a participant in one or more Tolven accounts. When a user logs in, the user selects the desired account, and thus only ever works with one Tolven account at a time.
If the user changes his or her username, such as when changing eMail accounts, a new user record is created. This is because Tolven can’t always be certain of the relationship between a set of credentials and a real person. While this creates a bit more database clutter, it also ensures that potential identity ambiguities are accompanied by unique user objects. In particular, it is quite possible for eMail addresses to be reused by different people over time. A user may have access to more than one Tolven account, such as when a physician belongs to two practice groups (two unrelated provider accounts) and has a third, personal account. A person may also have more than one active username such as a personal eMail address and an eMail address at work.
A Tolven account holds health data on behalf of users. One account may have one or more users. For example, a family account might have two adult users and perhaps a teenage user. An account used by a provider might have a number of physicians plus clinical and clerical staff.
A Tolven account provides the primary unit of data ownership. Patient data, rules, schedules and lists are all partitioned into accounts. A user in one account is never allowed to see data in another account. The exchange of data, fundamental to Tolven, is carried out by different
mechanisms. The boundaries between accounts are firm. So called shared data is actually copied from the source account and re-encrypted (when applicable) so that the receiving account is able to read the data. At any given moment, all data visible to an account is owned by and is part of that account.
Unless specifically restricted, all users associated with an account will have access to all data held by the account. For example, a clinic (account) will have users that most likely will share access to all patients of that clinic. The users of a family account, say mom and dad, will have access to all patient data, including each other’s records and the kids. If this is not desired, a family might establish three accounts: one for each parent and one for the kids. Each parent then is a member of two accounts: one containing their own medical record and the kids account. Thus either of the parents can access the kids medical data but not each others.
Menu and page displays are controlled by metadata (see below). In general, these are read-only displays. AJAX and other technologies are exploited to provide very fast and efficient displays of these pages. At the same time, which tabs and menus are displayed can vary by account.
Tolven also maintains that page layout, new UI features, and such should be under user or account control, not under control of the base software. Thus, different accounts in the same system may be at different levels of uptake of various features.
A list is populated by rules and prepared for high-speed display. Patient lists, disease-based cohort lists, problem lists, new results lists, etc., are all examples of a generalized list mechanism in Tolven that represents the accumulation of many data elements into a convenient list for viewing. The columns for each list are defined in metadata. List data (and the metadata that defines it) is defined per account. This means two accounts can have completely different list definitions and contents.
In Tolven, a wizard is generally responsible for acquiring new or revised data from an end user. The direct target for wizard data is the document repository, described below. From there, the new data will be distributed, as appropriate, by rules. The simplest one-page wizard could be described as a simple data entry form. Nevertheless, Tolven uses the same basic mechanism for simple name changes or complex history and physical entry.
Menu metadata defines what will be displayed to the user and in what order. Metadata also defines the columns applicable to lists. In general, metadata does not define low-level page details. Instead, a number of individual templates are defined for things like menu bars and patient summary pages, while the metadata determines which template to use where.
Index data (internally called MenuData), is what is most often displayed on lists and in other page templates. Index data is not THE data, but is extracted and derived from document data (see Doc, below). For example, if a lab result arrived, some of that data might be extracted and stored in a new results list (index data). And that index entry will point back to the actual lab result. One new document can result in any number of changes to index data.
Document data covers a broad range of data types. At the fundamental level (the DocBase class in Java), documents are a string of bytes. Sometimes a document is no more than that, such as a photograph or scanned document (FAX). Other documents are structured, typically as XML, and may be in a recognized form such as CCR or HL7. These higher-level document types can be interpreted by rules to generate index data (described above) or other documents.
Tolven makes no predetermined judgment about the interpretability of documents. Say one rule knows how to recognize an HL7 V3 RIM-based lab result to find the patient and populate a new results list. Another rule might know how to translate an HL7 v2 message into a RIM-based result message. Another rule might know how to recognize a FAX and translate it into an HL7 V2 result message. Therefore, to the extent technology and effort permits, there is no end to the number of usable formats that can be processed as a document.
When a document is created and becomes active, it is subject to rule evaluation. Rules are defined within an account (many accounts might use the same rule but that is the account’s choice). Usually an account will have a number of rules and each document is subject to all of them. Upon evaluation of the content of a document, a rule can populate index data, or it can create another document, or it can do all of the above, or it can do nothing.
Rules generally have latitude to do almost anything programmatically possible, possible within constraints established by the account. A rule is unable to access data in another account.
What is very common is that a rule can access data both from the document itself and from the corresponding patient. This makes it possible to look for events based on patient data not known (or unreliable) in the document itself. See Rules paper.
A rule can use UMLS to evaluate, validate, and categorize coded vocabulary entries in a document. Wizards also use UMLS to prepare value sets for user selection (e.g., list of valid route of administration for a given drug).
The message component is external to Tolven but is used to describe the mechanism for messages getting into and out of Tolven. Getting a message into Tolven is simply a matter of creating a document. Tolven rules will then take it from there. The mechanism can be a simple web service or Java RIM call to the DocumentBean or through an alternate JMS path. The first approach creates the document synchronously and returns control to the caller while the second approach queues the message to Tolven which then creates the document. The second technique has no real benefit over the first. This is because creating a Tolven document is a very lightweight operation, no heavier than queuing a message. In both cases, the processing of the document is queued. So in the second case, there are simply two queue hops which could negatively affect throughput even though message response time could be less. Nevertheless, in high volume configurations with a lot of memory, the second (JMS) approach may yield better throughput.
The Tolven Platform is rapidly becoming the most widely adopted open source solution for healthcare information technology globally. Tolven clients in Europe, North America, and Asia are leveraging the breadth of solutions the Tolven technology can support to serve their needs.
The Tolven Platform
The Tolven Platform takes advantage of a broad, flexible, and open source architecture that gives healthcare and life sciences professionals as well as patients the information they need in an open and extensible solution. The Tolven Platform and applications have global applicability.