Using Tolven to Establish an Information Ecosystem

Introduction

The Tolven platform and application development framework have been developed to enable partners to establish robust healthcare information ecosystems that will allow all stakeholders in a broad healthcare environment to interact with one another in a seamless and secure way.

The information ecosystem will take advantage of all aspects of Tolven software, most notably:  Incorporation of electronic data input from all relevant systems  Processing of electronic data input formats to extract granular payloads of re-usable healthcare information (clinical, administrative and financial)  Creation of scalable relational data bases of analytical quality clinical information  Transmission of data from the data repository to other systems; the format for transmission can be either the original input format or a format that facilitates aggregation of data from a variety of inputs  JBoss Rules for ease of implementing alerts, notifications, transactional clinical decision support, and external communications  Robust account configurations that allow logical groups of users to view and create information relevant to their needs  Certified security, audit, and access control mechanisms (including role-based permissions)  Plug-in framework for ease of developing modules that can be introduced at any time for any particular set of requirements  API s for ease of development of and interaction with third party applications  Layered technology for ease of new application development that can continue to take advantage of underlying consistency of behaviors of healthcare information objects  Incorporation of vocabulary and information model standards for ease of extensibility into all domains of healthcare  Knowledge access architecture for ease of presentation of context-aware knowledge to any group of participants  De-identification services for creation of research data bases

Establishing the Ecosystem

In order for any clinical enterprise to effectively manage its business, it must manage an array of healthcare information that has traditionally been created in many locations (Figure 1).

Figure 1: Representative sources of healthcare information Using Tolven to Establish an Information Ecosystem

Of course, information is not easily shared when it resides in existing electronic (or paper) silos. Merely establishing “connectivity” between disparate systems is not sufficient. Transformation and consolidation of information from disparate sources facilitates information re-use, efficient decision making, and robust analytic activities. The consolidation of relevant healthcare information in a Tolven-based system will also allow an organization to provide specialized views of information to authorized groups of stakeholders without having to resort to inefficient “query-response” exercises. The Tolven ecosystem will be an overall standards-based environment in which each group of users can be comfortably and accurately represented

Data Flow in the Ecosystem

Rules will facilitate data flow into, through, and out of the ecosystem. The following diagram (Figure 2) illustrates, at a high-level, data flow in a Tolven-based health information ecosystem.

Figure 2: High level representation of data flow in the ecosystem

Page | 2 Company Confidential October 2013 Using Tolven to Establish an Information Ecosystem

Starting on the left and moving toward the right, data is accepted from external applications and immediately stored as a “document” exactly as it was received. Tolven then calls each one of the processors that have been configured for particular document types.

The processors that recognize the document format can then parse that document using a technique of their choice (many are in XML format, but that is not required). This processing enables semantic normalization because, at this point, the differences among different data sources sending in the same data can be resolved. For example, a serum glucose test result may come from one of many different sources such as independent clinical laboratories, hospitals, and even the patient. Without disturbing the source document, the processor creates what Tolven calls “placeholders” which is a catch-all term representing the various kinds of data objects used in healthcare: patient, problem, allergy, medication order, laboratory result, vital sign observation, etc.

Placeholders are instantiated in harmony with the HL7 Reference Information Model, a discipline that facilitates semantic interoperability. Key clinical information is thus redundantly stored in the ecosystem: once as the original document and then again as the placeholder. The link between placeholder and original document is always maintained to assure fidelity of context and provenance.

If a message is very simple, it may only create or update a single placeholder. Complex messages may affect many placeholders. For example, a lab result may affect only a single or small number of placeholders of a single type (lab result) whereas a CCD document may affect many placeholders of different types.

After semantic processing, all affected placeholders are subject to rule processing. In Tolven, rules are used to maintain “truth” by reasoning over patient data with the affected placeholders in context. For example, when a laboratory result is received and the rules determine that that claim should be place on a list of new results for a particular patient, then Tolven will add the item to the list of laboratory results for that patient which can then be reviewed by authorized personnel in the appropriate account. All rules are stated in the positive so that if a rule does not support an item being on such a list, then it will automatically be removed from that list. This style is called truth maintenance. Rules can be, and usually are, added to specific accounts in order to implement desired user interface and decision support behavior in that account.

Rule consequences are not limited to the creation of lists. Outbound messages, such as for other EMRs, case management systems and utilization review systems, can also be triggered by rules. This allows for multiple approaches to integration with other systems. For example, data can be written to non-Tolven tables or to completely different databases.

Some external applications may only send data into the ecosystem (such as “Application a” above); other external applications (such as “Application d” above) may only be recipients of data from the ecosystem.

The lower section of the diagram shows how data from applications developed on the Tolven framework submit data to the ecosystem. All data from Tolven-based applications is formatted in an xml structure call a TRIM (Templated Reference Information Model). TRIMS are taken in and processed by the ecosystem in exactly the same way as messages from external systems.

Representing Groups of Users

Within the ecosystem, many groups of users, organized into logical accounts (Figure 3), will use data viewing applications. In addition, developers will utilize Tolven to develop data entry applications that also will be used by members of logical accounts, each of which will have its own packages of rules while, at the same time, sharing an overarching standards- based clinical information system.

Figure 3: Accounts for groups of users in the ecosystem

Each individual user will have his/her own identity in the implementation, and each individual user can be a member of more than one account. Separation between accounts is essential for preserving privacy and is also essential for documenting when and what information is shared between accounts. Sharing information between accounts (Figure 4) takes place through explicit “copy,” “send,” “acknowledge,” and “receive” actions. All such actions documented in an “audit trail.”

Figure 4: Sharing information between accounts via Tolven “copy” functions

As we have already seen, the ecosystem will be able to be integrated with outside applications (non-Tolven systems) in a variety of ways, including standard and non-standard messaging and APIs. Information created in outside systems will be conveyed to the ecosystem and distributed to appropriate accounts for further action (Figure 5).

Figure 5: Integrating information from applications outside of the ecosystem

Developing New Applications

As the system matures, the need for additional applications to support particular clinical domains has been anticipated. Such applications (Figure 6) can be developed for use in the established ecosystem, through use of the Tolven plug-in framework.

Figure 6: New application development using Tolven technology

In all cases, modules developed for various groups of users in various domains can take advantage of a universe of common healthcare information objects and work flows that have already been established by Tolven.

Taking the First Steps: Example 1 (Consolidate electronic record for clinicians)

In the initial steps of the implementation, information about authorized users will be loaded into the system (Figure 7). User information can be programmatically transmitted from an existing directory (top entry point) or it can be entered via existing Tolven application modules (lower entry point). The enterprise will establish the information requirements for various categories of users (specified demographics, etc). Such information will provide the foundation for a user directory.

Figure 7: Initial load of user information

End users are organized into logical accounts that are synchronized with clinical responsibilities for care groups. Within the ecosystem, patient records begin to be created by either importing of demographic information from outside systems or by use of existing Tolven application modules to enter demographic data in compliance with government standards (Figure 8).

Figure 8: Creating patient records

Clinical information will be pushed from various systems in the enterprise, usually via HL7 messages. Summarized clinical information can also be imported from other clinical enterprises, usually via CCD, into the ecosystem where it will be appropriately processed (Figure 9). In addition, clinical staff will use current Tolven 2.1 application functionality to add critical clinical information to the patient records. All information is retained in the data repository of the ecosystem. Rules enable presentation of this new information to appropriately authorized members of the clinician accounts.

Figure 9: Taking in, storing, processing, and displaying information

Rules can facilitate the transmission of clinical information to outside systems such as those maintained by public health entities or by other government agencies. While rules determine the appropriate outside system “targets” for clinical information, clinicians can also explicitly designate targets for receipt of information within the parameter established by patient consent. The outside EMR “targets” will be available in a directory maintained in the ecosystem (Figure 10). All transmissions of information are audited, and the audit trail is visible to any authorized member of the account that is sending or receiving such information. The outbound CCD (which complies with standards for data format and data content) aggregates information that has accumulated in the patient record from all sources. Careful programming allows for preservation of provenance for transmitted data.

Figure 10: Transmitting information to outside applications

Facilitating Clinical Research

With patient consent, information held in the clinical enterprise data base can be de-identified and stored in a separate research database with viewing access provided to authorized users through Tolven-based applications in Tolven style accounts (Figure 11)

Figure 11: Organizing information for clinical research

Taking the First Steps: Example 2 (PHR-centered Health Information Exchange)

While Tolven software can be used to establish traditional clinical data repositories as well as to support health information exchange systems controlled by clinical provider organizations, some partners have been exploring how to use Tolven to implement patient controlled health information systems, some of which are referred to as Health Record Banks. Because such exchanges are under the explicit control of patients, many of the stumbling blocks surrounding current heath information exchange constructions can be avoided. The approach to such systems re-uses nearly all of the application functionality that we have already discussed, so much of this will be familiar.

In the initial steps of the implementation, information about members in the targeted group(s) will be loaded into the system (Figure 12). The sponsoring enterprise for the HIE will establish the information requirements for members (specified demographics, etc). Such information will provide the foundation for a member record.

Figure 12: Initial load of member information

Within the ecosystem, PHR accounts will be created for members and authorized family members or “agents” (Figure 13).

Figure 13: Creating end user PHR accounts

Clinical information will be pushed from the medical care provider organizations to the ecosystem where it will be appropriately processed (Figure 14). All information is retained in the data repository of the ecosystem. Rules enable presentation of this new information to appropriately authorized members of the PHR accounts.

Figure 14: Taking in, storing, processing, and displaying information

The PHR application will also allow patients (and any other authorized member of a patient’s account) to enter key clinical information such as OTC medications, allergic reactions to drugs, etc.

While rules determine the appropriate PHR “targets” for clinical information, the patient will explicitly designate targets for receipt of information. We have thus introduced the term “patient control” rather than continue to reference “patient consent”. The EMR “targets” will be available in a directory maintained in the ecosystem (Figure 15). All transmissions of information are audited and the audit trail is visible by the any authorized member of the account sending or receiving such information. The outbound CCD aggregates information that has accumulated in the PHR from all sources.

Figure 15: Transmitting information to outside applications

Facilitating Clinical Research

With the exercise of patient control, information held in the HIE data base can be de-identified and stored in a separate research database with viewing access provided to authorized users through Tolven-based applications in Tolven-style accounts (Figure 16)

Figure 16: Organizing information for clinical research

Tolven Architecture

Tolven is assembled from many components, but it begins with a slender infrastructure framework (Figure 17). The Tolven technology framework has three primary components with others added for specific needs:

 The Tolven infrastructure  The database  One or more LDAP servers

Tolven has embedded security at every level of the infrastructure. Encryption, authentication, and authorization are common services to most aspects of Tolven. The Tolven Gatekeeper, provides user authentication, authorization, and single sign on. Transactions are processed reliably using RDBMS technology.

Figure 17: The Tolven healthcare framework

The Tolven Application Server is added to the infrastructure and contains a number of components including the Tolven Web Application and the HTTP-based APIs. All of these components make use of a common library of “backend” application behavior. Each component can be deployed to the same or different server hardware. All communication between Tolven components is TCP/IP in the standard configuration.

The Tolven plug-in architecture (Figure 18) allows maximal flexibility for application development by partners while preserving the Tolven core and allowing for easier maintenance and customization. Plug-ins facilitate easy updates and extensions of a Tolven-based solution. The Tolven plugin architecture allows partners (Tolven itself uses this same mechanism) to configure alternate and/or additional behavior into the system at all architectural levels. Plug-ins can be horizontal, such as database, LDAP and application server choices or vertical, such as adding additional types of clinical data. An installation of Tolven will have one or more “plug-in catalogs” from which to draw. The assembly process, with the aid of a configuration file, draws from these catalogs to construct a complete application server and related components. At runtime, core Tolven code and customer-specific code work side-by-side.

Tolven provides HL7 ANSI Data types and abstract HL7 Reference Information Model components in order to support virtually any type of healthcare application development.

Figure 18: Tolven healthcare application plug-in architecture

Tolven Architecture Layers

In order to guard against rigidity and the attendant inability to evolve, Tolven utilizes a technology stack that includes components that can be exchanged without either loss of function or loss of data.

Within the diagram seen below (Figure 19), we have made component choices for the current Tolven release. The diagram shows the layers in which those choices have been made. • Web browser – using Ajax • Web server – using JSF • Application server – JBoss or Glassfish • Database – PostgreSQL or Oracle • LDAP – OpenDS or OpenLDAP

Figure 19: Tolven’s component layers

Tolven Security

Tolven operates in a “security by design” environment with multiple layers. All documents, public keys and secret keys are protected (Figure 20).

Figure 20: Tolven approach to security

Performance

In Tolven, there are three main data flows affecting scalability (the ability to handle a specific workload): 1. Query transactions from the user interface 2. Message processing transactions 3. Analysis queries

The execution environment includes: 1. Tolven application server 2. Tolven database 3. Tolven authentication server (Tolven Gatekeeper) 4. Tolven's document store

A typical installation is likely to have additional software running as well which must also be considered when measuring scalability.

Within the first two years of Tolven’s development, benchmarking was conducted in partnership with Sun Systems. The published benchmark demonstrated scaling to millions of records with excellent user response times (200 simultaneous users) and affordable hardware. In more recent tests and with the availability of low-cost cloud computing, we have used Amazon EC2 servers for testing. Since Tolven does not sell hardware, and desires to remain hardware platform independent, the virtual computing environment allows us to dynamically expand or contract the resources utilized in a given test in a way that can be easily reproduced and translated to other computing environments - and at a relatively low cost. In our tests, a single thread executing on Amazon EC2 virtual environment was very close to a single thread running on a well-configured three-year-old desktop machine.

Performance (measure of elapsed time and resources used to accomplish a given task) and scalability (ability of a system to handle increased workloads) have always been critical considerations for Tolven. We can supply a more detailed white paper, if desired.

Summary

Tolven is able to work with partners and clients to establish a healthcare information ecosystem for that will meet needs for information storage, information transformation, information exchange and data analytics. The standards-based, rules enabled ecosystem will provide efficient data throughput, cost effective new application development, and real time patient stratification and case management functions that have been cumbersome to implement in other technologies.

Page | 24 Company Confidential October 2013