Advantages and Integration of Multivendor LIS Environments Pathology

Advantages and Integration of Multi-vendor LIS Environments Pathology Informatics 2010 Mark Routbort, MD, Ph. D University of Texas MD Anderson Cancer Center Houston, Texas Disclosures: No financial relationships Mostly satisfied customer Have previously served as a member of IMPAC Power. Path 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 Data analysis Image analysis QA/QI Procedure/EDM Inbound integration orders, ADT Phlebotomy/ specimen collection 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

Extra labels Test requisition Slides from hemepath BM report Mostly handfilled, includes CBC data BM diff Historical data Clinic. Station or Power. Path 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 (HL 7) • 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^R 01|2980822|T|2. 1 PID|1||00000999999|00000|TEST^MICKEY^N||19400313|F||W|||||||UNK|000010501880256|428827901 PV 1|1|O|DICT^DICT|||||||731||||HIS|||0000361^WALTERS, RONALD S. M|R|||||||||||||200503011442000600|20050402155000 -0600 OBR|1|5500280|0101477520000155055002802503284790000101|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||0000000225200|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||0000000225200|20050331155000. 0000 -0600|IIM^INSTRUMENT PERFORMED ID|PCNDA^ACOSTA, NOEL D.

HL 7 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

Common uses of HL 7 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

HL 7 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 • HL 7 is generally a “push” model for integration

Traditional EMR-centric (push) model for pathology result reporting HL 7 -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. HL 7 “Native” pathology report Interface engine Transmission of complex data over HL 7 generally requires transformation (parsing) to ASCII text HL 7 HIS Viewer Custom display logic Clinician

Report as seen by pathologist

Report parsed into HL 7 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 W 3 C 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 • e. Xtended Markup Language • W 3 C specification for data modeling • Human and machine readable • Self-describing

SPi. DR at MD Anderson – Shared pathology information data repository • Middleware service for querying of path & lab data • Implementation: – HL 7 listeners -> population of relational database with normalized model of laboratory data – For some systems (APLIS - Power. Path), 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 Lab. Data – Leverages W 3 C 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 (Test. Detail) or additional metadata about the test itself (Test. Info) – 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 HL 7 hierarchy • Test. Details – Test. Details 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). • Test. Info – 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 Test. Detail, 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… Cell. Quest, Flo. Jo, 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 Cell. Quest analysis Multidimensional scattergrams

Sample Cell. Quest 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

Flow. Analysis schema

Flow. Analysis 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. “Launch. Application”, “Login. User”, “Open. Case”

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

Path. Station 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, Power. Path, 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 – Path. Station lead developer • Leslie Nesbitt – project manager • Trey Elliot, Sanjivkumar Dave, Cathy Price, Mohammed Gomah, James Fleming- SPi. DR • Mike Riben – Medical Director, Path Informatics