“Standards-based Messaging”
Communications
Barriers, Boundaries, and Solutions
in Public Health
Agenda
Why do we need standards-based messaging in Public Health?
Three Approaches to System Integration
Manual Integration
Brute Force Integration - Tightly Coupled
Ideal Integration - Loosely Coupled
How does standards-based messaging enable “ideal” integration
Case Study – State of Hawaii, Department of Epidemiology
Generation 1 – Manual reporting
Generation 2 – Somewhat automated
Generation 3 – Fully automated
Why do we need standards-based
Messaging in public health?
Bioterrorism
Tie systems disparate systems together on different platforms
HIPAA
Existing systems are built on multiple platforms with different messaging
capabilities
Non-technical boundaries also exist – trust, organizational, geographical
Additional boundaries –security
Systems, organizational structures, agreements, partnerships are ever-
changing - Organizations can‟t afford to reinvent the wheel when things
change
System integration traditionally used proprietary code with little or no
reuse.
Generation 1 – Manual Integration
Characteristics
Both sides agree on what, how, when, even why
MANY points of failure
Changes, both technical and non-technical highly effect interface
and/or delay communication
Tightly Coupled Applications
Characteristics
Both parties had to agree to format of message, protocol for message
communication, communication methods, security, etc.
Often required manual efforts to initiate integration with little to no error
checking, message retry
Systems are often built on multiple platforms and languages
Drawbacks
Changes to one application caused other application to change
As non-technical issues (politics), personnel turn over, knowledge of what,
why left
Difficult to get both sides to agree to interface details
Loosely Coupled Applications
Characteristics
Systems are, when possible, “self-defining”
As systems are changed or replaced, impacts to downstream
systems are not affected
Relies on standards to ensure message flow and are compatible
Advantages
Large vendors like Sun, IBM, and Microsoft have bought into standards and
have legitimized EAI
How does standards-based
messaging enable “ideal” integration
Self-defining interfaces
WSDL
Message Format agreed upon (mostly) upfront
HL7 (XML version also helps make it self-defining)
X.12 EDI (HIPAA-approved transaction sets)
Standard Communication format/protocols
HTTP(s)
SOAP
Secure – helps alleviate trust issues
Use of X.509 digital certificates
RSA 3DES, Diffie-Hullman encryption
Case Study – Hawaii DOH
Hawaii Dept. of Epi wanted real-time knowledge of infectious
or emerging diseases throughout the state.
Hawaii‟s public health lab contributed a VERY small portion
of the lab results to Epi.
70%+ of reportable disease results come from 4 partner labs
– Diagnostic Labs of Hawaii, Clinical Labs of Hawaii, Kaiser
labs of Hawaii, and Tripler Army Medical labs.
One lab had strong systems and strong IT personnel, other 3
did not.
Generation 1 – No integration
Characteristics
paper reports compiled
Couriered
Different formats from each lab
By the time the data arrived and was compiled, the data was too old
to do any good outside of marginal research value
Too much human involvement, thus error-prone
Generation 2 – Mostly Manual
Characteristics and Drawbacks
electronic file created from labs‟ LIS and uploaded via manual modem file send.
Daily transmissions from all three labs were received on time an average of 74% of
the time. A variety of technical problems accounted for delayed or missing reports,
including such mundane problems as accidentally unplugging the computer used for
transmission.
On average, missing data were re-transmitted within three days, but re-transmission
sometimes took over a week. Approximately 12% of records received were either not
reportable findings, were negative results, or were otherwise incorrect. This required
considerable staff time for data cleaning and editing.
Relied on human intervention to filter data to provide only positive results of diseases
deemed by law to be “reportable”
No automatic re-transmission
As people moved in organization or left, they had to be retrained
the electronic reporting yielded more than twice as many reports as paper reporting
Generation 3 – Fully automated
Characteristics and Drawbacks
real-time transmission
encryption provides security/privacy
uses public internet
requires little human intervention – 90% automated
Automatically filters out „reportable‟ results
Not always positives – allows for testing success of new tests
(specifically, flu)
Further anonymizes HIV/AIDS results to further protect patients
What is eWebIT?
A suite of products consisting of eLink, eView, and eConfirm
eLink – interface engine technology capable of embracing
both new technologies as well as enabling legacy
applications
eView – state of the art web screen generator that expands
the backend integration tools of eLink into front-end
application
eConfirm – Single sign-on solution that uses a non-invasive
approach to manage third party system access, access
audits, and overall user desktop management
Supported Device Connections
Device connections enable eLink to receive a new unit of
work, often over a specific communication protocol:
– TCP/IP
– SNA (LU6.2)
– Directory poll / timer
– IBM MQueue Series, MSMQ
– RS232 / Serial
– Screen scraping (Mainframe, AS/400, UNIX,
Meditech, TDS, etc)
– Windows / Web browser scraping
Available Libraries
Various libraries are accessible from translators including:
Data parsing (XML, HL7, X12, Fixed width, delimited, binary and
proprietary)
Comparison / Validation / Boolean logic / Routing
Database access via SQL and stored procedures to Oracle, Microsoft SQL,
Informix or ODBC
File and directory access
Object invocation via COM, Corba and Enterprise Java Beans
Internet protocols such as HTTP(s), FTP and LDAP
Formatting (EBCDIC, Binary coded)
Floating point and whole number arithmetic
Date/time functions
Operating System specific such as running external programs and
accessing the Windows registry
Encryption and digital signatures
eLink Architecture
Hawaii ECDRS Architecture
Hawaii DOH - ECDRS Conceptual Interface
Architecture
Lab Department of Health
LAB HL7 Data Encryption/
Results Gathering Communication Decryption/ Data
Interface Interface Interface Communication Gathering
Internet Interface Interface
Firewall Firewall
Test/ Firewall Test/
Results Results
HL7 mappintg mappintg
Encrypted HL7
HTTPS
Decrypted HL7
XML External
Feeds
External
External
File
External
File
Feeds
FeedsExternal
File
File
Feeds
Feeds
XML