(Personal profiles for both are posted at:http://www.tolvenhealth.com/leadership.html

Agenda

Over the next few days, they will attempt to show more than one implementation of Tolven. They willprovide a functional overview including discussions of the data generator.

Tour of Tolven

A core principle is, in Tolven, the term “account” is used to refer to a logical group of users. Anaccount might be patients, hospital workers, researchers, etc.All users in an account work off thesame platform, information model, and vocabularies. When a user logs in, they have to specify what“account” they are acting on behalf of.

In Tolven, the information is generally assumed to beintended toshare.

Discussion of Transcend. Information is de-identified for Transcend.

However, the selected modelmade everything look

like a patient (rather than a “subject”), which was troublesome for some.

Transcend has very complex work flows and“ICD-9 procedures”.

A demo was then given to show how to customize the tabs that appear at the top of each web page.They showed how to arrange, rename, alter the default tabs, and create new tabs with new content. Allof this can be done by an administrative user through the UI. They don’t allow non-admin end usersto alter some things, (like change the tab name from “patient” to “people” since that makes fordifficult support calls over the phone).

Below

isa display that shows this:

2

Their lists are configurable too. You can alter what columns display oryou canadd new columns.

Data from the demo comes from the “patient data generator”. You can go to their web site and createyour own account andcreate your own patients–

to filter and graph on the fly. For example, if you click on the Observationstab:

Notice the “Graph” button here. If you click on it, you can select what to graph:

3

And the hit “Graph”…

Tom

gave a demo of how to drag portlets

from one location on the web page to another,

and how toget rid of portlets (standard portlet behavior) on the Overview display:

4

The Problems, Results, and Observations portlets above can be dragged around, minimized, or you canclick on the arrow down button to configure how many items appear in each list:

Tom gave a demo of how to configure the number of items in a list.

There is an administrator who controls the screens, roles, and users for each account.

Click on:

To see this:

Side note: It’s good to be able to track if different test lab results were gathered from different labs.Apparently some labs give consistently higher or lower values that other labs.

5

Tom

gave a demo of how their “filter” capability can be applied to various fields in the list.Byclicking on the “New” button (below) the list can be configured to filter on physicians or nurses:

TRIM and Data Types

Tom

explained how Kaiser &

SNOMED terminology have been downloaded to the demo. He thenshowed how a new diagnosis from SNOMED can be added for a given patient.

Then he showed thefeature of many demo Tolven displays where the XML for the display’s object can be viewed:

Notice the “Show/Hide” at the bottom of this display.

6

If you click on this link, the display opens up toreveal

theinternal“TRIM” (stands for TemplateReference Implementation Model), which is a key Tolven concept:

Note this Show/Hide option disappearsat the end client site. It’s for debugging and testing.

A question was asked about where error handling occurs–

in the client user interface or inservlets.Answer: Both. The preference is to check as much as possible in the client user interface, andeverythingelse is checked on the backend.

The menus on web pagefrequentlyopen up dynamically torevealnew options (lots of AJAX).

Side note: Fuzzy dates are accepted in Tolven

(seehttp://www.lunaimaging.com/support/4_0/inscribe/idh_fuzzydate.htm

for a quick example of variousfuzzy dates). Exact dates are not always known

and people differ on how they enter date information.

Side note: SNOMED may provide a definition of an allergy, but in HL7, it’s the allergy + the reactionthat constitutes the definition of an allergy.

In Tolven, they try to offer digitizable choices rather than free-form text fields (althoughfree form textfields

are sometimes unavoidable).

Todd asked about the UCOM units variables

(TBD–

I don’t know what UCOM is, but I know unitsare very important with interoperability), and if they are configurable. (For example, are you lockedinto lbs if you want kgs?) Answer: units are configurable for some fields, but not all fields.

Below isan example of configurable units:

7

John then provided a demo that showed how, in TRIM, both the schema for an object and the valuesfor that object are contained within the same XML. He provided an example of some TRIM XML thatcontains both WeightValueSet and WeightValue blocks.

Here’s the weight value set:

<observation>

<value>

<valueSet>weightValue</valueSet>

<PQ>

<label>Weight in pounds</label>

<value>182.0</value>

<unit>lb</unit>

</PQ>

</value>

</observation>

Here’sthe weightvalue:

8

<valueSet name="weightValue">

<PQ>

<label>Weight in pounds</label>

<value>0.0</value>

<unit>lb</unit>

</PQ>

<PQ>

<label>Weight in kg</label>

<value>0.0</value>

<unit>kg</unit>

</PQ>

<null type="NA">

<label>Unable to obtain</label>

</null>

</valueSet>

(Note the

“PQ” tagin the XMLis HL7.)

This is the difference between a “Trim Instance” and “Trim”. ATrim message contains both the Triminstance and the template at the same time.

Much more on this at:http://www.tolven.org/architecture/briefs/templates.html

Question: why didn’t they use XML schemas? Answer to evolve over next few hours.

Note thetemplate

defines the expected structure and default values while theinstance

shows thosefields filled in

with real values.

At any point in Tolven, you can link a transaction to an“encounter”

–

typically when the

patient camein and met someone on the medical staff. However, exactly what constitutes an “encounter” isconfigurable by the particular end customer.

John then demos another instance of Tolven–

Transcend, which is not on the public network.“Transcend is the platform for the ISPY2 trial.”

In Tolven, as users work on activities, they don’t loose their work in progress. If they get interrupted,they can go to a different task, then return later to the work they had to push on the stack.(Postmeeting note–

I notice even when you log out you might still be returned to a display where you werein the process of some work.)

In Tolven, if information is ever copied from one “account” (aset of users) to another account, theinformation is de-identified and copied (not referenced but copied). This was to address securityissues. Also, there is a clear audit trail of who sent what and when.

Note there is “optionality” onboth the send and receive operations. That is, the

sender has to agree to send the information and thereceiver has to agree to receive it.

9

John remarked on the size of one of the TRIM structures (in Transcend? I can’t recall anymore).Recall that at the top of many displays you can see the flow–

from

the procedure, to the surgery, tolymph nodes, then histology, receptors,staging, etc. For example:

Apparently all of the information across that entire flow was captured in a single gigantic TRIM

the asynchronous update capability. He submitted a change, then we waited a fewmoments and the screen updated by itself.

Sometimes the displays provide you information on whenthe next update will occur:

Johndemo’ed

the concept of signing and submitting

forms. Some displays used to manageparticularly sensitive or important information require the end user to re-enter their password prior tosubmission as a sort of “are you sure?” check, as well as an auditing mechanism.

Johndemo’ed

a plan pulled off SNOMED. Thevisibleterms on the display were SNOMED, but anICD-9 model is used internally.

** Break **

Glenn asked if Tolven is an EHR or an EMR. Answer: both. It’s really an EMR that knows how totalk to remote systems in a common vocabulary, so it’s also an EHR.

Tolven Semantic Wiki

The Tolven Semantic Wiki (TSW) was thendemo’ed

(http://wiki.tolven.org/doc/index.php/Main_Page). The semantic wiki is important to understand. Thesemantic wiki creates TRIM XML for you. It can, for example, take SNOMED information and createan HL7 RIM structure and package that up as a TRIM (I think). They support CDASH, RIM,SNOMED, and HL7 data types.

10

There are actually multiple TSWs. Why? Some of the data standards are proprietary. For example,SNOMED is licensed so you can just post the content on the web. So access to the TSW that hasSNOMED is restricted.

John showed how you can query the TSW by text string. He typed in “craniotomy” and the wikireturned a section that showed 1) facts about a craniotomy, 2) the subtypes associated with it, and 3)the TRIM XML. He noted how, within the TRIM, you could see RIM terminology–

the approachtype, the method code, the approach site code, etc. It turns out, anything in SNOMED will fit inot anHL7 RIM!

[TBD

–

What is the URL for this page?]

Below is a truncated excerpt from the page:

You can learn more about the semantic wiki at:https://docs.google.com/viewer?url=http://tolven.org/architecture/TolvenSemanticWikiOverview.pdf&embedded=true&chrome=true

The wiki can perform ICD-9 and ICD-10 mapping. Note, however, that SNOMED is more granular.Rather than merely “appendicitis”, SNOMED might have “appendicitis atypical”.

Johndemo’ed

the wireframe capability in Tolven–

how to preview the structure of displays.

TBD–

Ihave no recollection of what this was anymore. Sorry!-gh

11

Tomdemo’ed

a constrained attribute set. A data standard may define hundreds of lymph nodelocations in the human body–

they are all over us. However, when it comes to sentinel lymph nodebiopsies for breast cancer, oncologists really only care about 4 groups of them (axillary, ?, ?, and ?)So you don’t want to get alist of 100 items.

John pointed out how HL7 RIM and SNOMED really have different objectives, which is why they canget away with combining them both into a TRIM. HL7 RIM is more about structure and relationships–

authors of documents, timestamps, etc.SNOMED (and other standards) are more about defining thefields in, say, a patient. There’s no dates. There’s a few relationships but not as many.

John returned to the question about why they don’t use schemas.

He stated there are about 2200 xsdsdefined by the HL7 RIM standard, none of which are all that useful without some modification. Theywould have to implement 2200 interfaces. However, some of those interfaces would need flexibilityin the data types they received (for example, some would wantto receive kilograms instead ofpounds). So if Tolven used xsds, they’d end up with 500,000 service calls. That’s too many so theyneeded a more flexible approach–

TRIMs.

John noted Tolven is in the process of further enhancing TRIMs. They are addingin the ability tospecify state changes within TRIM. He showed some XML that had some “from State” and “to State”tags, but I didn’t catch it.

The Tiers of Tolven

John referred us tohttp://tolven.org/doc/tutorial, which, he said, is really just a compilation of hisvarious notes.

For this discussion, he clicked on “Tiers” on the left hand side of the following page:

12

Tolven is anopen source

application–

at least, as much as possible.

For their referenceimplementations, theytry to have

at least 2 implementations for each layer in

the stack-

Oracle andPostgre, for example, for the database. Or OpenLDAP, OpenDS, or Microsoft Active Directory forthe LDAP server. For the Object Relational Mapping (“ORM” in the diagram above), you can useHybernate, Toplink, or EclipseLink). TheEJB’s can run in JBoss or GlassFish.

There generally isn’t any Tolven source code for the lower layers. They really start coding at the EJBlevel and above.

Their sessionbeans provide their core behavior. They are all stateless, and never stateful. Never. Allstate is stored in the database. This approach allows them to load balance at will (at the app server andhttp server level).John provided some discussion of good benchmark scores, which are posted ontheir web site.

Some clinical laboratories process 250,000 results per day. They’ve benchmarked36,000 user sessions per hour (John was unsure how many transactions that equates too).

Tolven is very asynchronous.

Actions and events are always queued up. They use message drivenbeans and JMS. Their queues are all persistent, and great care has been given to guard for message13

loss. For JBoss, they use JBoss Messaging and not JBossMQ. GlassFish also comes with embeddedqueue support.

John noted that messages arrive as HL7/CCR/TRIM. However, the format of those messages is reallyunimportant. (We’ll find out later that’s because the message is unpacked into an internal formatcalled “placeholders”.)

Nothing in

the upper tiers makes any direct calls to the lower tiers below the session bean level.

On the Layers diagram, the term “mobile” is used to refer to smart phone applications.

SOA layer is implemented with session beans. John noted they are struggling to avoid remotemethod invocations (rather than SOA), but they have a demand forRMI

too, so it has beenadded tothe diagram. But really the normal flow into Tolven is throughasynchronousqueued messages.

Sidebar on CCR–

the Continuity of Care Record. It’s based on the Continuity of Care Document(CCD).

TheoriginalHL7/CCR is storedin Tolven in an encrypted

format–

more on that later.

Note that Tolven stores BOTH the exact image of the message it received, but also the unpackedinternal representation of it.

Most messages are Tolven are stored twice.

Translating Message Types

After Tolven receivesa message, it has a number

of plugins that know how to process that messageinto an internal “placeholder” format:



ProcessCCR



ProcessCDA



ProcessTRIM



ProcessCCD



Etc.

HOWEVER, John wanted to be clear that Tolven is NOT intended to be an integration enginelikeMIRTH

(seehttp://www.mirthcorp.com/community/overview). At Tolven sites, it’s very common tofind MIRTH sitting in front of the Tolven message queue translating any message it receives into

HL7/CCR before passing that message on to the Tolven message driven bean.

** Lunch **

Configurability

John then clicked on the “Configurability” link off the tutorial web site:

14

There are many ways to change Tolven, but the majority of them are through configuration (theyellow). Note that web page changes are only a matter of changing XML! (This is the blue above.)For core behaviors changes, programming is required, but not very often.

Apparently the various components in Tolven have checks to ensure the component sending themmessages is authorized to do so. The check is both ways–

they check each other.

An “account user”(a Tolven display) is used to tie

a particular user to a particular account.

John gave demo of how to override menu names and how to change the order of fields in lists.Go toapplication->preferences and click oncustomizemenus:

15

The Customize Menus page is shown below:

Note the list items in blue on the left are really stored in MenuData/TRIM. That is, there’s nothingbuilt in to Tolven about “patients”, or “allergies” or anything else in that list. There is no “patient”object–

it’s all configurable.

Clicking on “accountList” yields:

16

From here you can click “extract data” and get to a display that will allow you to download the XML.The XML for allergies looks like:

<?xml version="1.0" encoding="UTF-8"?>

-

<results path="echr:allergies"

account="2754041"

database="2.16.840.1.113883.3.75"

timestamp="2010-10-15T12:20:09.077-07:00"

offset="0"

limit="0"

count="0">

<fields>id,allergy,documentId,path</fields>

</results>

John talked about this XML some, but I didn’t quite catch it.

In Tolven, you will often encounter the term “Menu Data”. That doesn’t really have anything to dowith menus (anymore). The term should notbe interpreted as a reference to some GUI component.17

It’s just data. Menu Data objects are really just “placeholders” that exist half way between TRIM andthe GUI.

Johndemo’ed

Application-> Preferences-> Account Users:

Here you can specify which users are associated with which other users:

Note that TRIM carries extra fields within it thatdon’t exist in the information model. They are justfields to support the displays. For example, a display might provide a checkbox that asks “do youhave additional weight details to provide for this patient?” If the user selects “yes”, then the displayopens up (AJAX) to reveal a number

of additional questions that can then be asked.Since the TRIMis used to construct the screen, in this example the TRIM carries a “weight details” tag within it that isused solely to support the displays andare never used in any algorithms or sent outside of Tolven.

Tolven business rules can be written in JBoss Rules (a.k.a. DROOLS

–

seehttp://www.jboss.org/drools).

The XHTML box in theConfigurabilitydiagram refers to the ability to override the defaultlook andfeel of Tolven, or other formats (likeif

first name comes first, or last name comes first, or if it’s M/For Male/Female, etc.)

The

box

labeled “WS/RMI/JMS” in the Configurability diagram

shows

you can add your owninterfaces.

In Tolven, you’re

not really supposed to alter the database schema. You can add to it, or decide not touse parts, but don’t alter the semantics of the database by altering its schema. Use metadata instead.In Tolven, you generally don’t add new tables for objects like“patients”. Instead, you use metadata18

fields inside of existing tables. Those fields say “this record is a patient” or “this record is a diseasedescription”.

But there is not “patient” or “disease” table.

Moreover, you probably won’t have to modify the Tolven code itself either. The screens are builtfrom the TRIM. Tom pointed out that theskeptisims that they commonly receive from architects anddevelopers about the lack of the need for customizing the code tends to revolve around objections like:

“but what if we get a new diagnosis, or a new procedure, or some other new object?”

Tom’s response:in Tolven, that’s all vocabulary driven. Youusuallydon’t change the code to add support for newobjects or activities.

The Plugin Framework

Discussion ofhttp://tolven.org/download:

19

Tolven uses plugins

(seen above, starting with org.tolven.analysis)

not only to configure itself, but toactually make itself. The entire thing is made out of plugins. If you look through the packagesavailable on this web site, the ones with “assemblers” embedded in the name pertain to assembling theapplication.

Note the plugins are not jar files (even though the naming convention looks like it). Theyare actually

zip files. What do they contain? That depends on the layer you are deploying to. Forexample, if you are downloading a plugin that pertains to servlets, it might have jar or war files in it.But if you are downloading a plugin that pertains to the desktop, it might have browser pluginscontains within it. It just depends.

They have a program that knows how to put these plugins together. That program is only about 1 mband you could argue that that program is the only true “core” component of Tolven.

John then showed/discussed Plugins.xml–

and focused on the line “repository library URL”.Can’tquite recall details on this anymore.

Tolven Models

Then there was discussion about the Tolven UML models that are posted (seehttp://tolven.org/architecture/model/index.html):

Object Model:The object model for Tolven is the HL7 RIM. Sort of. They “don’t really have asingle model.However,HL7 RIMtends to be

the target for semantic normalization.”

Most data in Tolven is stored twice–

once in it’s original form (the original XML received), and oncein normalized form (an easy-to-recognize format–

with objects like “patient”). The source of theexternalinformation could have been TRIM, RIM, CDA, etc.–

who caresonce you’re inside ofTolven(from an internal perspective).

Doc Flow Slide

John then went on to explain the doc flow slide (that is, click on “Doc flow” off the tutorial web page):

However, he prefers to just drawthis diagramup on the chalk board piece by piece, so that’s what hedid.

The flow begins this way:

21

Eitherthe world or the Tolven UI creates a TRIM message. That then gets marshaled into a Tolvenmessage (the TRIM iswrappedas an XML attachment), and is placed on the queue for processing.The Tolven “MDB Evaluator” empties the messages on the queue, and sends them to the “dispatcher”one at a time.The dispatcher then interprets the table using one of several plugins–

the CDAprocessor, the TRIM processor, the CCR processor, the HL7 version X message processor, etc. Oncethe

dispatcherunderstands

the format of the message, itimmediately stores the message in its originalformat in three parts:

1) the original document in encrypted format in the database

–

in a document table,

2) the signature indicating who sent the message–

in a signature table, and

3) any attachments are sent to the attachment table.

Note each of the processors(CDA, TRIM, CCR, etc.)may store the message again. Each calls amessage parser–

almost alwaysimplemented ineither JAXP or JAXB. Each of the processors createsobjects like “patient” with attributes that

you would intuitively expect. The understandableobjectsarecalled “placeholders”

in Tolven.

The dispatcher determines “who’s

interested in this message?” and sends the message to thesubscribers.

John went into the details of JAXB processing for a moment. Java Expression Language (or Java EL)is used by JAXB to interpret strings like this: <From>#{TRIM.ROLE.Person.name[Family]}, whichreally means take the family name (the person’s last name) out of the trim andput it in the Fromvariable. Note that JAXB will generate Java classes, which JAXP does not do. JAXP uses XPathinstead, so the strings look like this: <From>#{CDA[“patient/Name”}</From>

Note that placeholders can storestate. Theoriginaltransactions

written to the database, on the otherhand, only represent snapshots in time.

Placeholder Lists

Tolven uses DROOLS (which, in turn uses a language called OPS-5) to process strings like“echr:patients:all” to create indexed lists of references to patients, which are then stored to disk.

You can frequently see such strings in the Tolven UI (I’m not sure if they would be there for aproduction release). For example, in the following display:

22

Visible at the very bottom of the image above is a javascript

line that includes the string“echr:activity:all”.

Tolven processes strings like this all the time to continually repopulate tables that are used for verycommon queries (like “show me all my patients for today”, orperhaps more specific to a particular

oncologist:“give me a list of all female patients over the age of 40 with no mammograms in the lastyear”).

There’s a technique called “placeholder touching” that forces repopulation of a subset of placeholderlists.

23

Submit

Pressing the “submit” button in Tolven is a big deal. Here’s what happens before and after hittingsubmit:

BEFORE submit is hit: lightweight validations routines are performed (largely on the browser)–

Ithink John said these were referred to as “computes”. The computes are often implemented in Java, orare purchased expert knowledge services (for example, the FDB drug data bank, which might be usedto check for drug interactions, proper dosage ranges, etc.)

AFTER submit is hit: JBoss Rules (Drools) are executed, lists and placeholders are updated, andoutbound messages are sent. After the submit button is pressed, the TRIM can no longer be updated(for security and auditing reasons).

Recall the discussion earlier about the 2200 xsd files in HL7 RIM (see above). The same problem ofan ever-expanding set of XSDs also applies to tables. Why not have a patient, allergy, organization,etc. table? The answer is there would be just too manytables.

In Tolven, all logical “tables” end up in a single physical table called “menudata” (recall the word“menu” in Tolven does not refer to UI components). You create a new table by defining new metadata.In Tolven, you can add

metadata on the fly.So you can actually create support for allergies orimmunizations, for example, at run time, without having the bring the system down for a softwareupgrade.

Note that

every account (group of users) can have their own metadata too. So different groups of userscan havediffering models.

What does the menudata table look like? It has:



an ID



an

“MS” field (short for menustructure–

this is the field that says what the record is–

an allergy, apatient, a disease, etc.)



a “parent” field (that really acts as a foreign key)



A number of other key fields (note–

a limited number of them though)

24



Etc.

Tolven, out of the box, defines some stock root structures in menudata including: