TolvenTraining_2010_10_11x

hushedsnailInternet and Web Development

Nov 12, 2013 (3 years and 9 months ago)

420 views

1



Meeting Notes

Date / Time

/
Location

October 11
, 2010

Meeting Purpose

Tolven Training Class


Glenn’s notes

(translation


might be

dead

wrong here and there)

Attendees

Multiple members of project team
, Tom Jones, John Churin


Teachers


Tom Jones


Tolven Chief Medical Officer, co
-
founder

John Churin


Tolven CTO.


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

Agenda


Over the next few days, they wi
ll attempt to show more than one implementation of Tolven. They will
provide 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
. An
account might be patients, hospital workers, researchers
, etc.
All users in an account work off the
same platform, information model, and vocabularies. When a user logs in, they have to specify what
“account” they are acting on behalf of.


In Tolve
n, the information is generally assumed to be
intended to
s
hare
.


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

However, the selected model
made everything look

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

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 c
ontent. All
of this can be done by an administrative user through the UI. They don’t allow non
-
admin end users
to alter some things, (like change the tab name from “patient” to “people” since that makes for
difficult support calls over the phone).

Below

is
a display that shows this:


2




Their lists are configurable too. You can alter what columns display or
you can
add new columns.


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


the data generator does that for.

Go to
http://demo.tolven.org
.
See other notes in my StagingInTolvenDemo.docx file, which shows screen
captures with step
-
by
-
step instructions.


Tom

gave a

demo of how

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



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 to
get 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 can
click on the arrow do
wn 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 no
te: 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 f
ields in the list.
By
clicking 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 then
showed how a new diagnosis from SNOMED can be added for a given patient.

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




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


6


If you click on this link, the display opens up to
rev
eal

the
internal
“TRIM” (stands for Template
Reference Implementation Model), which is a key Tolven concept:




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


A question was asked about where error handling occurs


in th
e client user interface or in
servlet
s
.
Answer: Both. The preference is to check as much as possible in the client user interface, and
everything
else is checked on the backend
.


The menus on web page
frequently
open up dynamically to
reveal
new options (lots of AJAX).


Side note: Fuzzy date
s are accepted in Tolven

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

for a quick example of various
fuzzy 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 reaction
that constitutes the definition of an allergy.


In Tolven, they try to offer digitizable choices r
ather than free
-
form text fields (although
free form text
fields

are sometimes unavoidable).


Todd asked about the UCOM units variables

(TBD


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

Below is
an example of configurable units:

7




John then provided a demo that showed how, in TRIM, both the schema for an obje
ct and the values
for that object are contained within the same XML. He provided an example of some TRIM XML that
contains 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’s
the 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</v
alue>


<unit>kg</unit>


</PQ>


<null type="NA">


<label>Unable to obtain</label>


</null>


</valueSet>


(
Note the

“PQ” tag
in the XML
is HL7.)


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


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


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


Note the
template

defines the expected structure and default values while the
instance

shows those
fields filled in

with real values
.


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



typically when the

patient came
in and met someone on the medical staff
. However, exactly what constitutes an “encounter” is
configurable by the particular end customer.


John then demos another instance of Tolven


Transcend, which is not o
n 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 p
ush on the stack.
(Post
meeting note


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


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

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

sender has to agree to send the information and the
receiver 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, to
lymph n
odes, then histology, receptors,
staging
, etc. For example:



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

that
had all of this stuff in it


procedures, specim
ens, lymph nodes, histo
lo
gy, etc
.
(
That
may have been
a
questionable design decision.
)


John
demo’ed

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

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




John
demo’ed

the concept of signing and submitting

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


John
demo’ed

a plan pulled off SNOMED. The
visible
terms on the display were SNOMED, but an
ICD
-
9 model is used internally.


** Break **


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

Tolven Semantic Wiki


The Tolven Semantic Wiki (TSW) was then
demo’ed

(
http://wiki.tolven.org/doc/index.php/Main_Page
)
. The semantic wiki is important to understand. The
semantic wiki creates TRIM XML for you. It can, for example, take SNOMED information and crea
te
an 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 po
st the content on the web. So access to the TSW that has
SNOMED is restricted.


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


the approach
type, the method code, the approach site code, etc. It turns out, anything in SN
OMED will fit inot an
HL7 RIM!

[
TBD



What is the URL for th
is 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 hav
e “appendicitis atypical”.


John
demo’ed

the wireframe capability in Tolven


how to preview the structure of displays.

TBD


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

11



Tom
demo’ed

a constrained attribute set. A data standard may defin
e hundreds of lymph node
locations in the human body


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


John pointed out how HL7 RIM and SNOMED really have different objectives, which is why they can
get 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 the
fields 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 xsds
defin
ed by the HL7 RIM standard, none of which are all that useful without some modification. They
would have to implement 2200 interfaces. However, some of those interfaces would need flexibility
in the data types they received (for example, some would want
to receive kilograms instead of
pounds). So if Tolven used xsds, they’d end up with 500,000 service calls. That’s too many so they
needed a more flexible approach


TRIMs.


John noted Tolven is in the process of further enhancing TRIMs. They are adding
in the ability to
specify 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 to
http://tolven.org/doc/tu
torial
, which, he said, is really just a compilation of his
various notes.

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


12




Tolven is an
open source

application


at least, as much as possible.

For their referen
ce
implementations, they
try to have

at least 2 implementations for each layer in

the stack
-

Oracle and
Postgre
, for example, for the database. Or OpenLDAP, OpenDS, or Microsoft Active Directory for
the LDAP server. For the Object Relational Mapping (

ORM
” in the diagram above
), you can use
Hybernate, Toplink, or Ec
lipse
Link). The
EJB’s can run in JBoss or GlassF
ish.


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


Their session
beans provide their core behavior. They are all stateless, and never stateful. Never. All
state is stored in the database. This approach allows them to load balance at will (at the app server and
http server level).
John provided s
ome discussion of go
od benchmark scores, which are posted on
their web site.

Some clinical laboratories process 250,000 results per day. They’ve benchmarked
36,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 driven
beans and JMS. Their queues are all persistent, and great care has been given to guard for message
13


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


John noted that messages arrive as HL7/CCR/TRIM. However, the format of those messages is really
unimportant. (We’ll find out later that’s because the message is unpacked into an internal format
called “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.

“CM” refers to
their “configuration manager”, AE = their “application editor”.


Agenda for this week


to add a session bean and an entity bean.


Their

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

too
, so it has been
added to
the diagram
. But really the normal flow into Tolven is through
asynchronous
queued messages.


Sidebar on CCR


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

The
original
HL7/CCR is stored
in Tolven in an e
n
crypted

format


more on that later
.


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

Most messages are Tolven are stored twice.

Translating Message Types

After Tolven rece
ives
a message, it has a number

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




ProcessCCR



ProcessCDA



ProcessTRIM



ProcessCCD



Etc.


HOWEVER, John wanted to be clear that Tolven is NOT intended to be an integration engine
like
MIRTH

(see
http://www.mirthcorp.com/community/overview
)
. At Tolven sites, it’s very common to
find 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 **


Configu
rability

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 throug
h configuration (the
yellow). 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.


In diagram, TZ = Timezone


Defaults are determined from the
top down


that is, user settings override account settings, which
override site settings.


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


they check e
ach 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 to
application
-
>preferences and click on
customize
menus
:


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 nothing
built in to Tolven about “patients”, or “allergies” or anything else in that list. There is no “p
atient”
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 do
with menus (anymore). The term should not
be 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 and
the GUI.


John
demo’ed

Applicatio
n
-
> Preferences
-
> Account Users:




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




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

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


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



see
http://www.jboss.org/drools
).


The XHTML box in the
Configurability
diagram refers to the ability to override the default
look and
feel of Tolven, or other formats (like
if

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


The

box

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

show
s

you can add your own
interfaces.


In Tolven, you’re

not really supposed to alter the database schema. You can add to it, or decide not to
use 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 metadata
18


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

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


Moreover, you probably won’t have to modify th
e Tolven code itself either. The screens are built
from the TRIM. Tom pointed out that the
skeptisims that they commonly receive from architects and
developers 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 proc
edure, or some other new object?”

Tom’s response:
in Tolven, that’s all vocabulary driven. You
usually
don’t change the code to add support for new
objects or activities.

The Plugin Framework


Discussion of
http://tolven.org/download
:




19


Tolven uses plugins

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

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

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

zip files. What do they contain? That depends on the layer you are deploying to. For
example, 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 des
ktop, it might have browser plugins
contains within it. It just depends.


They have a program that knows how to put these plugins together. That program is only about 1 mb
and 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’t
quite recall details on this anymore
.

Tolven Models


Then there was discussion about the To
lven UML models that are posted (see
http://tolven.org/architecture/model/index.html
):





20


Data Model:
The data model for Tolven is really the sum of three hyperlinks: app + core + doc

(see
above)
.


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

the target for semantic normalization.”


Most data in Tolven is stored twice


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


with objects like “patient”). The source of the
external
information could have been TRIM, RIM, CDA, etc.


who cares
once you’re inside of
Tolven
(from an internal perspective).


Doc Flow Sli
de


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




However, he prefers to just draw
this diagram
up on the chalk board piece by piece
, so that’s what he
did
.


The flow begins this way:


21


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


the CDA
processor, the TRIM processor, the CCR processor, the HL7 version X message processor, etc. Once
the

dispatcher
understand
s

the for
mat of the message, it
immediately stores the message in its original
format 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 signa
ture 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 a
message parser


almost always
implemented in
either JAXP or JAXB. Each of the processors creates
objec
ts like “patient” with attributes that

you would intuitively expect. The understandable
objects
are
called “placeholders”

in Tolven
.


The dispatcher determines “who’s

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


John went into t
he 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]}, which
really means take the family name (the person’s last name) out of the trim and
put it in the From
variable. Note that JAXB will generate Java classes, which JAXP does not do
. JAXP uses XPath
instead, so the strings look like this: <From>#{CDA[“patient/Name”}</From>


Note that placeholders can store
state
. The
original
transactions

written to the database, on the other
hand, 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 a
production 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 very
common queries (like “show me all my patients for today”, or
perhaps more specific to a particular

oncologist:
“give me a list of all female patients over the age of 40 with no m
ammograms in the last
year
”).


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


23


Submit


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


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


I
think John said these were referred to as “computes”. The computes are ofte
n implemented in Java, or
are purchased expert knowledge services (for example, the FDB drug data bank, which might be used
to check for drug interactions, proper dosage ranges, etc.)


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


Tolven uses
an internal table
called MenuData Version

to track these lists. It looks like thi
s
:


List

Version

Echr:patients:all

2


=

=
=
t桥渠n=獴⁩猠s桡湧e搬⁴桥⁶=牳楯渠湵浢敲⁩猠扵浰敤⁦牯洠獡y′⁴漠㌮

q桥牥⁩猠=a癡pc物灴渠癡物潵猠
摩獰day猠瑨慴⁣hec歳⁦潲⁴桥⁶=牳楯渠灥物潤楣a汬y=a湤⁲n
J
灥牦潲浳⁴桥楳琠煵敲y⁩映瑨=畭扥==c桡n来猠
楮牤i爠瑯re瀠瑨e⁩湦潲浡瑩潮渠m桥⁤楳灬ay⁣ur牥湴⸠
=
Key Concept


No Need to Create New Tables


Recall the discuss
ion earlier about the 2200 xsd files in HL7 RIM (see above). The same problem of
an 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 many
tables
.


In Tolv
en, 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 me
tadata.
In Tolven, you can add

metadata on the fly.
So y
ou can actua
lly create support for allergies or
immunizations, for example, at run time, without having the bring the system down for a software
upgrade.


Note that

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


What does the me
nudata table look like? It has:



an ID



a
n

“MS” field (short for menustructure


this is the field that says what the record is


an allergy, a
patient, 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:




Patient



Staff



Location



Provider



Others…



As described on:

https://docs.google.com/viewer?url=http://www.tolven.org/documents/ScopeoftheTolvenOpenSource
Solution.pdf&embe
dded=true&chrome=true