Brief Tolven overview with comments about security - Medsphere

flameluxuriantData Management

Dec 16, 2012 (4 years and 4 months ago)

237 views


Tolven White Paper

for the HRBA


1

Introduction


Managing information is key to managing any enterprise, including health care delivery systems.
In a recent study, a group at RAND has estimated that widespread adoption and effective use of
electronic medical records could result in a cost s
avings between 81 and 162 billion dollars a
year in the United States. In addition, use of effective health information technology (HIT) would
significantly reduce morbidity and mortality.
1



“Effective” health information technology requires standards.



High quality health care depends on complete and comprehensive patient medical
record information (PMRI). This information is essential to support diagnosis and
treatment, measure and improve quality of care, advance public health, enhance
healthcare produ
ctivity, and facilitate reimbursement. Today, however, patient medical
record information is primarily written, stored, and transported on paper. This paper
-
based information is often illegible, subject to delays, difficult to interpret, frequently
misplac
ed or lost, and contributes to unnecessary costs. While health care has adopted
information technology for financial and administrative systems, it has made limited
progress in utilizing information technology to support patient care. Today, the greatest
i
mpediment to the adoption of information technology is the lack of complete and
comprehensive standards for patient medical record information.”
2



To be widely deployed, HIT must be affordable. A recent estimate of the costs for widespread
HIT deployment
is jarring.



An expert panel estimated the existing and the expected prevalence in 5 years of critical
information technology functionalities. They then developed a model of an achievable
NHIN
(National Health Information Network)
by defining key provide
rs, functionalities,
and interoperability functions. By using these data and published cost estimates, the
authors determined the cost of achieving this model NHIN in 5 years given the current
state of information technology infrastructure. To achieve an N
HIN would cost $156
billion in capital investment over 5 years and $48 billion in annual operating costs.


3


Kaushal et al
, however,
chose to use as their costing model, a “brokered peer
-
to
-
peer
communication network” along the lines of the Santa Barbara
County Care Data Exchange

(which has now closed down)
. This places them squarely in the court of “federated” electronic
health record systems. The more cost
-
effective model is a “consolidated” system in which the
“…EHR is put together when it is created an
d updated, not when it is requested.”
4

The
consolidated model has important advantages which “…include much simpler access control
and security compared to federated systems and the likelihood of a much better

Tolven White Paper

for the HRBA


2

price/performance ratio.”
5

This “consolidated
” model is the one that has been endorsed by the
Health Record Banking Alliance.


Moreover, the authors did not attempt to factor in usage of open source software, but assumed
that the NHIN would evolve using traditional proprietary software, whether it co
nsisted of
commercial off
-
the
-
shelf (
COTS
)
or of purpose
-
built proprietary code.


“The potential advantages of open source software in health care are many. Anyone can
use or modify the software with few restrictions; the cost for customers is minimal
beca
use developers generally volunteer their time, and revenues derive from services
such as implementation and support rather than licensing, which means that care
providers are more likely to gain direct value. In addition, the fact that no single vendor
own
s the software gives providers more options, enables them to customize software for
their own particular needs, promotes public and foundation support of software
development, and ensures correct and timely implementation of standards, since there
are no p
roprietary limitations.”
6


Combining the use of open source, standards
-
based software with the principles articulated by
the Health Record
Banking Alliance (see Appendix
) should provide many opportunities for
communities to establish low cost highly funct
ional nodes in the National Healthcare Information
Infrastructure.




Standards and Interoperability


‘Semantic’ interoperability

provides common interpretability, i.e., information in the fields within
the message can be used in an intelligent manner. At

the highest level, semantic interoperability
takes advantage of both the structuring of the message and the codification of the data so that
the receiving computer can interpret the data.”
7

Tolven systems operate in an environment of
semantic interoperabi
lity in order to reach the full benefit
s of electronic health records
8
.

Using
HL7’s version 3

Reference Information Model (
RIM)
,
with standard terminology facilitates
c
reating a system

for persisting
semantically normalized
clinical information so that

con
sumer
s

can

efficiently and accurately

communicate with clinicians and receive information about
the
world of clinical care. The Tolven approach, which enables participation of
consumers

and
families in the creation an
d reading of EHRs, brings consumers

and

their families into the same
realm of semantic interoperability

that is recommended for clinical provider organizations
.



Tolven White Paper

for the HRBA


3

Because Tolven’s Electronic Health Solution is designed with comprehensive interoperability in
mind, it supports the seamless exchang
e and storage of clinical, administrative, research, and
public health data from a variety of sour
ces and in a variety of formats so that account holders in
Health Record Banks
can be assured that all relevant
electronic clinical information can be
capture
d, stored, and displayed.

The Tolven applications are engineered to capture the

data
elements needed to generate the

“Continuity of Care Record”

(CCR)
9
.

The CCR is a maturing
industry standard that specifies the core information that should be shared amo
ng care
providers about any patient.
Tolven believes that a core function of the CCR is to ensure
seamless access to information for all appropriate members of a patient’s care t
eam, including
consumers

and their families.

The CCR concept is so fundamental

that
Tolven makes it

equally
accessible to consumers

(and/or their families) and care providers.


A major part of the CCR is a compilation of the critical clinical information (CCI) that medical and
nursing students are trained to review and that is cons
tantly at the top of the list of information
shared among care team members in the ongoing care of
students
. We shall be certain that the
CCI includes all of the paramete
rs required to manage

healthcare
. In addition, the CCR includes
a number of demographi
c and administrative data elements that are required for e
ffective care
delivery to consumers

(e.g., health insurance status, next of kin, and advanced directives).
Whenever possible, the CCR components will be rendered as semantically interoperable data
e
lements. Such transformation will enhance clinical decision support, evidence
-
based medicine,
quality assurance, public health, and clinical research
.



The very nature of the open source movement enhances ease of technology transfer.
10

The
applications and

services offered by Tolven are licensed as Open Source (LGPL). Tolven’s
commitment to open source is absolute and unprecedented in health care. The Tolven source
code is managed by the non
-
profit Tolven Institute and controlled appropriately by the Insti
tute’s
Governing Board to ensure high quality of product development and delivery.


Open Source Components


The Tolven platform incorporates those information model and vocabulary standards that have
showed durability in healthcare information technology
. In addition, many development
resources used by Tolven are ones that have become available through the efforts of the open

Tolven White Paper

for the HRBA


4

source community. A full review overview of the major standards and open source components
used in the Tolven platform and applicat
ions is available through
www.tolven.org
.


1.

The
Core Data Model

is based on an ANSI standard model called the HL7 Reference
Information Model (
RIM
) which is in turn composed of ANSI standard
data types
. The
third major aspect of the core model is based on standard terminologies from
HL7
,
College of American Pathologists (
SNOMED
), and several others which have been
cross referenced by the National Library of Medicine in the Unified M
edical Language
System® (
UMLS
).


2.

Tolven is using the
JBoss Application Server
, an implementation of EJB3, the next
generation of Enterprise Java Beans technology. This new standard
was

finalized in
2006. The EJB3 standard is proving to be more productive to use, test and maintain.
The JBoss platform provides an embedded Apache HTTP server for reliable and high
performance Web page delivery.


3.

The Tolven Platform is developed as a databa
se
-
independent solution. The initial
release of the Tolven Platform uses the
PostgreSQL database
, which is a powerful,
open source relational database system. The Tolven solution uses a relational database
in several ways. The UMLS schema stores over one m
illion standard medical concepts,
over 5 million terms, and tens of millions of relationships and mappings between them.


4.

Tolven applications access the database through Enterprise Java Beans (EJB3) objects
which are in turn implemented by
Hibernate for
object relationship mapping
. EJB entity
beans are used without the need for Hibernate extensions. Other than for performance
and for some configuration, Hibernate is transparent to the Tolven Platform.


5.

Tolven makes use of a number of advanced Web
-
based pa
tterns and technologies in
order to improve the user experience and reduce response time latency.
The MyFaces
incubator project has several

AJAX
-
based components
. The goal is to minimize screen
repaints, scrolling, and typing. This sets the stage for pen
-
b
ased devices. Faces
provides the technology to support multiple languages, style sheets, and other
customization capabilities. This makes it possible to visually adjust the user interface to
specific needs. Faces also provides support for variations in pag
e composition due to
user permission and preferences.


6.

Tolven provides built
-
in process flows. While
jBPM

does have a graphical process flow
designer, it is activated in a programming environment and thus has limited value for the
typical user. Neverthele
ss, these flows will have sufficient optional flows that typical
process configuration can be handled by preference settings.


7.

Tolven utilizes the new
Java 5 language

environment for improved maintainability and
programmer productivity. From regular expres
sions to security capabilities, Java 5 is
fully exploited by Tolven. Generics have reduced errors and overall much cleaner code.
Annotations provide a more organized means of configuration than previous XDoclet
approaches. All Tolven source code is writte
n in Java.


8.

The JBoss
Rules Engine implementation
is
based on
Charles Forgy's
Rete
algorithm
tailored for the Java language. Adapting Rete to an o
bject
-
oriented interface allows for

Tolven White Paper

for the HRBA


5

more natural expression of business rules with re
gards to business objects. JBoss Rule
s
is written in Java, but able to run on Java and
.Net
. JBoss Rule
s provides for
Declarative Programming

and is flexible enough to match the semantics of your problem
domain with Domain Specific Languages (DSL) via XML using a Schema defined f
or
your problem domain. DSLs consist of XML elements and attributes that represent the
problem domain.


9.

Tolven stores user information in
OpenLDAP
. This approach allows federation, a variety
of authentication technologies, and another decoupling between us
ers and protected
patient data. LDAP is used widely and so should provide as much flexibility as needed
for complex, multi
-
organization, distributed user communities. Tolven has no
dependency on the specific Directory Server used as long as it supports the

standard
protocol.


The platform incorporates workflow, rules and terminology management, thereby supporting a
complete solution for the purpose of secure data storage and the semantic re
-
use of data,
irrespective of the source of the data.
The platform
is ideally c
onstructed for

Health Information
Exchange.

The platform supports secure information exchange and storage, and patient
consent functionality that
are

compliant with
the principles of the HRBA
. The platform is able to
scale to s
upport large regi
ons and

support
s

the rapid response times that are demanded
by
consumer
s

and clinicians alike
. The platform is able to support a hosted service for the required
a
pplications. The end user

require
s

nothing more than a browser on a modern desktop/laptop or
a Web enabled hand held device such as a mobile phone or PDA.


The Tolven electronic Clinician Health Record (eCHR) application allows for seamless
exchange of clinical information with
electronic clinical information data sources and with
the
Tolven
elect
ronic Personal Health Record (ePHR).



The Tolven eCHR application includes, at a minimum, the ability to enter, persist, and
view all of the Critical Clinical Information data that is required to generate the Continuity
of Care Record (CCR)



The Tolven eCHR
allows for linking of ordered services (procedures, medications,
laboratory studies, etc) to appropriate diagnoses



Upon being granted consent by the patient, the provider can transmit clinical information
to another designated provider
or to the patient’s

PHR (account in the Health Record
Bank.)


The Tolven ePHR

is the patient’s view of his/her electronic health record (EHR) information
. It
corresponds to the account view in a Health Record Bank.



The Tolven ePHR is launched by and maintained by the patient

(or his/her explicitly
designated agent)


Tolven White Paper

for the HRBA


6



At the account holder’s discretion, c
linical information created by other sources (provider
systems, drug orders, laboratory results) can be forwarded to and incorporated in the
ePHR
.



Consent to view
any
clinical i
nformation in any Tolven ePHR must be explicitly granted
by the patient (or his/her explicitly designated agent)



Both Tolven applications take ad
vantage of open source clinical data definition

(
formal re
-
usable
model
s of

domain conce
pts)

development (see

www.wikihit.org
) to enhance interoperability.

A

Wiki
HIT clinical data

definition

(CDD)

brings together a number of elements into a single
reu
sable domain model. The
CDD
s that are being developed as part of the colla
borative nature
of WikiHIT include:



a CDD structure

and naming conventions



a model for aggregating templat
es into usable components such as

assessments
and

questionnaires




a

mechanism f
or relating CDDs

to
clinical codes




a means to encapsulate
rules
,
log
ic

and
dependencies




links to
external references

for validation purposes


The Tolven solutions empower
consumers

and clinicians to collaborate
in the creation of a
system of electronic health records that can become a major (if not the major) component of

a
national or regional health information network
.


Security and Privacy


Because the Tolven platform is designed in an open source environment using a clearly ratified
set of standards for health care information, new technology and new systems can be em
braced
with greater ease than in the past. The Tolven architecture has been specifically designed to be
complementary to the National Health Information Network (NHIN) pilots that have been
established by the Office of the National Coordinator (ONC, former
ly ONCHIT). Tolven uses
industry standards from a technical, architectural and information model perspective, which
ensures that the Tolven applications and services are complementary to the NHIN pilots.


The Tolven platform addresses
privacy and security

issues by including provisions for the
following:



Consumers

have the right to opt out of participating at any time



Once
consumers

have elected to “opt in” they can also explicitly grant consent to
authorized users to view only specified sections of their p
ersonal healthcare information


Tolven White Paper

for the HRBA


7



Conse
nt to view/not view can

be limited to selected logically meaningful categories of
information in t
heir medical records



Consent may be granted (or denied) to individuals or groups



The pairing of the Tolven eCHR and the To
lven ePHR will empower
consumers

and
their families
/agents

to participate in managing their healthcare to an extent not yet seen
because each can easily exchange information with the other, upon registration of
consent.


Tolven is concerned with protecting

data in transit (eg SSL) and protecting data at rest (e.g. in
the database). Tolven requires proper authentication

of users, accounts (e.g. family, clinic
, lab,
etc), and system components (App server, LDAP server, Database server).


1.

End users (via their

browser) verify authenticity of Web/application server using digital
certificates. SSL then protects the communication between browser and application
server from "man in the middle" attack. The application server, with the aide of the LDAP
server, usually

authenticates the user via username and password entry. This accounts
for the bulk of the visible web
-
based security most people see.


2.

Although typically behind a firewall,

Tolven further requires mutual authentication (digital
certificates) and secure co
mmunication (SSL/TLS) between backend system
components. For example, the application server

must authenticate the database server
that

it connects to and likewise the database server must authenticate the application
server. The same

approach is used

for

communication between the application server
and the LDAP server.


3.

While SSL is designed to guard against "man in the middle" attacks, it does nothing to
protect data once it arrives at its destination where the SSL encryption is removed. In
Tolven, new d
ocument data is immediately encrypted in the application server, before
being transported to the database. Thus, as a new document travels from the application
server to the database server, it is essentially double encrypted because of SSL.

Upon
arrival,
the SSL encryption is removed. Yet, when the document comes to rest, it is still
encrypted because of the document
-
level encryption.


4.

Document encryption provides an "absolute" level of protection between Tolven
accounts. For example, a document created, s
ay, in

a person's

personal health record is
only visible to users of that personal health record account, typically that one person or
members of that person's family. No one else. This absolute partition cannot be violated,
even by a system administrator
with root passwords and a complete copy of the
(encrypted) data, log files, etc. It would be as unusual for a physician to have access to
someone's personal account as it would for a
patient

to have access to data in the
physician's account.


5.

The process o
f sharing data between accounts in Tolven is explicit. Simply

granting
users in one account access to see data in another account is not allowed and if it were,
it wouldn't do any good because of the "absolute" encryption described in #4. Instead, to
share

data between accounts requires a user in the outgoing account to initiate an action
that internally makes a
copy

of the source document encrypted so that only members of
the receiving account can read the
copy
. This is why

we say

"Privacy is enhanced at t
he
cost of

extra disk space" This explicit action provides a very reliable audit trail because

Tolven White Paper

for the HRBA


8

the act of sharing data is recorded in space and time with the medium

being the
document itself. If

a citizen
opts in

to a research program, cancer registry, pub
lic health,
shares an intake questionnaire (clip board) with his or her family doctor or a physician
releases a lab result to the
patient
, each such sharing is explicitly recorded in the form of
a new document only visible to members of the receiving accou
nt.


6.

Sharing data among users within a single account is not subject to such strict control as
above. When needed,

access can

be

controlled by "traditional" authorization, role
-
based
access.

However, Tolven expects accounts to be small enough (a
family or
a
single
clinic for example) so that cumbersome user
-
level permission schemes can be reduced
or avoided completely.


7.

SSL, TLS, X.509, PKCS, WS
-
Security, etc are protocols and wrappers around the actual
low
-
level encryption and public/private key algorithms
. The algorithms

(RSA, DES,
3DES, AES, etc)

and corresponding strengths or key lengths evolve over time as CPU
speeds increase. In order to avoid a lock
-
in to specific algorithms, Tolven uses

the
openSSL framework for SSL and the JCE framework for document

encryption so that as
new algorithms are added or specific countries impose restrictions, only parametric
changes are required.


8.

Security standards are particularly important for data at rest since encrypted documents
may exist for decades. It would impra
ctical to re
-
encrypt existing documents. So, many
different encryption techniques may be in use over time.


9.

Digital signatures of documents in Tolven is somewhat related to encryption because
many of the underlying algorithms are the same. While documents
are encrypted at the
account level, signatures

on a document

are

attributed to

individual users. A document
can be signed by one or more users. A copied document, as long as it has not been
changed from the original, can retain

its signatures even if it mo
ves to an account where
that user is not a member. For example, if a physician "signs" a lab result and then
sends the result (a copy actually) to the
patient
, the physician's signature is retained.
The
consumer

or even a privileged system administrator

(o
r someone else in the middle)
would not be able to modify or counterfeit a document without invalidating the signature.






1

Taylor, Roger at al

(2005).
Promoting Health In
formation Tec
hnology: Is There a Case f
or More
-
Aggressive



Government Action?

Health Affairs
,

24
:

1234
-
1245
.

2

Lumpkin, John R, et al (July 6, 2000). Report on Uniform Standards for Patient Medical Record Information.


National Committee on Vital and H
ealth Statistics Report to the Secretary of the US Department of Health and



Human Services
,.

3

Kaushal, Rainu et al (2005). The Costs of a National Health Information Network.
Annals of Internal Medicine
.


143: 165
-
173

4

“Electronic Health

Record Definition, Scope, and Context” ISO/TC 215 Technical Report, August 2003

5

“Electronic Health Record Definition, Scope, and Context” ISO/TC 215 Technical Report, August 2003

6

Goulde, Michael and Eric Brown (March 2006). Open Source Software: A Pr
imer for Health Care Leaders.


California HealthCare Foundation
.

7

Lumpkin, John R, et al (July 6, 2000). Report on Uniform Standards for Patient Medical Record Information.


National Committee on Vital and Health Statistics Report to the Secre
tary of the US Department of Health and


Human Services.

8

Walker, Jan
et al
; The Value of Health Information Exchange and Interoperability. Health Affairs, January 19,
2005


Tolven White Paper

for the HRBA


9






9

Tolven will also support the CCD when that standard is sufficiently ratifi
ed

10

Goulde, Michael and Eric Brown (March 2006). Open Source Software: A Primer for Health Care Leaders.




Appendix


HRBA Principles



Consumer Ownership and Control of Health Records


1.

Health record banks protect the
individual consumer’s
right to
heal
th information
privacy
and confidentiality
by acting as trusted legal custodians of consumers’ health
records.


2.

Health
record banks

are repositories for
trustworthy
copies of health information

selected
or submitted by the consumer from various sources.


3.

H
ealth information i
n a health record bank

is owned by the consumer and is not an
asset of
the health record bank.



4.

Consumers may authorize

someone else to manage their heal
th record bank account
.


5.

Health record banks
provide consumers and others they
auth
orize
with immediate
electronic acc
ess to their health information.


6.

Consumers control all disclosures of their health information b
y a health record bank

unless otherwise required by
law
.


7.

With consumer consent

based on advance disclosure appropriate to t
he
circumstances, health record banks

enable secondary use of health information
, such
as
for public health and research purposes
.


Operation of Health Record Banks


8.

Health record banks
are governed in an open
, accountable,

and transparent manner.


9.

All acc
ess and updates to

information in h
ealth record banks are recorded as they
occur in an appropriately detailed audit trail database, and each health record bank
shall maintain those unaltered audit records

at least during the time that a consumer’s
health r
ecord is kept at the bank
and
make
th
o
se
audit records immediately
accessible
to consumers.


10.

Health record banks
have established processes for correcting errors by updating,
amending, and sequestering data
,

including mechanisms for notification of parties

who have received such data.


Tolven White Paper

for the HRBA


10







11.

Health record banks promptly disclose
breaches
of privacy, confidentiality, or
security
to consumers.


Operation of the HRBA


12.

The HRBA seeks to maintain neutrality among vendors that agree to adhere
to the
above principles.




Definitions used by the HRBA in its statement of principles.

Derived from a l
etter from the National Committee on Vital and Health
Statistics to Secretary of HHS sent to Michael
Leavitt,
6/22/06.


Health information privacy

refers to an individual's righ
t to control the acquisition, use, or
disclosure of his or her identifiable health data.


Confidentiality

refers to the obligations of those who receive information to respect the
privacy interests of those to whom the data relate.


Security

refers to the
physical, technological, or administrative safeguards or tools used to
protect identifiable health data

from unwarranted access or disclosure.