Advantages and Integration of Multi-vendor LIS Environments

1. 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 relationshipsMostly satisfied customerHave previously served as a member of IMPAC PowerPath Advisory Board

2. Anatomy of the laboratory information system General lab resulting

3. Anatomy of the laboratory information system Inbound integrationorders, ADT Phlebotomy/specimen collection General lab resulting Outbound integrationEMR, fax/print, outreach Billing

4. Anatomy of the laboratory information system Labs Inbound integrationorders, ADT Anatomic pathology Phlebotomy/specimen collection Transplant/HLA General lab resulting Microbiology Outbound integrationEMR, fax/print, outreach Transfusion Cytogenetics Billing Molecular diagnostics Flow cytometry Proteomics

5. EMR Radiology Clinical notes Pharmacy Anatomy of the laboratory information system Cross-cuttingfeatures Labs Inbound integrationorders, ADT Anatomic pathology In-lab workflow Phlebotomy/specimen collection Digitization Transplant/HLA Data analysis General lab resulting Image analysis Microbiology QA/QI Outbound integrationEMR, fax/print, outreach Transfusion Procedure/EDM Cytogenetics Billing Rules Integrated reports Molecular diagnostics Synoptic data Flow cytometry Asset management Proteomics Automation

6. 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

7. A tsunami of clinical diagnosticand biomedical research data • Hematologic lab values • Morphology • Clot • Core • Smears • Cytochemical/special • Immunohistochemistry • Flow cytometry • Cytogenetics • Molecular Example – Diagnostic bonemarrow biopsy

8. Dealing with complexity • Break up problems into their constituent elements • Classify and subclassify • Compartmentalize and subspecialize

9. Slides from hemepath Slides from histopath BM report Mostly hand-filled, includes CBC data Test requisition BM diff Custom application Historical data ClinicStation or PowerPath Flow CERNER

10. 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

11. 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

12. 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

13. General integration approacheswith 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

14. Cross system reportsRelational databases enable a granular, extensibledata-centric model of the real world

15. Cross system reports Data from outside system (institutional ADT database)

16. Terminal scripting • For terminal/host based LIS integrations • Programmatically emulate a set of keystrokes imitating what a user would do at a terminal keyboard

17. Terminal scripting

18. Terminal scripting • 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”) Doesn’t have to be (shouldn’t be) “dumb”

19. 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

20. MAK Progesa to CERNER PathnetScripted Updates • Runs as a Windows service • Unattended • Auto start • No direct user interface • Incorporates logging and alerting logic

21. MAK to CERNER Test Harness

22. 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

23. 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.1PID|1||000000000999999|00000|TEST^MICKEY^N||19400313|F||W|||||||UNK|000010501880256|428827901PV1|1|O|DICT^DICT|||||||731||||HIS|||0000361^WALTERS, RONALD S. M|R||||||||||||||||||||||||||20050301144200-0600|20050402155000-0600OBR|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^^RTOBX|001|NM|5500009^WBC^WHITE BLOOD CELL COUNT|| 2.4|K/UL| 4.0- 11.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.00- 5.50|L|||F||00000000000000225200|20050331155000.0000-0600|IIM^INSTRUMENT PERFORMED ID|PCNDA^ACOSTA, NOEL D.

24. HL7 version 2.x strengths (weaknesses)

25. 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

26. 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

27. “Native” pathology report Traditional EMR-centric (push) model for pathology result reporting HL7-based delivery of pathology reportsconverted from editor like Microsoft Word to ASCII Pathologist Self, transcriptionist, resident entry DIAGNOSIS Metastatic adenocarcinoma. Format conversion to ASCII text HL7 Interfaceengine HL7 HIS Viewer Transmission of complex data over HL7 generally requires transformation (parsing) to ASCII text Clinician Custom display logic

28. Report as seen by pathologist

29. Report parsed into HL7 and received by the HIS/EMR Integrity of semantic content is at risk in any transformation process

30. Push model generally means multiple copies • 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 Should everyone have their own copy of the data?

31. 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

32. XML • eXtended Markup Language • W3C specification for data modeling • Human and machine readable • Self-describing

33. 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

34. Internal data model • Fully relational • Process-aware • Temporal • Multiple data sources; multiple databases

35. 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!

36. 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

38. 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.

39. Demonstration

40. Data export and import strategies • XML is powerful but not often the starting point for non-relational 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

41. 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

42. Sample CellQuest analysis Multidimensionalscattergrams

43. Sample CellQuest analysis Summary front sheet

44. 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

45. FlowAnalysis schema

46. FlowAnalysis schema

47. The import tool:

48. The import tool:

49. The end result in the LIS:

50. Pre-vendor integration – electronic flow PDFs to replace paper printouts