LIS Interfaces: Basics, Implementation and Pitfalls

Transcription

1 A Review of Pathology Informatics LIS Interfaces: Basics, Implementation and Pitfalls James H. Harrison, Jr., M.D., Ph.D. Division of Biomedical Informatics Departments of Public Health Sciences and Pathology University of Virginia October 9, 2012

2 Key Concept: Interoperability The ability of systems to provide services to and accept services from each other, and to use the exchanged services to operate effectively together An interface is a communications connection and translation mechanism between two systems that may have different internal representations of data Laboratory interoperability: patient registration, orders, specimens, results & reports

3 Data Interoperability Syntactic Interoperability Symbols are accurately exchanged Semantic Interoperability Symbols are correctly associated with concepts

4 Digital Communications ISO Networking Reference Model Message Structure & Content 7 Application Data model and semantics 6 Presentation Characters, lines, delimiters, fields 5 Session Authentication/authorization 4 Transport End-to-end communication (TCP) Low Level Transmission 3 Network Packet routing (IP) 2 Data Link Ethernet, FDDI, etc. 1 Physical Fiber, coax, UTP, µwave, Wifi

5 Digital Communications ISO Networking Reference Model Message Structure & Content 7 Application Semantics 6 Presentation Syntax Data standards: HL7, CLSI (ASTM), IHE, etc. 5 Session Authentication/authorization 4 Transport End-to-end communication (TCP) Low Level Transmission 3 Network Packet routing (IP) 2 Data Link Ethernet, FDDI, etc. 1 Physical Fiber, coax, UTP, µwave, Wifi

6 Generic Interface Structure Mapping Table Message construction & parsing Messages: Patient registration Orders Results Message construction & parsing Mapping Table Lab database MSH ^~\& ADT1 GOOD EVN A PID 1 PATID1234^5^ MSH ^~\& ADT1 GOOD NK1 1 NUCLEAR^NELDA EVN A PV1 1 I 200 PID 1 PATID1234^5^ NK1 1 NUCLEAR^NELDA PV1 1 I 200 Transaction logs Error logs MSH ^~\& ADT1 GOOD EVN A PID 1 PATID1234^5^ MSH ^~\& ADT1 GOOD NK1 1 NUCLEAR^NELDA EVN A PV1 1 I 200 PID 1 PATID1234^5^ NK1 1 NUCLEAR^NELDA PV1 1 I 200 EMR database

7 Relevance of System Interfaces EMR value proposition requires interoperability HITECH incentives are increasing lab clients with EMR Ambulatory EMR < 25% in 2009 to > 80% by 2016 Meaningful Use requirements are evolving CPOE and lab reporting becomes required in MU 2 Data content HL7 version progression (HL ) LOINC and SNOMED inclusion Financial impact of implementation and upgrade Ubiquitous; the glue that holds the system together

8 HL7 Department of of Public Health Sciences

9 Laboratory Interfaces Local Health System LPL System Reference Laboratory HL7 Interface Engine EMR VPN VPN Community Providers Instrument Manager LIS Ancillaries & Research Systems Analyzer Analyzer Analyzer POC Devices & Base Station

10 Instrument Interfaces Local Health System LPL System Reference Laboratory HL7 Interface Engine EMR VPN VPN Community Providers Instrument Manager LIS Ancillaries & Research Systems Analyzer Analyzer Analyzer POC Devices & Base Station

11 Instrument Interfaces Connect instruments to LIS Instrument manager may mediate POC manager is analogous Unidirectional Enter accession # and test, send results once Bidirectional Receive & store orders; barcoded samples; store and resend results Order broadcast/query across multiple analyzers; throughput issues Data content Proprietary instrument drivers CLSI (formerly ASTM) standard, majority HL7 standard; new HL7-based profile from IVD Industry Connectivity Consortium (IICC) and IHE Relatively plug-and-play and improving

12 Local System Interfaces Local Health System LPL System Reference Laboratory HL7 Interface Engine EMR VPN VPN Community Providers Instrument Manager LIS Ancillaries & Research Systems Analyzer Analyzer Analyzer POC Devices & Base Station

13 HL7 Messaging Standard Health Level Seven International A framework for messaging between healthcare applications (ISO level 6 & 7) Version 2 released in 1988 Version 2.3 (1997) widely deployed, 2.7 is current Version 3 released 2003 Membership required for use previously, now standards to be released at no cost Not plug and play

14 HL7 Version 2 Defines message types for medical events: admission/registration/discharge/transfer, queries, orders, results, clinical observations, billing, medical records, etc. Defines transaction model for using the messages (initiation, response, error handling) Defines message structure (data fields), but limited requirements for content Pragmatic standard that predated terminology standards

15 Admit Message (A01) Segments, delimiters, fields, components & subcomponents MSH ^~\& ADT1 GOOD HEALTH HOSPITAL GHH LAB, INC. GOOD HEALTH HOSPITAL SECURITY ADT^A01^ADT_A01 MSG00001 P EVN A PID 1 PATID1234^5^M11^ADT1^MR^GOOD HEALTH HOSPITAL~ ^^^USSSA^SS EVERYMAN^ADAM^A^III M C 2222 HOME STREET^^GREENSBORO^NC^ GL (555) (555) S PATID ^2^M10^ ADT1^AN^A ^NC NK1 1 NUCLEAR^NELDA^W SPO^SPOUSE NK^NEXT OF KIN PV1 1 I 2000^2012^ ^ATTEND^AARON^A SUR ADM A0

16 Result Message Example (ORU-R01) MSH ^~\& IDXLAB UVAHSC DADD ORU^R P 2.2 PID xxxxxxxx lname^fname^mi M ^^ PV1 OP STFM^ ^lname^^fname mi.(4201) ^ OP ORC RE ^0 4201^lname^^fname mi. ^ OBR ^0 CPBAS^BASIC METABOLIC PANEL^^CPBAS ^13:54 ^ ^13:54 ^ 4201^lname^^fname mi.(4201) M61675 CHEM F CPBAS^CPBAS ^^^^^R ^~^~^ OBX 1 NM NA^SODIUM mmol/l F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 2 NM K^POTASSIUM mmol/l F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 3 NM CL^CHLORIDE mmol/l F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 4 NM CO2^CO mmol/l F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 5 NM BUN^UREA NITROGEN 1 23 mg/dl F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 6 NM CREAT^CREATININE mg/dl F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 7 NM GLUC^GLUCOSE mg/dl H F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 8 NM CALCM^CALCIUM mg/dl F ^14:15 UVA^ 2886^AUTO^VERIFY OBX 9 ST GFRCAL^CALC GFR (ml/min/1.73m2) 1 >60 F ^14:15 UVA^ 2886^AUTO^VERIFY

17 Textual Results (ORU) OBR ^ DIA0021^CHEST, SINGLE VIEW PS4 ^^^ ^lname^fname mname RX P 1^^^^^P^^PRIOR &lname&fname mi&&& OBX 1 TX DIA0021GDT PRELIMINARY-THIS IS A PRELIMINARY REPORT AND SHOULD BE VIEWED AS P OBX 2 TX DIA0021GDT PRELIMINARY AND MAY BE AMENDED IN THE FINAL REPORT. P OBX 3 TX DIA0021GDT PT ACCT NO: xxxxxxx P OBX 4 TX DIA0021GDT ORDER NO: P OBX 5 TX DIA0021GDT EXAMINATION: P OBX 6 TX DIA0021GDT DIA CHEST, SINGLE VIEW EXAM DT/TIME: Aug 8, :03AM P OBX 7 TX DIA0021GDT Accession No: ###### CPT: P OBX 8 TX DIA0021GDT CLINICAL DATA:,--TRAUMA ALERT P OBX 9 TX DIA0021GDT P OBX 10 TX DIA0021GDT FULL RESULT: Examination: Chest, single view, dated xx/xx/xxxx P OBX 11 TX DIA0021GDT P OBX 12 TX DIA0021GDT COMPARISON: None P OBX 13 TX DIA0021GDT P OBX 14 TX DIA0021GDT FINDINGS: P OBX 15 TX DIA0021GDT Single portable supine view of the chest. EKG wires overlie the P OBX 16 TX DIA0021GDT patient. The lungs are without focal consolidation. Pulmonary P OBX 17 TX DIA0021GDT vasculature is mildly cephalized, likely secondary to supine P OBX 18 TX DIA0021GDT positioning. There is no evidence of pneumothorax or pleural P OBX 19 TX DIA0021GDT effusion. The hila, mediastinum, and heart appear within normal P OBX 20 TX DIA0021GDT limits for supine positioning and AP projection. P OBX 21 TX DIA0021GDT P OBX 22 TX DIA0021GDT P OBX 23 TX DIA0021GDT PRELIMINARY-THIS IS A PRELIMINARY REPORT AND SHOULD BE VIEWED AS P OBX 24 TX DIA0021GDT PRELIMINARY AND MAY BE AMENDED IN THE FINAL REPORT. P OBX 25 TX DIA0021GDT P OBX 26 TX DIA0021GDT P OBX 27 TX DIA0021GDT P OBX 28 TX DIA0021GDT IMPRESSION: P OBX 29 TX DIA0021GDT 1. No evidence of acute cardiopulmonary disease. P

18 Results Message Definition (ORU) OBX Segment Definition

19 Variability in HL7 Interfaces Site 1: Site 2: Site 3: OBX 1 CE ABO^ABO GROUP O^Type O OBX 1 CE BLDTYP^ABO GROUP TYPEO^Type O OBX 1 CE ABOTYPE^ABO GROUP OPOS^Type O

20 Variability in HL7 Interfaces Site 1: Site 2: Site 3: OBX 1 CE ABO^ABO GROUP O^Type O OBX 1 CE BLDTYP^ABO GROUP TYPEO^Type O OBX 1 CE ABOTYPE^ABO GROUP OPOS^Type O Requires mapping between systems and limits interface re-use

21 LRI and LOI Initiatives Standardize HL7 interfaces for ambulatory lab orders and results as part of Meaningful Use Based on HL , with additional field content requirements Incorporates LOINC for test names, SNOMED for non-numerical results including microbiology Will require upgrade of most existing interfaces Laboratory Orders Interface Laboratory Results Interface

22 Report Layout and Styling No style or layout information in routine OBX segment; reports are fragmented into separate lines Possibilities for styled reports RTF formatted text Marked up text (e.g., xhtml) PDF HL7 v. 3 clinical documents (XML, allows structured data) Send as HL7 v. 2 messages using OBX field 5 or MIME attachments? HL7 v. 3 interface? Both sending and receiving systems must be able to handle the messaging strategy Receiving system must be able to display the results

23 Goals for HL7 Version 3 Substantially reduce interface development time Clarify spec for messages Fully-defined information model for messages Method for conformance specification Support modern communications infrastructures Reference Information Model (RIM) Coherent shared information model Includes all content of HL7 messages Provides consistency to messages across usage settings

24 HL7 RIM Reference Information Model Entities Roles Participation Acts Messaging Structured documents

25 HL7 v. 3 Status Limited uptake since 2003/4 release Most impact in clinical document arena Clinical Document Architecture (CDA) Combines structured and human-readable data Continuity-of-Care Document (CCD) RIM and derived messages require special modeling tools and are complex in practice Few interfaces exist

26 HL7 FHIR Fast Healthcare Interoperability Resources New messaging strategy initiated 2011 Simplified interoperability messages derived from the HL7 RIM, but shielding complexity Messages are aggregates of resources that represent clinical concepts (physician, patient, test, specimen) with defined data elements Individually understandable Expressed in XML with both structured data and human-readable text (xhtml) Internet-standard communications (HTTP & Atom) Currently in draft for comment Has potential to yield drop-in interfaces with both good visual formatting of reports and machine-readable structured data

27 Interface Implementation Work with vendors of both systems Define HL7 v. 2 message set Compare data element representations in both systems Build mapping tables Implement communications in vendor frameworks Test results/reports (both correct and erroneous data) Validate data display in downstream systems 2 4 weeks of analyst time, $5,000 - $20,000 HL7 interface engine, ~$200,000 plus IT staff Data mapping and message processing based on rules and scripts

28 HL7 Department of of Public Health Sciences

29 External Interfaces Local Health System LPL System Reference Laboratory HL7 Interface Engine EMR VPN VPN Community Providers Instrument Manager LIS Ancillaries & Research Systems Analyzer Analyzer Analyzer POC Devices & Base Station

30 External Interface Implementation Reference laboratories HL7 Interfaces generally available Physician offices Ambulatory EMR, increasing numbers and variety Affiliated hospitals and clinics In-patient/ambulatory EMR Laboratory-Provider Link (LPL) systems Local device or vendor service Vendor handles interfaces with multiple client systems May be available through reference laboratories Internet communications require data protection Periodic encrypted connection or VPN, access policies Business associate agreement with client and LPL

31 Interface Maintenance Immediate response to communication problems Correct and resend failed transactions Daily verification of operation Daily check of error and transaction logs Problems include bad data (e.g., unknown physician) Correct and resend failed transactions Latency measurements monthly Editing and testing mappings (new physicians, test catalog updates, locations, etc.) Revalidation of data transmission and results display biannually and after changes or upgrades

32 Evolving Interoperability Challenges Managing and synchronizing the test catalog across multiple client EMR systems (explosion of mapping tables) Mapping the test catalog correctly to LOINC Managing the progression of reporting to both structured data and better report formatting Identifying patients across multiple client EMRs Maintaining current downstream system validation when those systems change Report distribution across multiple systems Necessity for institutional collaboration on security policies

33 Take-home Points System interfaces form the crucial glue that holds multi-vendor healthcare information systems together Laboratories face interfacing challenges: Clients are moving to adopt a myriad of new EMR systems Regulations will require upgrade of current interfaces The software and information design of system interfaces is well established, but is not plug-and-play and additional standards development is underway Effective strategies to support internal and external interfaces are available Significant effort and cost involved Planning with awareness of interface basics necessary for effective use