Integrating the Healthcare Enterprise

1
Integrating the Healthcare Enterprise

• HL7 the essentials

Eric Poiseau Laboratoire IDM Faculté de
Médecine Université de Rennes 1
2
Overview of the Presentation

• Need for Standards in Medicine
• Why HL7 ?
• HL7 version 2.x
• Bottom-up
• Messages
• HL7 version 3
• Top-down
• CDA
• CCOW
• RIM
• Messages

3
Need for standards in Medicine

• Since the 80s, Information systems in Hospitals
• Many autonomous systems in departments
• Fulfill departments specific needs
• Many different systems from different vendors
• Need for communication between systems

4
Why do we need standardized interfaces ?

B
4 systems, 6 interfaces
C
A
B
D
5 systems, 10 interfaces
C
A
E
D
5
Why do we need standardized interfaces ?
Impossible to maintain !!!
6
Case of standardized interfaces

B
4 systems, 4 interfaces
C
A
B
D
5 systems, 5 interfaces
C
A
E
D
7
What is HL7.org ?

• HL7 Health Level Seven
• ANSI-Approved Standards Developing Organization
  (SDO)
• Not-for-profit
• More than 2200 members
• More than 500 corporate members
• Local organization in more than 27 countries
• Widely used and accepted

More than 93 of all organization in the US with
Health IT Systems use HL7
8
HL7 - History

• 1987 Interested users in the US start work on a
  standard  Health Level Seven 
• 1990 First Standard V2.1
• 1994 ANSI Accreditation
• 1999 V2.3.1 Approved as an ANSI Standard
• August 2001 V3 1st Draft is released
• June 2003 V2.5 released

9
Concepts

• The scope of HL7 is restricted to the
  specification of messages between application
  systems, and the events triggering them
• Trigger event ? an event in the real world of
  healthcare creates the need for data to flow
  among systems
• Two types of data flow
• unsolicited update/acknowledgement
• query/result

10
How the Standard Works ?

• HL7 assumes that an event in the real world of
  healthcare creates the need for data to flow
  among systems.
• A Trigger Event equates to an event in the real
  world.
• Trigger events are identified by a unique 3
  character code.

11
Sample Trigger Events

• ADT Trigger Events
• A01 Admit a Patient
• A02 Transfer a Patient
• A03 Discharge a Patient
• A08 Update Patient Info
• Order Trigger Events
• O01 Order Message
• Result Trigger Events
• R01 Unsolicited Transmission of Requested
  Observation
• Master File Trigger Events
• M02 Master File - Staff Practitioner

12
Concepts

• A message is the atomic unit of data transferred
  between systems
• Each message has a message type that defines its
  purpose
• For example, the ADT Message type is used to
  transmit portions of a patients Patient
  Administration (ADT) data from one system to
  another

13
Concepts

• There is a one-to-many relationship between
  message types and trigger event codes
• a message type may be associated with more than
  one trigger event
• A message is comprised of a group of segments in
  a defined sequence
• A segment is a logical grouping of data fields

14
Segments

• Each segment forms a line in the message.
• A segment starts with a unique three character
  identifier
• Segments may be required or optional and grouped
  within a given message
• Z segments - reserved for locally-defined messages

15
Fields

• A field is a unit of data such as a name, number,
  address, etc.
• A data field is a string of characters.
• Fields are separated by l

16
Components

• A field is made up of components
• The fields data type defines its components
• A component may itself contain components
  (sub-components)
• HL7 does not define Optional or Length at the
  component level.

17
HL7 V2.x Trigger event (example)

• Event  admit a patient  is the trigger.

Admit a patient
Data
18
HL7 V2.x Message Structure

• A message is made of segments.
• A segment is made of fields
• A field is made of component

Message
Segment
Segment
Field
Field
Field
Field
Field
Field
19
ADT A01 Message Segments

• MSH
• SFT
• EVN
• PID
• PD1
• ROL
• NK1
• PV1
• PV2
• ROL
• DB1
• OBX
• AL1
• DG1
• DRG

• PR1
• ROL
• GT1
• IN1
• IN2
• IN3
• ROL
• ACC
• UB1
• UB2
• PDA

20
Sample ADT Message

• MSH\ST01ACM01A1994091310500102ADTA010
  02988538062171P2.21
• EVNA01199409131050
• PID88888EMI Primary99999LABU6123456Hows
  erDoogieBJr.SirPhDBabasafa1961
• 0521MaleHowserDogBrace123 Looney Toon
  WaySte 123Toon TownCA95403USAHome(707)578-
  4098(707)541-
• 2583EnglishMCatholic3444-55-
  6666555555555CAMothersIdentifierethnicModesto
  N1USA
• NK1BelleClaraASister123 Toon Tower
  RdToon
• TownCA95403USAB(707)538-9141(707)234-
• 1234Emergency1995082619950830DaycareDC434-3
  2-1232Toon Daycare
• NK1BelleBruceABrotherContact19950826
  19950830DC
• PV1Inpatient/Acute1ESTROOM2BEDAFAC01Aafl
  avFlavershumAlexander
• Dr.200SmuckShirleyDr.MEDICINE/CARDIOLOG
  Y0003
• 199508261025199508301050
• DG1ICD910.1Hopeless Diagnosis199508271035Adm
  itting
• AL1FAALCODEAllergic to Roadrunners10Sneezing
  
• GT1Acme Insurance100 Looney StreetDisney
  DistrictToon
• CityCA90505USA(709)333-3333(709)444-
• 4444Self1994010119980101McKessonHBOC123
  Employer
• AddressAddress Line 2Toon CityCA90505USA(70
  7)555-55551

21
HL7 V2.x Data Types
22
XAD - Address

• ltstreet address (ST)gt
• lt other designation (ST)gt
• ltcity (ST)gt
• ltstate or province (ST)gt
• ltzip or postal code (ST)gt
• ltcountry (ID)gt
• ltaddress type (ID)gt
• ltother geographic designation (ST)gt
• Example
• 123 Looney Toon WayDisney District Toon
  TownCA95403USAHome1st Flr

23
CE - Coded Element

• ltidentifier (ST)gt
• lttext (ST)gt
• ltname of coding system (ST)gt
• ltalternate identifier (ST)gt
• ltalternate text (ST)gt
• ltname of alternate coding system (ST)gt
• Example
• F-11380CREATININEI921485CREATININELN

24
HL7 V3

• V2.x Bottom-up approach
• V3 Top-down approach
• HL7 version 3.0 consists of
• a messaging standard and
• an information model (the RIM)

25
Reference Information Model (RIM)

• The RIM defines and relates all data that exist
  for HL7.
• It defines the world of healthcare data.
• It makes functional silos obvious.
• It promotes the discovery and resolution of
  functional overlaps in data definitions and
  models.
• It provides for integration of additional
  functionality through
• abstraction and reuse
• careful addition of new items

26
Characteristics of the HL7 RIM

• It is a consensus view of the healthcare
  universe.
• Nothing exists outside it, or isolated from it.
• That's why it is a Reference Information Model.
• It provides flexible structures, rather than
  isolated detailed data elements.
• It emphasizes the semantics of health care
  information
• rather than syntax and technology architectures
• It melts the vertical silos into a coherent
  whole.
• Is a work in progress.
• Can be used with other technologies
• XML, databases, CorbaMed, etc.

27
Reference Information Model (RIM)
28
CCOW

• CCOW specifies the HL7 Context Management
  Architecture (CMA).
• Developed by the HL7 Clinical Context Object
  Working Group (CCOW), it enables multiple
  applications to be automatically coordinated and
  synchronized in clinically meaningful ways at the
  point-of-use.

29
CCOW Example Patient Link
Nancy Furlow
30
Clinical Document Architecture (CDA)

• Formely known as the Patient Record Architecture
  (PRA)
• Provides an exchange model for clinical documents
  (such as discharge summaries and progress notes).
  
• CDA brings the healthcare industry closer to the
  realization of an electronic medical record. CDA
  was approved as an ANSI Standard in November
  2000.

31
HL7 Version 2 vs. Version 3
32
Thanks

• More information on
• http//www.hl7.org
• http//www.ihe-europe.org