• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
HL7 Interface
 

HL7 Interface

on

  • 2,858 views

 

Statistics

Views

Total Views
2,858
Views on SlideShare
2,846
Embed Views
12

Actions

Likes
8
Downloads
0
Comments
0

1 Embed 12

http://www.slideshare.net 12

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    HL7 Interface HL7 Interface Presentation Transcript

    • Introduction to HL7 V2.5 Standard Tuesday, June 09, 2009 Bhaski - The Warrior Group 1
    •  Interoperability : Ability of two or systems or components to exchange information and use the information that has been exchanged [ source : IEEE Standard Computer Dictionary : A Compilation of IEEE Standard Computer Glossaries, IEEE, 1990]  Functional interoperability - Message format and content  Semantic interoperability - Terms (SNOMED-CT, LOINC), units  Service (Business) Interoperability – SOA, HISA  Vision : Plug and play (PnP) Tuesday, June 09, 2009 2
    •  Computers work by matching  Cannot handle the unexpected  Easier to send than to receive  Testing, Testing, Testing  (N2 - N)/2 = Number of interface N Benefits of Standards Tuesday, June 09, 2009 3
    •  Reduce Cost  Reduce Risk  Competition (avoidance of lock-in)  Change control (real costs of upgrades)  Quality (leveling up)  Compliance testing Tuesday, June 09, 2009 4
    •  OSI Level 7  Organization  Standards  HL7 is a Language (s)  • Syntax (Grammar)  • Semantics (Words) Tuesday, June 09, 2009 5
    •  Layer 7 - Application - network processes for application  Layer 6 - Presentation - Data Representation  Layer 5 - Session - Interhost communication  Layer 4 - Transport - End-to-end connections  Layer 3 - Network - Addresses and best path  Layer 2 - Data Link - Access to media  Layer 1 - Physical - Binary transmission Tuesday, June 09, 2009 6
    • Tuesday, June 09, 2009 7
    • Tuesday, June 09, 2009 8
    •  1988 - present (backwards compatible)  Very widely used in hospitals  Position-dependent syntax  EVN||20040627||||20040601  PID|||567890^^^CXH^PI~9999999484^^^NHS  Local tailoring of Z-segments  “If you have seen one implementation, then you have  seen one implementation” Tuesday, June 09, 2009 9
    •  Message  Segment  Field  Data Type (may repeat)  Component  SubComponent Tuesday, June 09, 2009 10
    •  MESSAGE SYNTAX  SEG –1..1  [ SEG ] – 0..1  { SEG } – 1..*  { [ SEG ] } – 0..* Tuesday, June 09, 2009 11
    •  DELIMITERS • Defined at start of MSH segment • Segment terminator is carriage return (hex 0D) | (vertical bar): field separator ~(tilde): repetition separator ^ (caret): component separator & (ampersand): subcomponent separator (backslash): escape character Always start MSH|^~&|MegaReg|XYZHospC|SuperOE| |2.5| Tuesday, June 09, 2009 12
    • 1. Introduction 11. Patient Referral 2. Control 12. Patient Care 3. ADT 13. Laboratory Automation 4. Orders 14. Application Management 5. Query 15. Personnel Management 6. Financial Management 7. Observation Reporting 8. Master Files 9. Medical Records 10. Scheduling Tuesday, June 09, 2009 13
    •  Data Definition Tables  Lower Layer Protocols  Network Management  BNF Message Descriptions  Glossary Tuesday, June 09, 2009 14
    •  HL7 V2.4, V2.5, V2.5.1(Lab test results), V2.6, V2.7(Device communication) Tuesday, June 09, 2009 15
    • Chapter 2 of the HL7 V2.x Standard Tuesday, June 09, 2009 16
    •  Defines the generic rules that apply to all messages  The Key: How to read the rest of the specification  HL7 Encoding Rules: what the !@#$ are those |^& in my data stream?  The programming procedures required to exchange all messages  Standard conformance profiling rules for message specification Tuesday, June 09, 2009 17
    •  Expects ISO OSI Level 7. If not, lower level protocols are available: Ad hoc w/o basic transport (RS-232) – LLP Robust export but not level 7(TCP-IP)-MLLP  Expects the following: Error free transmission Character conversion No assumed maximum message length Tuesday, June 09, 2009 18
    • Tuesday, June 09, 2009 19
    • Tuesday, June 09, 2009 20
    •  A real world event that necessitates an exchange of information. Tuesday, June 09, 2009 21
    •  An atomic unit of data transferred between systems.  A Message Type defines its domain.  A Trigger Event defines the reason for the exchange. Tuesday, June 09, 2009 22
    •  A 3-character code contained within each message that identifies its type or domain. Tuesday, June 09, 2009 23
    •  One message type can have many different trigger event codes.  A trigger event code may not be associated with more than one message type. Tuesday, June 09, 2009 24
    •  A message is comprised of a group of segments in a defined sequence. Tuesday, June 09, 2009 25
    •  Information about the message (MSH)  Information about the patient PID, AL1, PV1)  Information about the order (ORC, order detail segment, OBX, BLG) Tuesday, June 09, 2009 26
    •  Segments of a message: are identified by a unique three character code known as the Segment ID. Can be required MSH is ALWAYS required!  May be optional [..]  May repeat {…} Tuesday, June 09, 2009 27
    •  A logical grouping of data field PID segment Definition (Partial) Tuesday, June 09, 2009 28
    •  SEQuence – the order of an element within the segment  Max LENgth  Data Type  OPTionality:  R - Required - Too few of these!  O- Optional- Too many of these !  C- Conditional-Based on what?  X- Don’t use  B- Retained for backwards compatibility  W-Withdrawn Tuesday, June 09, 2009 29
    •  RP/# = Repetition:  N-No or Y-Yes; may designate number of repetitions  TBL# = Table Number  A unique identifier for a table of values used by the data element  HL7 defined values  User defined values  Externally defined values  ITEM# - a unique identifier for the HL7 data element  ELEMENT NAME Tuesday, June 09, 2009 30
    • Messages are made up of segments which are made up of fields which may have components which may have sub-components. Tuesday, June 09, 2009 31
    •  An HL7 field is a set of characters defined by an HL7 data type. For example, marital status. PID.15 (data type CWE) Tuesday, June 09, 2009 32
    •  A field entry may also have parts called components. For example, the patient’s name has components such as last name first name middle name or initial  Components may be further divided into sub-components. Tuesday, June 09, 2009 33
    • Tuesday, June 09, 2009 34
    •  To determine the exact representation of an abstract message, one applies the HL7 encoding rules defined in Chapter 2 to the abstract definition from the functional chapter (example - Chapter 3, Patient Administration). Tuesday, June 09, 2009 35
    • MSH|^~&|RegSys|Genhosp|LabSys|Genhosp|200812242336| Security|ADT^A01^ADT_A01|MSG00001|P|2.6|||AL|NE<CR> EVN|A01|200812242333<CR> PID|||ID12345^^^^MR~ID12345001^^^^AN~123456789^^^^SS|| Jones^William^A^III||19810615|M||C| 1200 N. Elm St.^Greensboro^NC^27401-1020|GL| (919)555-1212|(919)555-3434||S||ID12345001| 123-45-6789|987654^NC<CR> NK1|Jones^Barbara^K|Wife<CR> PV1|1|I|2000^2012^01||||004777^Lieber^Sidney^J.|||Sur<CR> Tuesday, June 09, 2009 36
    •  In a message certain encoding characters delimit the constructs.  The Segment Terminator <CR>  The Field Separator |  The Component Separator ^  The Sub-Component Separator &  The Repetition Character ~  The Escape Character Tuesday, June 09, 2009 37
    •  The Encoding Characters are specified immediately following the segment ID in the MSH Segment.  With the exception of the segment terminator, delimiter values are at the discretion of the sender.  Most senders use the suggested values. Tuesday, June 09, 2009 38
    •  The HL7 field separator marks the beginning of a data field within an HL7 segment.  It always follows the segment ID to indicate the first data field in the segment. | Tuesday, June 09, 2009 39
    •  Used to separate adjacent components within a field.  The data type defines whether a field has components. ^ Tuesday, June 09, 2009 40
    •  Used to separate occurrences of a repeating field.  The “repetitions” are of a common structure (like rows in a database) defined by the data type. The content of each repetition may be (and usually is) different. ~ Tuesday, June 09, 2009 41
    •  Used in alphanumeric fields defined by data types ST, TX or FT  Used for highlighting  Used to escape the other delimiters  Used for hex character representation  Must both precede and follow the character(s) being escaped Tuesday, June 09, 2009 42
    • Tuesday, June 09, 2009 43
    •  Used to separate adjacent subcomponents.  The data type defines whether the components of a field have subcomponents.  When a component of a data type is itself a data type with components, its parts will be expressed as subcomponents of the full data type. & Tuesday, June 09, 2009 44
    •  Is the last character of EVERY segment.  Is ALWAYS the ASCII CR character (hex 0D).  Is NEVER omitted.  Can NEVER be changed. <CR> Tuesday, June 09, 2009 45
    • Tuesday, June 09, 2009 46
    • Tuesday, June 09, 2009 47
    • Tuesday, June 09, 2009 48
    •  If components, subcomponents, or repetitions at the end of a data field are ‘not present’, their separators may be omitted If no more fields are present in a segment, the data field separators may be omitted Padding doesn’t violate the rules, it’s just not good practice! Tuesday, June 09, 2009 49
    •  End each segment with the REQUIRED segment terminator Tuesday, June 09, 2009 50
    •  Rule 1: Ignore the unexpected  Rule 2: If it’s not there, assume it’s not present. Tuesday, June 09, 2009 51
    •  Ignore segments, fields, components, subcomponents, and repetitions of a field that are present but not expected. Tuesday, June 09, 2009 52
    •  Treat fields, components, subcomponents, and repetitions that are expected but not sent as not present.  DON’T break the interface  DO return an ERR segment in the acknowledgment message for each required field that is missing  Treat segments that were expected but not sent as consisting entirely of fields that were not sent.  Example: If the PR1 procedure segment is not sent on a discharge, assume that procedure info is not present - do NOT assume it’s NULL. Tuesday, June 09, 2009 53
    •  New messages may be introduced in subsequent versions.  New segments may be introduced and placed anywhere in an existing message structure in subsequent versions.  In subsequent versions new F/C/S/R - can only be introduced at the end of a segment, field, component, or repetition list.  Data types can only be extended in subsequent versions by adding components to the end.  Non-repeating field can become repeating, but first repetition meaning should remain the same. Tuesday, June 09, 2009 54
    •  Retained for backwards compatibility only” designates fields no longer recommended for use, but retained as place holders. These fields may need to be valued to support prior versions.  Obsolete message elements may be withdrawn when they are no longer referred to by other parts of the Standard: e.g., superseded data types such as CE. Tuesday, June 09, 2009 55
    • Data Types Tuesday, June 09, 2009 56
    • Here are the ones that occur most frequently:  Alphanumeric (ST TX FT SRT)  Numeric (CQ MO NM SI SN)  Identifier (ID IS HD EI RP PL PT  VID)  Date/Time (DT TM DTM)  Coded Values (CF CN CX XCN  CNE CWE)  Demographics (XAD XPN  XON XTN SAD FN)  Price Data (CP)  ADT/Finance (FC)  Extended Queries (QSC QIP RCD)  Master Files (DLN JCC VH)  Medical Records (PPN)  Time Series (DR RI SCV TQ) Tuesday, June 09, 2009 57
    • Tuesday, June 09, 2009 58
    •  Original Mode  Application Level Acknowledgements  Version 2.1  Enhanced Mode  Accept and Application Level Acknowledgements  Version 2.2+ Tuesday, June 09, 2009 59
    •  Original Mode (only mode in V2.1)  Application acknowledgment only Tuesday, June 09, 2009 60
    •  Enhanced Mode (available in V2.2 and later)  Allows accept/commit and application acknowledgments  Supports interface engine use cases Tuesday, June 09, 2009 61
    • Tuesday, June 09, 2009 62