HL7 - Whats Hot and Whats Not

HL7 What’s hot and what’s not Dr David Hay Chair New Zealand HL7 Users Group healthAlliance Enterprise Architect

Agenda HL7 and interoperability SAEAF IHE What’s hot and what’s not Last words

Interoperability “ Ability of two or more systems or components to exchange information and to use the information that has been exchanged ” [IEEE Standard Computer Dictionary: A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990] Functional Interoperability - message structure - eg HL7 v2 / CDA Semantic Interoperability - meaning - eg SNOMED, LOINC Functional interoperability Semantic interoperability

Interoperability needs standards Each/every end of the conversation needs to know what the other is saying Structural standards physical construction of the message Semantic standards what does the sender mean? Standards are really common: Mobile phones WiFi CD’s ATM’s The ‘Great Baltimore Fire’ of 1907

Everyone knows that Standards are important...

HL7 Organisation Central Organisation (US Based) with 32 International affiliates International aspect increasing in importance Many different standards driven by members / user well defined process to update standards Collaborations with other SDO LOINC IHTSDO (SNOMED) OMG (Object Management Group) IHE (Integrating the Healthcare Enterprise) openEHR 3 Working Group Meetings per year develop standards and training 2 in the US and one International Separate Educational summits focused on training

Why Health Level “Seven”? 1 Physical (hardware, Ethernet, RS232) 2 Data Link (MAC& LLC) 3 Network (switching & routing) 4 Transport (error recovery & flow control) Communication 6 Presentation (encryption) 5 Session (session set-up & termination) Function 7 Application (clinical) 7-layer ISO Communication Model

HL7 Mission To provide standards for the exchange , management and integration of data that supports clinical patient care and the management, delivery and evaluation of healthcare services. Specifically, to create flexible , cost effective approaches, standards, guidelines, methodologies, and enable healthcare information system interoperability and sharing of electronic health records .” global

the Stages of HL7 Stage 1 simple messaging - v2 multi domain Stage 2 standards in other areas decision support (arden gello) ccow ehr, phr Stage 3 common information model - v3 RIM, D-MIM, R-MIM, CMET (and all that jazz...) defined processes Stage 4 unified theory SAEAF One process to rule them all...

Stage 1 - the beginning Started 1987 - v1 1988 - v2.x (currently 2.6) Clinical input from domain experts ie knowledgeable users now have many domains lab, pharmacy, emergency care and many others point to point solutions participants agree on detailed meaning Z segments ‘ bottom up’ solution ‘ on the wire’

V2 Messaging The standard assumes that the transport will: have error free transmission will perform any character conversion not limit the message length Message Ack HL7-enabled system Receiver Data Network HL7-enabled system Sender Data HL7 Message Creation E n c o d i n g HL7 Message Parsing E n c o d i n g HL7 V2.5 Standard HL7 2.5 Standard

Segments and Fields MSH|^~\&|PATH||GP123||20070625||ORU^R01|101|P|2.5^AUS|||AL|NE|AUS||en<cr> PID|||KNEE123||Knees^Nobby^J^^Mr||19601130|M|||23 Shady Lane^LIGHTNING RIDGE^NSW^2392||||||||219171803<cr> OBR|1|PMS66666|956635.9|LFT^LIVER FUNCTION TEST^N2270<cr> OBX|1|NM|1751-7^S Albumin^LN||38|g/L|35-45||||F<cr> OBX|2|NM|1779-8^S Alkaline Phosphatase^LN||52|U/L|30-120||||F<cr> Town/Suburb DOB ID Name Gender Street Address

Stage 2 - beyond messaging Standards beyond simple messaging Conceptual EHR/PHR Functional standards SOA standards EA standards Application CCOW (Clinical Context Object Workgroup) Arden Syntax GELLO Exchange standards (V2 & V3)

Stage 3 - version 3 & the RIM Main purpose was to address deficiencies in v2 and promote semantic interoperability. V2 has: No defined development process Fields and events are described using natural language Massive reuse of segments and events leading to a lot of optionality and ambiguity V3 has: A Reference Information Model (RIM), with messages and other artifacts derived from the model A standard development methodology Story boards / Use Cases Interaction diagrams State diagrams

v3 document: CDA Most successful v3 standard has been CDA (Clinical Document Architecture) Many implementations internationally Even in New Zealand! Why? people understand documents clearly defined Implementation Guides don’t have to be an expert to use It took 2 weeks for pharmacy vendors to produce CDA dispensing documents Business focussed deals with problem domains not covered by existing messaging (eg CCD) v3 messaging is hard! do have to be an expert to use

© Alschuler Associates, LLC, 2008 12 The CDA document defined CDA Release 2 , section 2.1: A clinical document ... has the following characteristics: Persistence Stewardship Potential for authentication Context Wholeness Human readability therefore, CDA documents are not: data fragments, unless signed birth-to-death aggregate records electronic health records

From RMIM to V3 Message (CDA) Prescription classCode* <= SBADM moodCode* <= RQO id*: II [1..1] text: ED [0..1] statusCode: CS CNE [1..1] <= active Person classCode*: <= PSN determinerCode*: <= PSN id: II [1..1] name: EN [0..*] birthTime: TS [0..*]… Patient classCode*: <= PAT id*: II [1..1] addr: AD [0..1] telecom: TEL [0..*] CMET (Assigned) R_AssignedPerson [identified] (COCT_MT090101) 1..1 patient 1..1 patientLivingSubject 1..1 assignedEntity <clinicalDocument> <id extension="3000201" root="2.16.840.1.113... <statusCode code="active"/> <recordSubject> <Patient> <id extension="7658456" root="2.16.840... <addr>... <Person> <name use="L"> <given>Kevin</given> <family>de Boer</family> <birthtime value= " 19551216 " /> </name> </Person> </Patient> </subject> <author> <time value="20040427090010"/> <AssignedPerson> <id extension="120450" root="2.16... </AssignedPerson> </author>... Person Patient recordSubject typeCode*: <= SBJ author typeCode*: <= AUT time IVL<TS> EntryPoint Clinical Document id

CDA: Templates A key concept in re-usability Able to ‘mark’ a document or sections of a document to indicate that they meet a particular business requirement eg what is in a problem list, a medication list etc... Use a globally unique identifier (OID) Can ‘mix and match’ sections in a document to meet specific requirements Can freely re-use between documents Will have a template registry available in 6 months

Stage 4 - SAEAF It’s still not quite right... v3 (apart from CDA) not widely adopted actually, v3 messaging is hard! actually, interoperability (especially semantic) is hard! but, having a common model is needed for semantic interoperability... within HL7 committees, there is some duplication and disconnect There are always ignore new technologies to accommodate - eg services - SOA It’s hard to ignore real-life architectures and real-life implementations SAEAF is a new initiative to address these issues.

SAEAF - Working Interoperability Services Aware Enterprise Architecture Framework It’s not just SOA Messages, Documents, Services A Framework for creating Enterprise Architecture specifications It’s not a specification in and of itself - it’s a way to create an architecture about a particular topic Initiative to bring Enterprise Architecture disciplines to: internal HL7 standards development external users of the standards Working Interoperability Make things explicit

The ‘Lens’ of SAEAF It’s drawing on many other standards in the software industry

Specification Stack Why What How Where

IHE Integrating the Healthcare Enterprise

Standards: Necessary…Not Sufficient Standards are Foundational - to interoperability and communications Broad - varying interpretations and implementations Narrow - may not consider relationships between standards domains Plentiful - often redundant or disjointed Focused - standards implementation guides focus only on a single standard IHE provides a standard process for implementing multiple standards

An Incremental Multi-Year Project Launched in 1998 Goal: Enhance the Access to Clinical Information Ensure Continuity and Integrity of Patient Information Speed Up the Integration in Healthcare Environments Fosters Communication Between Vendors of Medical Information Technology Prove that Integration is Attainable Based on Standards Participants: Representatives of Healthcare Providers Information Systems Vendors Imaging Systems Vendors Standardization Groups The IHE Initiative

Stakeholder Benefits Healthcare providers and support staff Improved workflows Information whenever and wherever needed Fewer opportunities for errors Fewer tedious tasks/repeated work Improved report turnaround time Vendors Align product interoperability with industry consensus Decreased cost and complexity of interface installation and management Focus competition on functionality/service space not information transport space SDOs Rapid feedback to adjust standards to real-world Establishment of critical mass and widespread adoption

9 IHE Organizational Structure USA Canada Japan Korea Taiwan China Global Development Regional Deployment Contributing & Participating Vendors IHE North America IHE Asia ACC ACCE ACEP JAHIS JIRA JRS METI-MLHW MEDIS-DC JAMI RSNA SFR SFIL SIRM BIR EuroRec COCIR EAR-ECR DRG ESC Professional Societies / Sponsors ACP GMSIHIMSS IHE International Board Radiology Cardiology IT Infrastructure Patient Care Coordination Patient Care Devices Laboratory Pathology Eye Care Radiation Oncology Public Health, Quality and Research IHE Asia-Pacific New Zealand Australia Malaysia IHE Europe France Netherlands Spain Sweden UK Italy Germany Norway Austria

International Growth of IHE 10 Local Deployment National Extensions Promotional & Live Demonstration Events Funding France USA Germany Italy Japan UK Canada Korea Taiwan Norway Netherlands Spain China Austria 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 Pragmatic global standards harmonization + best practices sharing Australia

IHE Technical Frameworks Implementation Guide for each Integration Profile An Integration Profile : A Set of Actors Exchanging Transactions Use cases Process Flows For each transaction: Std referenced Options specified Mapping required Actors Transactions

IHE Scheduled Workflow Profile Registration Orders Placed Orders Filled Film Film Folder Image Manager & Archive Film Lightbox report Report Repository Diagnostic Workstation Modality acquisition in-progress acquisition completed acquisition completed images printed Acquisition Modality

IHE Connectathon Cross-vendor, live, supervised, structured tests All participating vendors’ products tested together in the same place/time Experts from each vendor available for immediate problem resolution… fixes are done in minutes, not months!! Each vendor tests with multiple trading partners (actual product to actual product) Testing of real-world clinical scenarios using IHE Integration Profiles

XDS (Cross Enterprise Document Sharing

What’s hot and what’s not? Hot HL7 v2 v3 RIM CDA and CCD Templates SAEAF IHE archetypes Not v3 messaging Not following a standard!

A shameless plug NZHUG represents the HL7 organisation in New Zealand We want to be a source of assistance for anyone developing in HL7 What help do you want ? Is there a need for training? If so, then in what? In 2011 (probably January) there will be an HL7 working group in Australia This is a wonderful opportunity to meet and greet with the international experts We can raise New Zealands profile internationally There will be training and certification opportunities

HL7 - Whats Hot and Whats Not

More Related Content

Similar to HL7 - Whats Hot and Whats Not (20)

More from Health Informatics New Zealand (20)

Recently uploaded (20)

HL7 - Whats Hot and Whats Not