Advantages and Integration of
Multi-vendor LIS Environments
Pathology Informatics 2010
Mark Routbort, MD, PhD
University of Texas MD Anderson Cancer Center
Houston, Texas
Disclosures:
No financial relationships
Mostly satisfied customer
Have previously served as a member of IMPAC PowerPath Advisory Board
Anatomy of the laboratory information system
General lab
resulting
Anatomy of the laboratory information system
Inbound integration
orders, ADT
Phlebotomy/
specimen collection
General lab
resulting
Outbound integration
EMR, fax/print, outreach
Billing
Anatomy of the laboratory information system
Inbound integration
orders, ADT
Phlebotomy/
specimen collection
General lab
resulting
Outbound integration
EMR, fax/print, outreach
Billing
Labs
Anatomic
pathology
Transplant/HLA
Microbiology
Transfusion
Cytogenetics
Molecular diagnostics
Flow cytometry
Proteomics
Anatomy of the laboratory information system
Cross-cutting
features
In-lab workflow
Digitization
Inbound integration
orders, ADT
Phlebotomy/
specimen collection
Data analysis
Image analysis
QA/QI
Procedure/EDM
General lab
resulting
Outbound integration
EMR, fax/print, outreach
Billing
Rules
Integrated reports
Synoptic data
Asset management
Automation
Labs
Anatomic
pathology
Transplant/HLA
Microbiology
Transfusion
Cytogenetics
Molecular diagnostics
EMR
Radiology
Flow cytometry
Clinical notes
Proteomics
Pharmacy
The allegorical elephant
• How you define a laboratory
information system depends to
some extent on what you are
trying to do, or what your
biggest current problems are
• If you want your laboratory
information system to do “all of
the above”
– Very good
– Very ambitious
A tsunami of clinical diagnostic
and biomedical research data
Example –
Diagnostic bone
marrow biopsy
•
•
Hematologic lab values
Morphology
•
•
•
•
•
•
•
•
Clot
Core
Smears
Cytochemical/special
Immunohistochemistry
Flow cytometry
Cytogenetics
Molecular
Dealing with complexity
• Break up problems
into their constituent
elements
• Classify and
subclassify
• Compartmentalize
and subspecialize
BM report
Test requisition
Slides from
hemepath
Mostly handfilled, includes
CBC data
BM diff
Historical data
ClinicStation or
PowerPath
Custom
application
Slides from
histopath
Flow
CERNER
However, in support of clinical diagnostic work, data
integration is needed at multiple levels
• Within a single modality over time (historical
record)
• Across labs for pathologic diagnoses and
pharmacodiagnostics
• Across the patient record for clinicopathologic
correlation and optimal diagnostic efficiency
What is an integrated application platform?
• Microsoft Office suite as example
• Consistent “look and feel”
– From user perspective, ease of use of application is
enhanced by consistent user interface paradigms
– From vendor perspective, branding and differentiation
are considerations as well
• Data communication and updates between
components
– Static cut and paste as minimal example
– Linked objects with dynamic updating
Multi-vendor integration advantages
• Allows a “best of breed” selection process
• Can enable lab-by-lab system upgrades
– Anatomic versus clinical lab system
– Transfusion medicine – donor and recipient
• Integration of new or rapidly evolving
technologies
– Digital pathology
– Proteomic/molecular
• Facilitate subspecialty lab data analysis
– Cytogenetics
– Flow cytometry
– Molecular diagnostics
General integration approaches
with multiple systems
•
•
•
•
•
•
•
Cross-system data reports
Terminal scripting
Health Level 7 interchange
XML/Web Services
Form based data exporting and importing
Application programming interfaces
Application integration
– Simulating a single vendor experience: single sign-on
and context synchronization
– Functional integration
Cross system reports
Relational databases enable a granular, extensible
data-centric model of the real world
Cross system reports
Data from
outside system
(institutional
ADT database)
Terminal scripting
• For terminal/host based LIS integrations
• Programmatically emulate a set of keystrokes
imitating what a user would do at a terminal
keyboard
Terminal scripting
Terminal scripting
Doesn’t have to be (shouldn’t be) “dumb”
• Dumb: timed set of keystrokes played back in
equal time regardless of host response
• Intelligent
•
•
•
•
•
Read host response and react appropriately
Handles branching logic
Handles delays on the part of the host
Handles errors gracefully with logging and alerting
Can abstract data from host windows (“screen scraping”)
Terminal scripting – uses at MD Anderson
• Provide “single sign on” functionality for
pathologists – lightweight
• Shortcut to flow cytometry test verification
function for pathologists – lightweight
• Used to automatically update a patient flag in our
CERNER system based on data from our MAK
Progesa transfusion medicine system to enable
intersystem rules based on recent blood typing
results – much more complex
MAK Progesa to CERNER Pathnet
Scripted Updates
• Runs as a
Windows
service
– Unattended
– Auto start
– No direct user
interface
• Incorporates
logging and
alerting logic
MAK to CERNER Test Harness
Terminal scripting lessons
• Difficulty of set up is linked to complexity of process being
automated
– Branching logic?
– Errors possible?
– Interactive or unattended?
• Potentially sensitive to changes in the underlying systems
• Can solve certain problems that can’t be addressed
effectively in other ways
Information transfer: Health Level 7 (HL7)
•
Messaging standard for health care inter-systems communication at the
highest level - application – of the Open Systems Interconnection or OSI
Model of networking
•
Founded 1987, versions 2.1, 2.2, 2.3 from 1990-1999, in wide use for
communicating lab and pathology results (version 2.x)
•
ANSI standard
CBC (Supergroup) result message examples - Partial result message
MSH|^~\&|ESI|LAB|INVISION_PMS|HIS|20050331155000-0600||ORU^R01|2980822|T|2.1
PID|1||000000000999999|00000|TEST^MICKEY^N||19400313|F||W|||||||UNK|000010501880256|428827901
PV1|1|O|DICT^DICT|||||||731||||HIS|||0000361^WALTERS, RONALD S. M|R||||||||||||||||||||||||||200503011442000600|20050402155000-0600
OBR|1|5500280|01014775200001550550028025032847925032847900000000101|5500312^CBC^COMPLETE
BLOOD CNT/DIF/PLT|RT|20050331152000-0600|20050331154200-0600|||PCCGS^SO, CELIA
G.||||20050331154300-0600||0000361^WALTERS, RONALD S.
M||1||0000509003089|G|||LA|P||^^^200503311520^^RT
OBX|001|NM|5500009^WBC^WHITE BLOOD CELL COUNT|| 2.4|K/UL| 4.011.0|L|||F||00000000000000225200|20050331155000.0000-0600|IIM^INSTRUMENT PERFORMED
ID|PCNDA^ACOSTA, NOEL D.
OBX|002|NM|5500018^RBC^RED BLOOD CELL COUNT|| 3.03|M/UL| 4.005.50|L|||F||00000000000000225200|20050331155000.0000-0600|IIM^INSTRUMENT PERFORMED
ID|PCNDA^ACOSTA, NOEL D.
HL7 version 2.x strengths (weaknesses)
Efficient, well-defined message
model
Difficult to human-read
Extensions must be through
overloading of fields
Vocabulary independent
Syntactic interoperability
Vocabulary independent
Lack of semantic interoperability
Widely implemented
Lowest common denominator
Widely implemented
Lowest common denominator
Common uses of HL7 to interface lab systems
• ADT interfaces
– Allow systems to get a direct copy of patient
demographic data and hospital/outpatient status
• Orders interfaces
– Allow intersystems direct creation of orders
– For instance, order entry in the EMR for lab draws with
transmission to the LIS
• Results interfaces
– Communication of lab test status and resulting to
systems connected to the LIS
HL7 between lab information system components
• Can be effective and reliable in the covered domains
– Uncovered areas of integration out of scope
– Non-textual data is awkward
• Most common example is incorporation of reference lab
testing (e.g. Quest Diagnostics, Mayo) into local LIS to
eliminate manual entry of send-out tests
• Other scenarios are possible but less common
– Incorporation of lab data stream into pathology system
• HL7 is generally a “push” model for integration
Traditional EMR-centric (push) model for pathology result reporting
HL7-based delivery of pathology reports
converted from editor like Microsoft Word to ASCII
Pathologist
Self, transcriptionist,
resident entry
Format conversion
to ASCII text
DIAGNOSIS
Metastatic adenocarcinoma.
HL7
“Native”
pathology
report
Interface
engine
Transmission of complex data over
HL7 generally requires transformation
(parsing) to ASCII text
HL7
HIS Viewer
Custom
display
logic
Clinician
Report as seen by pathologist
Report parsed into HL7 and received by the HIS/EMR
Integrity of semantic content is at risk in any transformation process
Push model generally means multiple copies
Should everyone have their own copy of the data?
• Complexity of the message processing
• Maintenance of the data model
• Maintenance and stewardship of the data,
including compliance issues
• Multiple potential conflicting sources of truth
An alternative – Service-oriented architecture
•
A perspective of software architecture that defines the use of services to
support the requirements of software users.
•
In SOA, resources such as lab data are made available as independent
services that can be accessed without knowledge of their underlying
platform implementation
•
While SOA does not dictate a specific implementation framework (e.g.
CORBA, RPC, DCOM, Web Services), Web Services as the
implementational strategy leverages W3C standards along with
corresponding deep penetrance of description, analysis, and
transformational tools
•
Key features of the SOA/Web Services perspective
– Schema and documentation is instrinsic to, not extrinisic from, service definition
(WSDL – web service description language)
– Schema and data are XSD/XML
– WSDL permits the automated generation of platform specific proxy classes for
consuming systems
Ref: http://en.wikipedia.org/wiki/Service-oriented_architecture
XML
•
eXtended Markup
Language
•
W3C specification for
data modeling
•
Human and machine
readable
•
Self-describing
SPiDR at MD Anderson –
Shared pathology information data repository
• Middleware service for querying of path & lab data
• Implementation:
– HL7 listeners -> population of relational database with normalized
model of laboratory data
– For some systems (APLIS - PowerPath), direct database replication
with implementation of text-indexes for case finding
– Multiple back-end databases running on multiple servers
• Supports multiple internal database models integrating data sources over
time
• Multiple mirrored servers allows the same data to be queried transactionally
(get me all the lab data on patient X) or analytically (find me all the patients
with recent diagnoses of chronic myelogenous leukemia with bcr/abl
translocation loads above X) without risking transactional performance
• Web services interface
– Annotated, streamlined XML schema for LabData
– Leverages W3C standards
Internal data model
• Fully relational
• Process-aware
• Temporal
• Multiple data sources; multiple databases
•
Internal data model is complex, normalized, and may vary according to source system
•
Includes temporal elements to support point-in-time state reconstruction (regulatory)
•
Much more complexity than most consumers need!
External (service) model
• Service – oriented question:
– What are the lab results?
• External model for consumers
– State but not process aware
– Significant denormalization to facilitate comprehensibility and
broad applicability
• For instance, patient demographic data is represented at the test level
Service model of lab data
• Tests
– A lab test, which may be in varying stages of completion (status), and which
may or may not have associated granular result details (TestDetail) or
additional metadata about the test itself (TestInfo)
– Examples: Complete blood count, GI panel, PSA
– Lab tests include information about the entity on which they were performed generally, a patient - which represents a flattening of the typical HL7 hierarchy
• TestDetails
– TestDetails are granular data elements representing specific result components
for a Test
– Examples: Hematocrit (within CBC test), bilirubin (within GI panel), PSA level
(within PSA test).
• TestInfo
– A collection of information about the test itself which does not readily fit into a
flat Test structure
– Examples: General result level comments not associated with a specific
TestDetail, cancellation or other process explanations, order level comments.
Demonstration
Data export and import strategies
• XML is powerful but not often the starting point for nonrelational data
• How to better get specialty lab diagnostic data in to the
LIS?
– Flow cytometry, molecular diagnostics, cytogenetics
• All share fairly complex workflows (non-linear) and have a high
degree of dependence on non-integrated analysis tools
• Data points transcribed in lab from different analysis packages into
LIS
• Domain data model is volatile and different than LIS data model
– It is common for these labs to use worksheets or specialized data
analysis packages to create summary data reports, which are
subsequently manually transcribed into the LIS and stored as
paper support documents
Getting the data in:
Flow cytometric analysis
•
Problems
– Multiple data analysis packages are required by lab…
CellQuest, FloJo, Excel, Diva, etc.
– LIS not designed, nor should it be, for raw list-mode
data or complex analysis
– This dichotomy results in separation of the original
diagnostic data from the LIS and cumbersome and
error prone transcription from the analysis data to the
LIS
•
Conclusions
– Even if acquisition and analysis resides outside the
LIS, there should be automatic import of both the
original analysis results and the structured data from
the analysis
– The LIS should be the place where the data comes
together
Sample CellQuest analysis
Multidimensional
scattergrams
Sample CellQuest analysis
Summary front sheet
Steps
• Define a schema for diagnostic flow cytometric analysis
data
• Define a web service/WSDL (and get our LIS vendor to
implement it!) for automatic data import using this schema
• Develop an import tool
– Reading raw PDF files to extract data elements
– Transformation into schema compliant XML
– Use web service to import analysis XML as well as an ectronic
copy of the visual data
FlowAnalysis schema
FlowAnalysis schema
The import tool:
The import tool:
The end result in the LIS:
Pre-vendor integration – electronic flow PDFs
to replace paper printouts
Application programming interfaces (APIs)
• An interface implemented by a software program that
enables it to interact with other software
• Functional integration is enabled by APIs
• Ideally, well-documented; publicly available
• Can be an extremely powerful paradigm
• It is also possible to create “wrapper” interfaces that use
techniques such as Windows automation to simulate a
native API
– E.g. “LaunchApplication”, “LoginUser”, “OpenCase”
Use of APIs to incorporate digital images
and digital slides in a simple viewer
Application integration
• Simulating a single vendor experience: single sign-on and
context synchronization
• Functional integration
– Bar coding support cross-application
– Automatic initiation of common tasks
• Accessioning a case
• Starting a dictation
• Functional build-out
PathStation at MD Anderson –
An enterprise application integration
engine for the laboratorian/pathologist
Design considerations for a unified
multi-vendor environment
• Single sign on for every application
• Intelligent context synchronization
• Use of bar codes to drive workflow in a
user/station appropriate manner
• Integration with both internal applications
(CERNER, PowerPath, dictation/transcription,
Aperio) and external (EMR)
• Platform for functional expansion
Brief demonstration
Conclusions
• Multiple vendor based systems can
present a relatively integrated end user
experience if appropriately connected
• This approach can provide some of the
benefits of incremental or best-of-breed
implementations with the benefit of a
unified application
• A robust tool set is needed
• There are many middleware providers,
developers, and automation toolkits
available in the marketplace in support
• Don’t take no for an answer – if it seems
like it should be doable, it almost
certainly is
Acknowledgements
• Shibu Ninan – PathStation lead developer
• Leslie Nesbitt – project manager
• Trey Elliot, Sanjivkumar Dave, Cathy Price,
Mohammed Gomah, James FlemingSPiDR
• Mike Riben – Medical Director, Path
Informatics