the Future 4 HL7 v2 into the future - RCPA

37
HL7 Australia – May 2019 Andrew McIntyre – Medical-Objects

Transcript of the Future 4 HL7 v2 into the future - RCPA

HL7 Australia – May 2019

Andrew McIntyre – Medical-Objects

Some History’ 1979 University of California San Francisco

’ Developed precursor’ In production in 1981

’ 1988 ASTM standard for Lab machines’ Clem McDonald (Medical Computer Science Research,

Indiana University School of Medicine), Ed Hammond (Division of Medical Informatics, Duke University) and Don Simborg involved

’ 1987 First HL7 Working Group – informal’ Imported much of ASTM - HL7V1

HL7 Defines Application Layer’ 1988 – First Connectathon HL7V1

Now a Standards Organization’ 1988 HL7V2.0’ 1990 HL7V2.1’ 1992 Dutch HL7 Organization’ 1992 German HL7 Organization’ 1997 English HL7 Organisation’ 1998 Standards Australia IT-14 involvement’ 1999 HL7V2.3.1’ 2002 HL7 Australia established

HL7v3’ 1995 – start of work

’ Influenced by xml’ Object orientation’ Formal methodology

’ First standard published 2005’ Use limited’ Most would agree has failed’ CDA loosely related

’ Lacks the level of modelling

HL7 V2 basics’ Text based Format (ASCII only initially and still so in Australia)’ Each Line is a Segment

’ eg MSH, PID, OBR’ Segments defined by message structure definition

’ Segment divided into fields using “|”’ Fields can repeat using “~”’ Fields have datatypes’ Fields have components using “^”’ Components have Subcomponents using “&”’ No field names, use field position’ Huge advance on Fixed width formats that preceded it’ Predates XML’ Limited Depth’ Delimiters must be escaped using “\”’ Highly backward compatible in design and practice

Example HL7V2 Message

Message StructureORU^R01 Observational Results (Unsolicited) MSH Message Header { [ PID Patient Identification [PD1] Additional Demographics [{NK1}] Next of Kin/Associated Parties [{NTE}] Notes and Comments [PV1 Patient Visit [PV2]] Patient Visit - Additional Info ] { [ORC] Order common OBR Observations Report ID {[NTE]} Notes and comments { [OBX] Observation/Result {[NTE]} Notes and comments } {[CTI]} Clinical Trial Identification } } [DSC] Continuation Pointer

Design Decisions’ Message parsed generically’ Custom parser required

’ Reflects tooling of its time’ Highly space efficient (< 10% of other formats)’ Low latency, cheaper storage, less memory used

’ Metadata dependant for meaning’ Maximal data set – no extensions**

’ Liberal addition of data elements if need demonstrated’ Contrasts with FHIR 80% rule and use of extensions

’ Means localisations require restriction vs Extension’ Tooling effort hijacked by HL7V3 work

Health Messaging in Australia’ PIT Pathology Information Transfer

’ Developed by QML and S&N in Brisbane in 1990s’ Transmitted via dialup’ Display orientated Text format

’ In late 1990s decision made to move labs to HL7v2’ Australian Standards developed AS4700.2’ Some labs still using PIT, but HL7V2 in widespread use’ No formal compliance program’ Still used as display format within HL7V2 messages**

’ Extensive use of ADT messages in Hospital systems’ CDA used in National systems

HL7V2 in Australia’ Majority of Lab results transmitted electronically

’ High volume usage’ Majority of Clinical messaging is HL7V2’ Despite issues its working

’ Atomic data for most results except Histology’ Display formats added for Australia usage

’ PIT ’ Provides for coloured and formatted text’ Allows inclusion of cumulative display’ Simpler to process’ Deprecated in current standard

’ PDF –currently favoured by RACP’ Display issues remain’ Large file size reduces efficiency

’ HTML’ Often not displayed with browser control’ Would be most standard and efficient format

The Present Australian Situation(2009!)

Clinical Models basic− Blob of text in single OBX− Blob of RTF (un-escaped) in single OBX− Little or No semantic interoperability− Opaque documents eg. PDF− No atomic data, minimal terminology

Pathology Models improving− Atomic data− Terminology (LOINC) in private labs− Hamstrung by unreliable imports of HL7− Many packages lack CE (Coded Entry) support

Clinical HL7v2 Messaging lives’ GP message counts >60% clinical

’ April 2019’ Sunshine Coast PHN: 203,000’ SE Queensland: 615,000

’ March 2019’ Sunshine Coast: 208,000’ SE Queensland: 627,000

’ Buderim GE Centre (outgoing clinical reports)’ April 2019 –1044’ March 2019 – 1002’ We have virtually eliminated paper copies.

HL7 V2.3.1 turns 20 this year!

MSIA Project – The issues’ Collaborative effort to define issues with HL7V2

’ Document produced 2011, no action’ The major issue with messaging interoperability working

’ NEHTA asked to take action by messaging vendors’ Issues relate to quality of messages, not standards

’ Escaping reserved characters’ Display of FT in fixed width font’ Display of html/PDF/PIT segments poor’ Non unique message/document IDs’ Poor understanding of HD values eg Author vs Sender’ Lack of recognition of clinical area of reports eg Clinical vs lab’ Lack of suitability of individual provider identifiers – not location

specific’ Non standard Addressing’ etc

Messages vs Documents’ Messages are transient and used once

’ Can transmit documents or events/orders etc’ Documents persist in legal and practical sense

’ Eg you receive a report in a message but keep the document’ HL7V2 does not separate concepts in documentation

’ OBR is report header and contains document’ OBX contains report contents

’ PID identifies patient’ Same document can be sent in may message types

’ Eg ORU, ORF, REF, ORM’ It is possible to identify document part and digitally sign it

’ Exclude MSH (Message Header components)

Digital Signatures in HL7v2

Signature Evaluated during display

EN 13606’ Allows Clinical Models to be defined’ Can be used for templating in HL7v2’ Sits above the HL7v2 standard

’ Messages remain compliant’ In use in Australia

’ Clinical reports’ Lab reports’ Handled by PMS systems

’ Largely ignore the additional structure

Example Archetypes

OBX Tree Structure• Only nodes that are valued need inclusion• Missing nodes inferred by Archetype• Requires receiver to have access to

archetype for Semantic interoperability

Walking the path

OBX|6|NM|163031004^diastolic^SNOMED-CT^at0005^^openEHR-EHR-OBSERVATION.blood_pressure.v1|1.1.1.1.1.1.1.1.2|100|mm[

Virtual Medical Record’ Allows abstracting a summary record’ Independent of the final message format used’ Allows common logic to be applied for Clinical Decision Support

Virtual Medical Record

Uses Templates

Structured Cancer Reporting

HL7 V3 Pedigree Model

Pedigree Model in HL7V2

Gello’ Standard updated 5 years ago’ Reaffirmed as HL7 Standard

Genetic Risks can be calculated

GLIF: Guideline Interchange Format’ Was the reason GELLO created

’ Never progressed by HL7

GLIF and GELLO in FHIR Smart App

Disadvantages of V2’ Requires custom parser

’ Open source versions available’ Is not trivial to do correctly – requires CS training’ Often done badly when no testing or governance

’ Viewed as old hat’ V3 was replacing it for 20 years and failed’ Has persisted despite this

’ Limited education of users ’ Not human interpretable (in under years of use)’ Clinical Models basic

’ Need additional templates -?Advantage

Advantages of V2’ Widespread usage

’ Most systems have a HL7V2 interface’ Virtually all electronic pathology/radiology in Australia

’ Lightweight’ Low memory usage’ Efficient storage (15 years of Practice in 50mb!)’ Fast parsing, faster encryption’ Low Latency

’ Backward compatibility by design’ Well proven administrative Model’ Powerful clinical models possible with external templating

The Future’ HL7V2 is not going away

’ Huge investment in Labs and ADT messaging’ Widespread support by receiving applications’ High cost of changeover

’ Likely to coexist with FHIR’ FHIR much easier for web developers’ New areas

’ Lack of governance wrt standards compliance’ A problem that persists’ Clinical safety issues being ignored’ Useful Clinical Decision support possible with better compliance

’ Would not require major investment’ Significant extension possible with Templating

’ Clinical data models are not widespread or standard currently’ Allows add hoc templating with backward compatibility

’ This is best way to progress clinical templates