hl7 wkslp

The HL7 Messaging StandardCurrent and Future Directions

Mike HendersonPresident, Eastern Informatics, Inc.

2001 Annual HIMSS Conference and Exhibition

© 2001 Healthcare Information Management and Systems Society

2/4/20012001 Annual HIMSS

Conference and Exhibition 2

The HL7 Messaging Standard

Learning objectives

! Overview of clinical interfacing! Data types and message formats

used in the current HL7 standard! The HL7 Version 3 Message

Development Framework! Usages in HL7 of various encoding

rules including XML for message formatting




Overview of clinical interfacing

! History of clinical computing and interfacing

! The beginnings of messaging standards

! Introductory summary of HL7




History of clinical interfaces

! Uses of computers as medical data repositories since 1950’s! Administration! Billing! ADT! Clinical information




History of clinical interfaces! Issues with computers

! Expense (large)! Size (ditto)! Point-of-care practicality (im)! Interfaces (batch)! Data timeliness (non-real)! Administrative priorities

(elsewhere)! Clinicians’ familiarity (not

much)





! Real-time interactive computing! Dr. Octo Barnett devises MUMPS at

Massachusetts General Hospital in mid 1960s

! Language now known as M! Infrastructure aka M Technology




History of clinical interfaces! Strengths of MUMPS

! Ran on smaller “minicomputers” (DEC PDP/11)

! User instruction set built around native data structure

! Compact, interpreted code – no waiting for compilation

! Evolved to be relatively platform-independent! ANSI standard language! Still in use today in medical and non-medical

applications (InterSystems’ CACHÉ)





! What MUMPS didn’t do! Support logical database design (at

least not as well as hoped)! Enforce database integrity! Address clinical vocabulary issues! Define high-level data interchange

formats between systems





! Data interchange?! Many medical centers were minimally

computerized or non-computerized• Single administrative system, if any• Much clinical work (lab tests, procedures)

performed and recorded manually

! Laboratory automation and biomedical computing were on separate tracks from administrative computing




History of clinical interfaces! De facto standard:

sneakernet! Results recorded manually

or by instruments! Transcribed into data

processing systems• Punch card• Paper tape• Terminal





! Manual transcription issues! Timeliness! Accuracy! Consistency! Usefulness




History of clinical interfaces! Identified need: automated results

interfaces between systems! Recognized source: data generating

systems (e.g., laboratory instruments)! Recognized destination: medical center

mainframe computer• Minicomputer adoption would take 10+

years

! Automated order entry interface not yet in the picture

• This would take even longer





! Hardware interfaces ca. 1970! Batch

• Punch cards• Paper tape• Magnetic tape

! Real-time• Cable




History of clinical interfaces! Real-time hardware

interfaces ca. 1970! Proprietary cabling! Coaxial cables, bisynchronous

protocols (mainframe)! RS-232, asynchronous

protocols (mini)! Decisions largely driven by

instrument vendors





! Software interfaces ca. 1970! Proprietary data formats! Generally vendor driven! Generally incompatible between

vendors! Not much influence from programming

languages such as MUMPS• Important exception: Delimited data





! Software interfaces ca. 1970! Bottom line

• Virtually every interface required custom programming

• Format and content had to be negotiated between vendor and institution

• Fixed lengths and size restriction constraints

• 2-digit years




The beginnings of messaging standards

! A laboratory data solution: ASTM 1238! Developed by Dr. Clement McDonald in

1970’s and onward! Used to transmit laboratory order and

results information from instruments to central systems

! Still in use today





! A laboratory data solution: ASTM 1238! Permitted agreement on

formats for times, units, numbers, codes

! Did not require fixed-length records





! ASTM 1238-type messageH^headerdata1^headerdata2…P^patientdata1^patientdata2…O^orderdata1^orderdata2…R^1^result1data1^result1data2…R^2^result2data1^result2data2…

! Each line represents a record





! Mmm, tastes just like MUMPS!! Like MUMPS, ASTM 1238

popularized the use of the variable-length record with ^ (caret) as a field delimiter





! Other interfacing standards development! DICOM (radiology)! X12 (financial transactions)! ACH (banking)





! Drawbacks to other standards! DICOM

• Limited to radiology• Originally required proprietary cabling

! X12 and ACH weren’t suitable for clinical data

! ACH used fixed-length fields





! 1980’s: HL7 is developed! Original developers

• Regenstrief Institute• Duke University• University of Virginia• Mayo Clinic• Many others





! 1980’s: HL7 is developed! Formats resemble ASTM 1238 (not

surprising)! Accommodates more kinds of data than

just laboratory results• Recognizing integration of administrative

and order entry systems with the clinical data repository




Introductory summary of HL7! What is HL7?

! A balloted standard for electronic exchange of health care related information

! An American National Standards Institute accredited standard

! A volunteer organization to develop and refine the HL7 standard

! Level 7 of the Open Systems Interconnection model




Introductory summary of HL7

! What HL7 isn’t! A physical

communication protocol

! A magic wand! A fully defined

specification





! Seven what?! The “7” in “HL7” refers to the top, or

application, layer of the Open Systems Interconnection series of communications protocols

! There’s no HL1 through 6! Other standards are used for lower

layers• Presentation (e.g., Windows, Motif)• Transmission (e.g., TCP/IP, DCOM)• Connection (e.g., Ethernet)• others





! HL7 Standard status! Current version (published November

2000) is 2.4! Current version will continue to be

refined and extended! Object oriented version 3.0 prototype

to be available in 2001





! HL7 structure! Messages and trigger events! Segments! Data fields! Data types and components





! Messages and trigger events! Based on activities in the health care

world! Activities create the need for

information flow! Examples:

• ADT^A01 - Admit a patient• OML^O21 - Order a lab test• ORU^R01 - Post a lab test result




Introductory summary of HL7! Segments

! Building blocks of messages! Correspond to records in ASTM 1238! Contain related information! Used in many different types of messages! Examples:

• MSH - Message header• PID - Patient identification• ORC - Order information• OBX - Observation/result information




Introductory summary of HL7! Fields

! Building blocks of segments! Define the information carried in the message! Must be one of the predefined data types! Examples:

• MSH-3 - Sending application• PID-5 - Patient name• ORC-12 - Ordering provider





! Data types and components! Specify the exact format of data fields! Can be complex! Are a pre-defined set for all messages! Examples:

• ST - Data string • IS - Coded value• TS - Time stamp





! Looking at a message! Message

delimiters! Message syntax

ADTÂ01ADTÂ01ADTÂ01ADTÂ01 ADT MessageADT MessageADT MessageADT MessageMSH Message HeaderEVN Event TypePID Patient Identification[PD1] Additional Demographics[ { NK1 } ] Next of Kin /Associated PartiesPV1 Patient Visit[ PV2 ] Patient Visit - Additional Info.[ { DB1 } ] Disability Information[ { OBX } ] Observation/Result[ { AL1 } ] Allergy Information[ { DG1 } ] Diagnosis Information[ DRG ] Diagnosis Related Group[ { PR1 Procedures[{ROL}] Role}]




Introductory summary of HL7! Looking at a message

Patient William A. Jones, III was admitted on July 18, 1988 at 11:23 a.m. by doctor Sidney J. Lebauer (#004777) for surgery (SUR). He has been assigned to room 2012, bed 01 on nursing unit 2000.

MSH|^~\&|ADT1|MCM|LABADT|MCM|198808181126|SECURITY|ADTÂ01|MSG00001|P|2.3.1|<cr>

EVN|A01|198808181123198808181123198808181123198808181123||<cr>

PID|1||PATID1234^5^M11ÂDT1^MR^MCM~123456789^^ÛSSSA^SS||JONEJONEJONEJONES^WILLIAMÂÎIIS^WILLIAMÂÎIIS^WILLIAMÂÎIIS^WILLIAMÂÎII||19610615|M||C|1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434||S||PATID12345001^2^M10ÂDT1ÂNÂ|123456789|987654^NC|<cr>

NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr>

PV1|1|I|2000^2012^012000^2012^012000^2012^012000^2012^01||||004777^LEBAUER^SIDNEY^J.004777^LEBAUER^SIDNEY^J.004777^LEBAUER^SIDNEY^J.004777^LEBAUER^SIDNEY^J.|||SURSURSURSUR||||ADM|A0|<cr>





! Messaging roles for the new millennium! Communicating systems assume roles

in pairs• Placer – filler• Generator - tracker

! Usually a client-server relationship • Peer-to-peer relationships are not generally

assumed, although they may exist• May be multi-tiered and multi-participant





! Messaging roles! Placer - filler

• Protocol• Source system makes request of destination• Destination acknowledges request to source

• Acknowledgement always expected

• Uses• Orders• Scheduling/ADT requests• Queries and subscriptions





! Messaging roles! Generator-tracker

• Protocol• Source system provides information• Destination system may acknowledge receipt

• Acknowledgement not expected in all instances

• Uses• Results• Subscription fulfillment• Query responses




Introductory summary of HL7! Clinical and administrative domains

! Laboratory! Radiology! Appointment scheduling! ADT! Pharmacy! Immunization! Blood bank! Anatomic pathology




Data types and message formats used in the current HL7 standard

! Message structures! Encoding of messages! Data types! Messages within domains




Message structures

! Overall structure rules prescribed by HL7 Chapter Two, Control

! Application domain structure rules prescribed by “content chapters”! Patient Administration (3)! Orders (4)! Query (5)! others




Message structures

! Each message is divided into segments! Each segment corresponds to one line

of the message! All messages begin with a Message

Header (MSH) segment• Gives general sender, receiver, and

protocol information, possibly including encoding data




Message structures! Example message definitionORU^R01 Observational Results (Unsolicited) ChapterMSH Message Header 2{[PID Patient Identification 3[PD1] Additional Demographics 3[{NK1}] Next of Kin/Associated Parties 3[{NTE}] Notes and Comments 2[PV1 Patient Visit 3

[PV2]] Patient Visit - Additional Info 3]{[ORC] Order common 4OBR Observations Report ID 7{[NTE]} Notes and comments 2{[OBX] Observation/Result 7{[NTE]} Notes and comments 2

}{[CTI]} Clinical Trial Identification 7

}}[DSC] Continuation Pointer 2




Message structures

! Example messageMSH|^~\&|LIS.FLEXILAB52|HI|CIS|HI|200008171101||ORU^R01|44

75|P|2.3.1|||AL|NE||

PID|||301836900017^^^1||Henderson^Mike^M||19510901|F|||555OAK ST^WAIKIKI^HI^91188||(626) 555-9988|

PV1||O|||

ORC|RE|r833376666kj^CIS|r833376666kjM1234^1|||||||||301836900013^Henderson^Mike^P^^^^^1||(510) 267-2000|||

OBR||r833376666kj^CIS|r833376666kjM1234^1|AST^AST(SGOT)|||20008171100|||||||20008171100||301836900013^Henderson^Mike^P^^^^^1||||M1234||20008171100||HM|F||^^^^^R|

OBX|1|NM|AST^AST(SGOT)||35|5-45|F||




Message structures

! Encoding of messages! The “cosmetic” syntax of the message! Not prescribed by the HL7 standard! In practice, ER/7 is used for HL7

Version 2 messages! XML generally will be used for HL7

Version 3 messages




Data types

! Philosophy! Examples




What is a data type?

! An attribute of a data field! The data type is used to

! Characterize information! Validate information! Associate related information




What is a data type?

! A data type may consist of! Values! Attributes

• A component or field containing attributes is generally associated with another (generally previous) component or field containing values




Types of types

! Simple! Values with understood constraints (if

any)! Identifiers from understood tables

! Complex! Coded values and code sets! Alpha/numeric values and attributes! Multiple associated values and

attributes




Our sample message

MSH|^~\&|LIS.FLEXILAB52|HI|CIS|HI|200008171101-1000||ORU^R01|4475|P|2.3.1|||AL|NE||


PV1||O|||

ORC|RE|r833376666kj^CIS|r833376666kjM1234^1|||||||||301836900013^Henderson^Mike^P^^^^^1||(510) 267-2000|||

OBR||r833376666kj^CIS|r833376666kjM1234^1|AST^AST(SGOT)|||200008171100-1000|||||||200008171100-1000||301836900013^Henderson^Mike^P^^^^^1||||M1234||200008171100-1000||HM|F||^^^^^R|





MSH segment definitionSEQ LEN DT OPT RP/# TBL# ITEM # ELEMENT

NAME1 1 ST R 00001 Field Separator2 4 ST R 00002 Encoding Characters3 180 HD O 0361 00003 Sending Application4 180 HD O 0362 00004 Sending Facility5 180 HD O 0361 00005 Receiving Application6 180 HD O 0362 00006 Receiving Facility7 26 TS O 00007 Date/Time Of Message8 40 ST O 00008 Security9 7 CM R 0076

0003 00009 Message Type10 20 ST R 00010 Message Control ID11 3 PT R 00011 Processing ID12 60 VID R 0104 00012 Version ID13 15 NM O 00013 Sequence Number14 180 ST O 00014 Continuation Pointer15 2 ID O 0155 00015 Accept

Acknowledgment Type16 2 ID O 0155 00016 Application

Acknowledgment Type17 2 ID O 00017 Country Code18 16 ID O Y 0211 00692 Character Set19 60 CE O 00693 Principal Language Of

Message20 20 ID O 0356 01317 Alternate Character

Set Handling Scheme




Data type ST

! Simple string! Any printable 7-bit ASCII data, i.e.,

between 0x20 and 0x7E! To send delimiter characters as

literals outside MSH-1 and MSH-2, use escape sequences




Data type IS

! Coded value for user-defined tables! Table number appears in segment

definition, not in message! (Example table: 0361 -

Sending/receiving application)

! Example field: PID-8-sex




Data type ID

! Coded value for HL7-defined tables! Table number appears in segment

definition, not in message! (Example table: 0301 - Universal ID

type)

! Example field: MSH-15-accept acknowledgment type




Data type HD! Hierarchic designator! Complex: 3 components

! namespace ID (IS)! universal ID (IS)! universal ID type (ID)

! One of two types of fields! Local with universal equivalent! Member of a universal ID set

! Example field: MSH-3-sending application




Data type TS

! Time stamp! Complex: 2 components

! date, time, timezone offset! degree of precision (for backward

compatibility only)• Example: ‘YYYYMMDD’




Data type CM

! Composite! Used for many different, custom-

built complex data types! Example: MSH-9-message type

! Message type (ID)! Trigger event (ID)! Message structure (ID)




Data type PT

! Processing type! Complex: 2 components

! processing ID (ID)! processing mode (ID)

! Example: MSH-11-processing type




Data type CE! Coded element! Complex: 6 components

! Identifier (ID)! Text (ST)! Name of coding system (ST)! Alternate identifier (ID)! Alternate text (ST)! Name of alternate coding system (ST)

! Example: MSH-19-principal language of message




Data type VID

! Version identifier! Complex: 3 components

! version ID (ID)! internationalization code (CE)! international version ID (CE)

! Example: MSH-12-version ID




Data type NM

! Numeric! Optional leading sign and

insignificant zeros+01.20 = 1.2

! Example: MSH-13-sequence number




PID segment definitionSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

1 4 SI O 00104 Set ID - PID2 20 CX B 00105 Patient ID3 20 CX R Y 00106 Patient Identifier List4 20 CX B Y 00107 Alternate Patient ID - PID

5 48 XPN R Y 00108 Patient Name6 48 XPN O Y 00109 Mother’s Maiden Name7 26 TS O 00110 Date/Time of Birth8 1 IS O 0001 00111 Sex9 48 XPN O Y 00112 Patient Alias10 80 CE O Y 0005 00113 Race11 106 XAD O Y 00114 Patient Address12 4 IS B 0289 00115 County Code13 40 XTN O Y 00116 Phone Number - Home14 40 XTN O Y 00117 Phone Number - Business

15 60 CE O 0296 00118 Primary Language




PID segment definitionSEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME

16 80 CE O 0002 00119 Marital Status17 80 CE O 0006 00120 Religion18 20 CX O 00121 Patient Account Number

19 16 ST B 00122 SSN Number - Patient20 25 DLN O 00123 Driver's License Number -

Patient21 20 CX O Y 00124 Mother's Identifier22 80 CE O Y 0189 00125 Ethnic Group23 60 ST O 00126 Birth Place24 1 ID O 0136 00127 Multiple Birth Indicator25 2 NM O 00128 Birth Order26 80 CE O Y 0171 00129 Citizenship27 60 CE O 0172 00130 Veterans Military Status

28 80 CE O 0212 00739 Nationality 29 26 TS O 00740 Patient Death Date and Time

30 1 ID O 0136 00741 Patient Death Indicator




Data type CX! Extended composite ID with check digit! Complex: 6 components

! ID (ST)! check digit (ST)! code identifying the check digit scheme

employed (ID)! assigning authority (HD)! identifier type code (IS)! assigning facility (HD)

! Example: PID-3-patient identifier list




Data type XPN! Extended person name! Complex: 8 components

! family name (ST) & last_name_prefix (ST)! given name (ST)! middle initial or name (ST)! suffix (e.g., JR or III) (ST)! prefix (e.g., DR) (ST)! degree (e.g., MD) (IS)! name type code (ID)! name representation code (ID)

! Example: PID-5-patient name




Data type XAD! Extended address! Complex: 11 components

! street address (ST)! other designation (ST)! city (ST)! state or province (ST)! zip or postal code (ST)! country (ID)! address type (ID)! other geographic designation (ST)! county/parish code (IS)! census tract (IS)! address representation code (ID)

! Example: PID-11-patient address




Data type XTN! Extended telecommunication number! Complex: 9 components

! [NNN] [(999)]999-9999 [X9999] [B9999] [C any text]

! telecommunication use code (ID)! telecommunication equipment type (ID)! email address (ST)! country code (NM)! area/city code (NM)! phone number (NM)! extension (NM)! any text (ST)

! Example: PID-13-phone number-home




Data type DT

! Date! Format: YYYY[MM[DD]]! Examples:

|200010| = October 2000|19620910| = September 10, 1962




Data type DLN

! Driver’s license number! Complex: 3 components

! license number (ST)! issuing state, province, country (IS)! expiration date (DT)

! Example: PID-20-driver’s license number – patient




Question Break #1




Messages within domains! Chapter 3 (Patient

Administration)! Chapter 4 (Orders)! Chapter 5 (Query)! Chapter 6 (Financial

Management)! Chapter 7 (Observation

Reporting)! Chapter 8 (Master Files)! Chapter 9 (Document

Management)

! Chapter 10 (Scheduling)! Chapter 11 (Patient

Referral)! Chapter 12 (Patient Care)! Chapter 13 (Clinical

Laboratory Automation)! Chapter 14 (Application

Management)! Chapter 15 (Personnel

Management)




Chapter 3 (Patient Administration)

! Purpose! Transmit new or updated demographic

and visit information about patients! Information typically entered into an

administrative system and transmitted to clinical/administrative ancillaries• Unsolicited updates (generator)• Record-oriented query responses (filler)





! Messages! ADT (62 varieties)! QRY (old-style queries)! QBP (conformance-based queries)





! Some ADT messages! Event A01: admit/visit

notification! Event A17: swap patients! Event A28: add person or patient

information! Event A39: merge person –

patient ID! Event A54: change attending

doctor! Event A60: update adverse

reaction information




Chapter 4 (Orders)

! Purpose! Provide for transmission of orders or

information about orders

! Participants! Order entry applications (placers)! Clinical ancillaries (fillers)! Others as needed (interested third

parties)




Chapter 4 (Orders)

! What is an order?! A request for

• Material• Medication• Food• Films• Linens• Supplies




Chapter 4 (Orders)

! What is an order? (cont’d)! A request for

• Services• Clinical observations• Tests• Medication and other orders




Chapter 4 (Orders)

! What is an order? (cont’d)! Usually for a specific patient! Bulk orders (e.g., floor stock) are also

accommodated




Chapter 4 (Orders)

! General messages! ORM (general order)! ORR (general response)! OSQ (order status query)! OSR (order status response)! OMG (general clinical order)! ORG (general clinical order

acknowledgment)




Chapter 4 (Orders)

! Services having specific messages! Laboratory! Dietary! Pharmacy! Supply! Vaccination




Chapter 5 (Query)! Purpose

! To allow data to be made available in one or more of several standard formats• Message-based (segment pattern)• Tabular• Display

! To allow the fulfilling system to state what parameters may be specified by the Client system




Chapter 5 (Query)

! Purpose (cont’d)! To maximize “plug-and-play”

interoperability by implementing the concept of conformance• Currently by means of a conformance

statement• Control/Query Technical Committee is

working with Conformance Special Interest Group to integrate this into the conformance profile




Chapter 5 (Query)! Messages

! QBP (query by parameter)• May include SQL or other query language if specified

in Conformance Statement

! RSP (segment pattern response)! RTB (tabular response)! RDY (display response)! QSB (create subscription)! QVR (query for previous events)! QCN (cancel query)! QSX (cancel subscription)




Chapter 6 (Financial Management)

! Purpose! To facilitate patient accounting, e.g.:

• Billing accounts• Charges• Payments• Adjustments• Insurance




Chapter 6 (Financial Management)

! Methodology! Transactions may be generated in

batch or in real time! HL7 standard includes all data in

National Uniform Billing Field Specifications

! Standard also accommodates the use of “Z” segments to meet state and other regulatory requirements




Chapter 6 (Financial Management)! Messages

! BAR (billing account transaction)• Add (event P01)• Purge (event P02)• Update (event P05)• End (event P06)• Transmit APC groups (event P07)

! QRY (generate bills query)! DSR (generate bills response)! DFT (post detailed financial transactions)




Chapter 7 (Observation Reporting)! Purpose

! To send structured patient-oriented clinical data between systems

! To associate these data in batteries of related results

! To facilitate the use of standard vocabularies, e.g.:• CPT4• LOINC™• SNOMED International




Chapter 7 (Observation Reporting)! Examples of reports

! Laboratory! 12-lead EKG! Cardiac echo! Obstetrical ultrasound! Radiology! History and physical findings! Tumor registry! Vital signs! Intake and outputs




Chapter 7 (Observation Reporting)! Methodology

! Each result is reported in its own OBX (observation/result) segment

! Each OBX segment may have its own data type, units, and reference ranges

! Definitions of status and abnormal flags are common

! Every report has an associating OBR (observation request) segment, even if the order was not automatically generated




Chapter 7 (Observation Reporting)! Messages

! ORU (unsolicited observation)! OUL (unsolicited laboratory observation)! ORF (observational report)! CRM (clinical study registration)! CSU (unsolicited study data)! PEX (product experience)! SUR (summary product experience)




Chapter 8 (Master Files)

! Purpose! To facilitate synchronization of common

reference files• Informational messages by the owning

system• Update request messages by ancillary

systems




Chapter 8 (Master Files)! Master file type examples

! staff and health practitioner master! system user (and password) master! location (census and clinic) master! device type and location (e.g., workstations, terminals,

printers, etc.)! lab test definition! exam code (radiology) definition! charge master! patient status master! patient type master! service item master





! Methodology! Limited number of explicitly defined

messages and segments! Support for use of “Z” segments to

transmit institution-specific information





! Messages! MFN (master file notification)! MFK (master file notification

acknowledgment)! MFD (master file delayed

acknowledgment)! MFQ (master file query)! MFR (master file response)




Chapter 9 (Medical Records/Information Management)

! Purpose! Current: document

management! Future: other medical

record functions, e.g.:• chart location and tracking• deficiency analysis• consents• release of information





! Philosophy! To facilitate the production of an

accurate, legal, and legible document that serves as a comprehensive account of healthcare services provided to a patient





! Assumptions! The application system is responsible for

meeting all legal requirements (on the local, state, and federal levels) in the areas of document authentication, confidentiality, and retention

! All documents are unique, and document numbers and file names are not reused

! Documents may be associated with one or more orders





! Trigger events for the MDM message! Original document notification (T01)! Original document notification and

content (T02)! Document status change notification

(T03)! Document status change notification

and content (T04)





! Trigger events for the MDM message (cont’d)! Document addendum notification (T05)! Document addendum notification and content

(T06)! Document edit notification (T07)! Document edit notification and content (T08)! Document replacement notification (T09)! Document replacement notification and

content (T10)! Document cancel notification (T11)




Chapter 10 (Scheduling)

! Purpose! Communicating various events

related to the scheduling of appointments• For services• For the use of resources




Chapter 10 (Scheduling)! Messages

! SRM (schedule request)! SRR (schedule request

response)! SIU (schedule information

unsolicited)! SQM (schedule query

message)! SQR (schedule query

response)




Chapter 10 (Scheduling)

! Examples of trigger events! Request new appointment booking

(S01)! Request modification of

service/resource on appointment (S08)! Notification of appointment

discontinuation (S16)! Notification that patient did not show

up for scheduled appointment (S26)




Chapter 11 (Patient Referral)

! Purpose! To facilitate patient referrals and

inquiries between mutually exclusive healthcare entities





! Participant examples! Primary care providers! Specialists! Payors! Government agencies! Hospitals! Labs





! Philosophy! Different entities possess (or have

access to) differing amounts of patient data

! Referrals must contain sufficient identification information to satisfy all these entities’ needs





! Messages! RQI (request patient information)! RPI (return patient information)! RPL (return patient display list)! RPR (return patient list)! RQP (request patient demographics)




Chapter 11 (Patient Referral)! Messages (cont’d)

! RQC (request clinical information)! RCI (return clinical information)! RCL (return clinical list)! PIN (patient insurance information)! RQA (request patient authorization)! RPA (return patient authorization)! REF (patient referral)! RRI (return referral information)




Chapter 12 (Patient Care)

! Purpose! To support the communication of

patient-specific data in problem-oriented records• Clinical problems• Goals• Pathway information




Chapter 12 (Patient Care)! Possible care settings

! Acute care! Clinic care! Long-term care! Residential care! Home health care! Office practices! School-based care! Community settings





! Clinical pathway! A standardized plan of care

against which progress towards health is measured





! Clinical pathway (cont’d)! Applied based upon the results of a

patient assessment! Shows exact timing of all key patient

care activities intended to achieve expected standard outcomes within designated time frames





! Clinical pathway (cont’d)! Included elements

• Documentation of problems• Expected outcomes/goals• Clinical interventions/orders





! Messages! PGL (patient goal message)! PPR (patient problem

message)! PPP (patient pathway

problem-oriented message)! PPG (patient pathway goal-

oriented message)





! Messages (cont’d)! PRR (patient problem response)! PPV (patient goal response)! PTR (patient pathway problem-oriented

response)! PPT (patient pathway goal-oriented

response)




Chapter 13 (Clinical Laboratory Automation)

! Purpose! Laboratory

information system integration (“total automation”)




Chapter 13 (Clinical Laboratory Automation)! Participants

! Automated or robotic transport systems! Analytical instruments! Pre- or post-analytical process equipment,

e.g.:• Automated centrifuges• Aliquotters• Decappers and recappers• Sorters• Specimen storage and retrieval systems





! Messages! ESU (equipment status update)! ESR (equipment status request)! SSU (specimen status update)! SSR (specimen status request)! INU (equipment inventory update)! INR (equipment inventory request)





! Messages (cont’d)! EAC (equipment command)! EAR (equipment response)! EAN (equipment notification)! TCU (test code settings update)! TCR (test code settings request)! LSU (log/service update)! LSR (log/service request)




Chapter 14 (Application Management)

! Purpose! To provide a means to manage HL7-

supporting applications over a network• Clock synchronization• Statistical aggregation• Application migration/load balancing• Application “ping”




Chapter 14 (Application Management)

! Messages! NMQ (application management query)! NMD (application management data)




Chapter 15 (Personnel Management)

! Purpose! Transmission of new or updated

healthcare administration information about:• individual healthcare practitioners• supporting staff members





! Some interesting events! Hiring and firing! Sabbaticals and leaves of absence! Role assumption and termination! Professional affiliation! Education and certification





! Trigger events for the PMU message! B01 (add personnel record)! B02 (update personnel record)! B03 (delete personnel record)! B04 (activate practicing person)! B05 (deactivate practicing person)! B06 (terminate practicing person)




Question Break #2




The HL7 Version 3 Message Development Framework

! Introduction! Principles! Managing message

development! Use case model! Information model




The HL7 Version 3 Message Development Framework

! Vocabulary domains! Interaction model! Conformance claims! Creating message specifications




HL7 V3 Message Development FrameworkIntroduction

! Systematic process for defining messages

! Follows software development lifecycle! Requirements! Analysis! Implementation





! Replaces ad hoc “methodology” of Version 2 messaging! Unclear structural relationships! Semantic inconsistencies! Heavy optionality





! Methodology! Requirements definition! Structural analysis! Behavioral analysis! Message specification





! Methodology sources! Ivar Jacobson! Rumbaugh & Booch (Unified Method)! Peter Coad! Ed Yourdon




HL7 V3 Message Development FrameworkPrinciples

! Support for legacy systems! “Open systems” conformity not

required

! Support for prior versions! Translation will be required between V3

and V2! V3 will be revised via compatible

enhancement





! Conformance determination! Application role definition, e.g.:

• Lab order sender• Lab order filler• Enterprise patient identification store

! Implementers may make conformance claims to one or more roles

! HL7 may also create conformance profiles for encoding rules, etc.





! Support for confidentiality and security! Confidentiality and integrity! Service authentication and

authorization! Non-repudiation





! Support for confidentiality and security (cont’d)! Non-repudiation

• a service that provides proof of the integrity and origin of data, both in anunforgeable relationship, which can be verified by any third party at any time

• an authentication that with high assurance can be asserted to be genuine, and that can not subsequently be refuted




HL7 V3 Message Development FrameworkManaging message development

! Constructs! Use cases, state diagrams! Reference Information Model! Interaction model! Hierarchical Message Definitions! Implementation Technology

Specifications





! Use cases, state diagrams! Provide context to the definitions of

trigger events





! Reference Information Model! Specifies information content of

messages! Clarifies definitions! Ensures that definitions are used

consistently across messages





! Interaction model! Specifies responsibilities

• For senders• For receivers





! Hierarchical Message Definitions! The exact fields of a message

• Description• Grouping• Sequence• Optionality• Cardinality





! Implementation Technology Specifications! Syntax descriptions for encoding of

messages• XML• Object-oriented• Encoding Rules/7 (“railroad tracks”)

! Different formats shall be functionally interchangable




HL7 V3 Message Development FrameworkUse case model

! Description (cf. Jacobson)! An interaction between the system and

an Actor that causes the system to fulfill a responsibility and, as a result, to produce a product of value for the Actor




HL7 V3 Message Development FrameworkUse case model

Admission

Clinical

Admit

Change Patient

Healthcare Information System

BIlling Establish Pt

Send Pt

ADT

Patient Care

Billing




HL7 V3 Message Development FrameworkInformation model

! Defines all information from which message content is drawn

! Object-oriented organization! Classes! Attributes! Associations

! Shared view across messages! Facilitates consistent definition





! Content! Classes, attributes, relationships! State-transition models (where

appropriate)! Data types and constraints





! Types of information model! Domain Information Model (DIM)

• Supports work of a specific Technical Committee, Special Interest Group, or project

! Reference Information Model (RIM)• For the collective work of HL7

! Message Information Model (MIM)• Data content of one or more messages





Logical View

Patient Physician

1

0..*has

has_pat.

Pat-Phys-Assn.

0..*

1has_phys.

seesb

PhysicianPatient

0..*

0..*has

seesa





! Class attributes! Identifier! Classifier! State





! Data types! Principal value sets for attributes! Value set relations and structures





! Data types (cont’d)! Formal representations for missing

information, e.g.:• “not present”• No information• Not applicable• Not asked• Unknown

! Constraints





! States and transitions! State

• Condition that can be tested by examining attributes and associations

! Transition• Change in state by virtue of

a change in attribute(s) and/or association(s)





Not Done

New In Progress Donecreate start

finishpurge

revise

abort

skip

redo





! Modeling activities! Construct/refine Domain Information

Model! Update/Harmonize Reference

Information Model! Construct Message Information Model




HL7 V3 Message Development FrameworkVocabulary domains

! Definition! A vocabulary domain is the set of

allowed concepts for a coded field• Note: Concept ≠ value

• M (sex/gender) = male• M (marital status) = married

! Compare with the definition of data type





! Why?! To increase semantic understanding! To enhance interoperability! To facilitate processes, e.g.:

• Direct patient care• Outcomes analysis and research• Generation of alerts and reminders• Other kinds of decision support processes





! May be extensible! To allow use of local coding schemes

! May be qualified by Realm! Political, geographical, organizational

environment





! Requirements! Unique, non-semantic identifier! Unique textual name! May have textual description! Version tracking! May be specific to Realm! Value sets come from single vocabulary

• Value set definition requires coding system context

! Value sets may be recursively defined! Set notation shows derivation of value sets





! Possible coding system examples! CPT-4! LOINC™! SNOMED International! MEDCIN! ICD-9! Read Codes! Many others!





! Vocabularies identified by OIDs (object identifiers)! Internet-like addresses, e.g.:

• 3.4.20910.240.6254441

! Applicable both to HL7-maintained and local vocabularies

! HL7-maintained vocabularies included in UMLS Metathesaurus




HL7 V3 Message Development FrameworkInteraction model

! Describes parties that interchange HL7 messages

! Describes interactions between parties

! Supports requirements definition! Facilitates conformance claims





! Steps! Identify interactions! Define interactions! Validate interactions for conformance

claims! Group interactions into sets





! Elements! Trigger events! Application roles! Interactions! Interaction sequences





! Trigger event! An occurrence causing information to

be exchanged! Derived from state models! Exception: queries

• Based upon “need to know”





! Application role! Definition of sender or receiver without

regard to functionality! Tool to analyze relationships between

messages and RIM classes! A way to define interoperable messages! Foundation for conformance claims





! Application role (cont’d)! Provides context for messaging

modes• Declarative (declarer-recipient)• Imperative (placer-filler)• Interrogative (questioner-answerer)





! Interaction! Transfer of information from sending role to

receiving role! Supported by a Hierarchical Message

Definition (HMD)! Creates a combination of

• Trigger event• Sender application role• Receiver application role• Receiver responsibility





! Interaction sequence! Multiple, coupled interactions

associated with a single trigger event! Example

• Order entry system places test order• Laboratory information system returns filler

order number

! May also facilitate transmission (broadcast) to multiple receivers




HL7 V3 Message Development FrameworkConformance claims

! Assertions that a system will! Send certain HL7 messages to other systems

that conform to certain other application roles in response to certain trigger events

! Receive certain HL7 messages from other systems that conform to certain other application roles

! Upon receipt of certain messages, perform the receiver responsibilities




HL7 V3 Message Development FrameworkCreating message specifications

! Work products! Message Information Model (MIM)! Refined Message Information Model (R-

MIM)! Hierarchical Message Definition (HMD)! Common Message Element Type

(CMET)




HL7-ConformantApplication HL7-Conformant

Application

Use Case Model

Interaction Model

HierarchicalMessage

Description

Implementation Technology

Specifications

Reference Information

Model Domain

Information Model

MessageInformation

Model

Data HL7

Message Creation

HL7 MessageParsing Data Message

Instance

ITS

RefinedMessage

Information Model

Defining a Message Structure

Sending a Message Instance

Common Message Element

Definition





! Message Information Model (MIM)! Contains RIM classes and relationships! Describes a logically connected group

of message types




Inpatient_encounter actual_day s_qty : INTestimated_days_qty : INT

Healthcare_service_providerspecialty _cd : CV

Stakeholderaddr : ADid : SET<II> phon : TEL ty pe_cd : CV

Patient_encounterencounter_classif ication_cd : CV end_dttm : TS expected_insurance_plan_qty : INTf irst_similar_illness_dttm : TSid : II start_dttm : TS status_cd : CV

Encounter_practitioner participation_ty pe_cd : CV

1..1 1..*

has_as_participant1..1 is_associated_with 1..*

Person_name cd : CV eff ectiv e_dt : TSnm : PN purpose_cd : CV termination_dt : TSty pe_cd : CV

Personadministrativ e_gender_cd : CV birth_dttm : TS citizenship_country _cd : CV deceased_dttm : TSdeceased_ind : BLethnic_group_cd : CVmarital_status_cd : CVrace_cd : CV religious_aff iliation_cd : CVv ery _important_person_cd : CV

is_f or

has 1..1

0..*

1..1

0..*

Patient_billing_account account_id : IIbilling_status_cd : CV patient_f inancial_class_cd : CV price_schedule_id : II

Patient id : IIstatus_cd : CV 0..*

1..1 inv olv es 0..* is_inv olv ed_in

1..1

1..1

0..1

takes_on_role_of 1..1

is_a_role_of 0..1

1..1

0..* has 1..1

belongs_to0..*

Individual_healthcare_practitioner id : II practitioner_ty pe_cd : CV residency _f ield_cd : CV

0..* 1..1

is_participant_f or 0..* participates_as 1..1

0..1 1..1

is_role_of 0..1

takes_on_role_of 1..1

0..1

0..*

is_the_primary _prov ider_f or 0..1

has_a_primary _prov ider 0..*





! Refined Message Information Model (R-MIM)! Constrains the MIM for use in specific

instances• Cardinality• Optionality• Vocabulary

! Direct parent of the HMD




Person_as_Patientadministrative_gender_cd : CVbirth_dttm : TScitizenship_country_cd : CVdeceased_dttm : TSdeceased_ind : BLethnic_group_cd : CVmarital_status_cd : CVrace_cd : CVreligious_affiliation_cd : CVvery_important_person_cd : CVaddr : ADid : SET<II>phon : TELtype_cd : CV

Inpatient_encounteractual_days_qty : INTestimated_days_qty : INT

Person_name_for_IHCPcd : CVnm : PNpurpose_cd : CVtype_cd : CV

Person_name_for_Patientcd : CVeffective_dt : TSnm : PNpurpose_cd : CVtermination_dt : TStype_cd : CV

Encounter_practitionerparticipation_type_cd : CV

Person_as_IHCPaddr : ADid : SET<II>phon : TEL

1..1

0..*

has 1..1

is_for 0..*

Patient_encounterencounter_classification_cd : CVend_dttm : TSexpected_insurance_plan_qty : INTfirst_similar_illness_dttm : TSid : IIstart_dttm : TSstatus_cd : CV

1..1

1..*

has_as_participant1..1

is_associated_with1..*

Patient_billing_accountaccount_id : IIbilling_status_cd : CVpatient_financial_class_cd : CVprice_schedule_id : II

1..1

0..*has 1..1

is_for0..*

Patientid : IIstatus_cd : CV1

1involves

1 is_involved_in

1

1..1

0..*

has1..1

belongs_to0..*

1..1

0..1

takes_on_role_of1..1

is_a_role_of

0..1

Individual_healthcare_practitionerid : IIpractitioner_type_cd : CVresidency_field_cd : CVspecialty_cd : CV

0..*

1..1

is_participant_for

0..*

participates_as1..1

0..1

1..1

is_role_of0..1

takes_on_role_of1..1

0..*has_a_primary_provider

0..*

is_the_primary_provider_for

0..1

One per messageinstance





! Hierarchical Message Description (HMD)! Information model mapping! Message elements! General constraints and defaults! Message type definitions




row type msg element name

in msg element type

source of msg

element type of msg element type

class Clin ical_document_header Message New type Clin ical_document_ header

attr availability_status_cd Clin ical_document_ header

Data type CV

assoc is_related_to_Authentication

Clin ical_document_ header

New type Authentication

attr authentication_dttm

Authentication Data type TS

assoc is_source_of_Healthcare_ Document_authenticator

Authentication New type Healthcare_document _authenticator

assoc is_a_Organization

Healthcare_Document _authenticator

New type Organization

attr organization_nm

Organization Data type ST

attr addr

Organization Data type ADDR

assoc is_a_subdivision_of _Organization

Organization Recursion Organization





! Common Message Element Type (CMET)! Rows from an HMD corresponding to a

single message element! Abstracted from HMD for reuse in other

messages




Question Break #3




Encoding rules

! Encoding Rules/7 (ER/7)! Extensible Markup Language (XML)




Message encoding in ER/7

! A delimited, plain-text set of encoding rules

! Does not constrain field lengths or repetitions (these are defined by the segment and message definitions)

! Encoding/decoding information provided in MSH segment





MSH|^~\&|LIS.FLEXILAB52|HI|CIS|HI|200008171101||ORU^R01|4475|P|2.3.1|||AL|NE||


PV1||O|||ORC|RE|r833376666kj^CIS|r833376666kjM1234^1|||||||||301836

900013^Henderson^Mike^P^^^^^1||(510) 267-2000|||OBR||r833376666kj^CIS|r833376666kjM1234^1|AST^AST(SGOT)|||

200008171100|||||||200008171100||301836900013^Henderson^Mike^P^^^^^1||||M1234||200008171100||HM|F||^^^^^R|






! Segments delimited by ASCII 13 (carriage return)

! CAUTION: ASCII 10 (newline) occurs only between messages, not between segments (although included on these slides for readability)




Message encoding in ER/7MSH|^~\&|LIS.FLEXILAB52|HI|CIS|HI|200008171101||ORU^R01|44

75|P|2.3.1|||AL|NE||

! Bytes 1-3 (the segment header) must be valued ‘MSH’ for the first segment of the message

! Byte 4 of this segment is the field separator! Used as primary delimiter for all fields in all segments

of the message

! The following bytes up to the next field separator define the delimiters for sub-entities of the fields




Message encoding in ER/7MSH|^~\&|LIS.FLEXILAB52|HI|CIS|HI|200008171101||ORU^R01|44

75|P|2.3.1|||AL|NE||

! Encoding character 1: component separator! Encoding character 2: repetition separator! Encoding character 3: escape character! Encoding character 4: subcomponent

separator! There’s no specified provision for ‘sub-subcomponents’,

etc.! This is a known limitation of ER/7, which can be

addressed by the use of XML encoding




Message encoding in ER/7MSH|^~\&|LIS.FLEXILAB52|HI|CIS|HI|200008171101||

ORU^R01|4475|P|2.3.1|||AL|NE||

! ER/7 recommends the use of the encoding characters underlined above

! CAUTION: the receiving system must be able to accept and process any encoding characters transmitted by the sending system! ! This is the responsibility of the receiving

system




Message encoding in ER/7An example of a complex field:…|99912121^LARSON&GREG&J^KFH\&HP~343434^LARSON&GREGORY&JOSEPH^KPSCAL|…

! A hypothetical identifier field! Contains two repetitions (~)! Each repetition contains three components (^)! The name component contains three subcomponents

(&)! The abbreviation KFH&HP must have the ampersand

escaped (\) to avoid its being interpreted as a subcomponent separator




Message encoding in XML! European Committee for Standardization

(CEN) 1993 study compared several interchange formats for healthcare messaging, including:! ASN.1! ASTM! EDIFACT! EUCLIDES! ODA




Message encoding in XML

! A subsequent study extended the comparison to include Standard Generalized Markup Language (SGML)

! SGML was found to compare favorably





! XML recommendation issued by World Wide Web Consortium (W3C) in 1998

! XML encoding of HL7 messages has been successfully tested in 1999 and 2000 at HIMSS

! Visit the HL7 booth at this meeting to see the 2001 demo





! Advantages of XML! A well-recognized information

interchange format! Free parsers available on Web

• James Clark’s NSGMLS





! Advantages of XML (cont’d)! Structures supported by programming

languages and other technologies, e.g.:• Document Object Model (DOM)• Simple API for XML (SAX)• Various Perl modules





! Advantages of XML (cont’d)! Produces browseable documents

• Browsers beginning to support Document Type Definitions (DTDs)/schemas directly

• Documents may be converted into Extensible HyperText Markup Language (HTML) using Extensible StylesheetLanguage Transformations (XSLT)





! The following is a simple Version 2 acknowledgment message in ER/7. The next slide will show the XML representation (in 2 columns).

MSH|^~\&|LAB^foo^bar|767543|ADT|767543|19900314130405||ACK^|XX3657|P|2.3.1<CR>

MSA|AA|ZZ9380<CR>




Message encoding in XML<!DOCTYPE ACK SYSTEM "hl7_v231.dtd">

<ACK>

<MSH>

<MSH.1>|</MSH.1>

<MSH.2>^~\&</MSH.2>

<MSH.3>

<HD.1>LAB</HD.1>

<HD.2>foo</HD.2>

<HD.3>bar</HD.3>

</MSH.3>

<MSH.4>

<HD.1>767543</HD.1>

</MSH.4>

<MSH.5>

<HD.1>ADT</HD.1>

</MSH.5>

<MSH.6>

<HD.1>767543</HD.1>

</MSH.6>

<MSH.7>19900314130405</MSH.7>

<MSH.9><CM_MSG_TYPE.1>ACK</CM_MSG_TYPE

.1>

</MSH.9>

<MSH.10>XX3657</MSH.10>

<MSH.11>

<PT.1>P</PT.1>

</MSH.11>

<MSH.12>

<VID.1>2.3.1</VID.1>

</MSH.12>

</MSH>

<MSA>

<MSA.1>AA</MSA.1>

<MSA.2>ZZ9380</MSA.2>

</MSA>

</ACK>





! HL7 Version 3 will use different formats for XML-encoded messages! Reflective of Hierarchical Message

Descriptions (HMDs)! Formal structure still under

development




More information! Healthcare Information and Management

Systems Society! http://www.himss.org

! Health Level Seven! http://www.hl7.org

! XML and other Web stuff! http://www.w3.org

! American Medical Informatics Association! http://www.amia.org




Thanks for attending!

! Mike Henderson! [email protected]! http://www.easterninformatics.com