HL7 Version 2. Chuck Meyer HL7 Chair HIMSS February,

Transcription

1 HL7 Version 2 Chuck Meyer HL7 Chair HIMSS February,

2 Relationship of 2.x to x & 3.0 Share the mostly the same resources. 3.0 published its first normative edition November Implementations are already underway. 2.x is likely to remain in place for the indefinite future wherever it is already in use. (Why fix something that isn t broken?) Hybrid environments will exist whenever 3.x is implemented and legacy systems exist We see 3.0 use growing over time. We do not see it replacing 2.x in the foreseeable future. February,

3 Compatibility Between Revisions HL7 2.x represents a progressing family of Standards that carry some baggage. Strictly speaking it is not backwards compatible. The lack of semantic definition related to the underlying processes creates an infinite variety of messages. Also, the lack of universally accepted and used code standards further inhibits reusability and transportability. Version 3 better addresses these issues, however there are few incentives in the US to upgrade messaging interfaces to improved Standards. February,

4 At A Very High Level Version 2.4 Completed November Chapters & 4 Appendices Completed before HL7 V3 Ballot Process had geared-up At the time there was some question if there should be a 2.5. Version 2.5 Published November Chapters (Chapter 2 now comes in 2 sections) Required 4 ballots (2 committee and 2 membership) A decided challenge to produce V2.5 and process 3.0 ballots simultaneously February,

5 Challenges to V2.5 Bandwidth and conflicting demands A lot of pent-up demand Significantly more Special Interest Groups but the same number of chapters Technical Committee Processes and, specifically, Ballot Processes had matured considerably. February,

6 Chapter by Chapter Chapter 2. Control 3. Patient Administration 4. Orders 5. Query 6. Financial Administration 7. Observation Reporting 8. Master Files 9. Medical Records / Information Management 10. Scheduling 11. Patient Referral 12. Patient Care 13. Clinical Laboratory Automation 14. Application Management 15. Personnel Management 2.4 Sections / Pages 19 / / / / / / / 87 9 / / 60 8 / 35 7 / 31 6 / 57 5 / 9 6 / Sections / Pages 21 / / / / 84 7 / / / / / 64 8 / 38 7 / 41 7 / 69 5 / 9 6 / 38 February,

7 General Trends Look to Chapter 2 Control A significant movement to make the Control Chapter far more robust. Large number of new data types Far more rigorous effort to define and consistently describe data types and moved to its own chapter (2A) Emphasis on data types is consistent with growth in HL7 International Affiliates Needs Alignment with emphasis on CMETs in Version 3 February,

8 General Trends Look to Chapter 2 Control A significant movement to make the Control Chapter far more robust. All segment / data field / data type definitions should now be in Chapter 2 (Control) and not in the individual function chapters. An attempt to eliminate duplicate but inconsistent definitions of data needs that started as a requirement for only one particular chapter. Dropped a few data types that had been declared obsolete several revisions ago Support for Waveform / Devices added (by far) the greatest number of new data types. February,

9 Chapter 2 Control Artifacts By the Numbers With the release of version 2.5 the number of artifacts has increased yet again: Frank Oemig & René Spronk s article in HL7 Newsletter Version 2 keeps going Data Elements / fields (*10) Trigger Events Segments Message Types Tables (*3) Message Definitions (*100) Data Types Message Structures Conformance Statements February,

10 Chapter 2 Control Message Profile Methodology HL7 V2.5 introduces a Methodology for defining Message Profiles to facilitate the concept of Conformance. Compliance to the HL7 Standard has historically been impossible to define and measure in a meaningful way. To compensate for this shortcoming, vendors and sites have used various methods of specifying boundary conditions such as optionality and cardinality. Frequently, specifications have given little guidance beyond the often-indefinite constraints provided in the HL7 Standard. This section presents the methodology for producing a precise and unambiguous specification called a message profile. Messages that adhere to the constraints of a message profile are said to be conformant to the profile. HL7 V Conformance Using Message Profiles Message Profiles are are express in in XML and and can can be be registered with with HL7. February,

11 Chapter 2 Control Segment Name / Grouping Rules for Segment Name/Grouping have been expanded to eliminate the possibility of an unparsable message. This is of particular importance for the XML encoding of HL7 V2 Messages. Segment Groups that contain <one or more segments> that are repeating or optional must follow that <one or more segments> with a required segment of a different name. February,

12 Chapter 2 Control A New Segment SFT (Software) This segment provides additional information about the software product(s) used as a Sending Application. The primary purpose of this segment is for diagnostic use. There may be additional uses per site-specific agreements. This segment is defined in Chapter 2 and now optionally follows the MSH in most messages. SEQ LEN DT OPT RP/# TBL# ITEM# ELEMENT NAME XON R Software Vendor Organization 2 15 ST R Software Certified Version or Release Number 3 20 ST R Software Product Name 4 20 ST R Software Binary ID TX O Software Product Information 6 26 TS O Software Install Date February,

13 Chapter 2 Control Some Data Elements Have Been Retired 2.4 c) A deprecated field in an existing segment may NOT be removed from the standard. However, no sooner than, after 2 versions in a deprecated state, the field will be marked as withdrawn and all explanatory narrative will be removed. The following data types have disappeared in Version 2.5 CK - composite ID with check digit CM - composite CN - composite ID number and name PN - person name TN - telephone number This data type is used only in CDM-11-Contract number as defined in chapter 8, section If a site is not using check digits for a particular CK field, the second and third components are not valued. --Replaced with CX in 2.5 No new CMs are allowed after HL7 version 2.2. The CM data type is maintained strictly for backward compatibility and may not be used for the definition of new fields. Dropped in 2.5 Note: Replaced by XCN data type as of v Dropped in 2.5 and replaced by CNN Dropped in 2.5--see XPN Dropped in 2.5--see XTN February,

14 Chapter 2 Control And there are many new data types AUI - authorization information CCD - charge code and date CCP - channel calibration parameters CNN - composite ID number and name simplified CSU - channel sensitivity DDI - daily deductible information DIN - date and institution name DLD discharge to location and date DLT - delta DTM - date/time DTN - day type and number Definition: This data type specifies the identifier or code for an insurance authorization instance and its associated detail. Definition: Specifies whether a charge action is based on an invocation event or is time-based. Definition: This data type identifies the corrections to channel sensitivity, the baseline, and the channel time skew when transmitting waveform results. Definition: Specifies a person using both an identifier and the person s name Note: Restores the original data type CN as was initially implementable in the CM used in sections and ( OBR-32), and ( OBR-33) and ( OBR-34) and ( OBR-35). Components 7 and 8, however, have been promoted to data type IS to be consistent with current practice without violating backward compatibility. Definition: This data type defines the channel sensitivity (gain) and the units in which it is measured in a waveform result. Definition: This data type specifies the detail information for the daily deductible. Definition: Specifies the date and institution information where a staff member became active or inactive. Definition: Specifies the healthcare facility to which the patient was discharged and the date. Definition: Describes the information that controls delta check warnings. Definition: Specifies a point in time using a 24 hour clock notation. Definition: This data type specifies the type and number of days for which a certification is valid. February,

15 Chapter 2 Control LA1 - location with address variation 1 LA2 - location with address variation 2 MOC - money and charge code MOP - money or percentage MSG - message type NDL name with date and location NR - numeric range OCD - occurrence code and date OSD - order sequence definition OSP - occurrence span code and date PIP practitioner institutional privileges Definition: Specifies a location and its address. Definition: Specifies a location and its address. Definition: Transmits monetary information and the associated charge code for services performed. Definition: This data type specifies an amount that may be either currency or a percentage. It is a variation on the MO data type that is limited to currency. Definition: This field contains the message type, trigger event, and the message structure ID for the message. Definition: Specifies the name of the person performing a service, when the person performed the service and where the person performed the service. Definition: Specifies the interval between the lowest and the highest values in a series of data. In the case where a numeric range is unbounded on one side, the component of the unbounded side is null. Whether the end points are included in the range is defined in the usage note for the field. Definition: The code and associated date defining a significant event relating to a bill that may affect payer processing. Definition: This data type specifies a fully coded version for forming a relationship between an order and one or more other orders. The relationship may be sequential or a cyclical pattern. Definition: A code and the related dates that identify an event that relates to the payment of the claim. For example, Prior Stay Dates which is the from/through dates given by the patient of any hospital stay that ended within 60 days of this hospital or SNF admission. Definition: This data type specifies the institutional privileges with associated detail granted to a provider. February,

16 Chapter 2 Control Definition: This data type specifies a practitioner s license number, or other ID number PLN practitioner license or other Id number such as UPIN, Medicare and Medicaid number, and associated detail. Definition: Uniquely identifies the parent result s OBX segment related to the current PRL - parent result link order, together with the information in OBR-29-parent. PTA - policy type and amount Definition: This data type specifies the policy type and amount covered by the insurance. RFR - reference range Definition: Describes a reference range and its supporting detail. RMC - room coverage Definition: This data type specifies insurance coverage detail for a room. Definition: The repeat pattern data type should be used where it is necessary to define the frequency at which an event is to take place. This data type provides a way to define repeat pattern codes "on the fly". The repeat pattern code is equivalent to the TQ data type, component 2, sub-component 1 (repeat pattern). The additional components define the meaning of the repeat pattern code. Components 2-10 are used to define relatively simple repeat patterns. Component 11 is provided to define complex repeat patterns. This data type forms a bridge between the 2.x Repeat Pattern concept from Quantity/Timing, and the Version 3.0 GTS General Timing Specification. Component 1 is the 2.x concept of repeat pattern. Components 2-7 are derived from the version 3.0 data type PIVL. Components 8-10 are derived from the version 3.0 EIVL data type. If a repeat pattern cannot be defined using components 2-10, then component 11, General Timing Specification is provided. This allows RPT repeat pattern the full literal form of the version 3.0 GTS to be specified. SPD specialty description Definition: This data type specifies the practitioner s specialty and related information. Definition: This data type identifies the site where the specimen should be obtained or where SPS specimen source the service should be performed. Definition: A code structure to relate amounts or values to identified data elements UVC - UB value code and amount necessary to process this claim as qualified by the payer organization February,

17 Chapter 2 Control An example of a new data type replacing an old TS (Time Stamp) has been retired but retained for backwards compatibility (probably through 2.7) HL7 Component Table - TS Time Stamp SEQ LEN DT OPT TBL# COMPONENT NAME COMMENTS SEC.REF DTM R Time 2.A ID B 0529 Degree of Precision 2.A.35 Definition: Specifies a point in time. Maximum Length: 26 Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]^<degree of precision> DTM (Date/Time) replaces TS. HL7 Component Table - DTM Date/Time SEQ LE N DT OP T TBL# COMPONENT NAME COMMENTS SEC.REF. 24 Date/Time Definition: Specifies a point in time using a 24 hour clock notation. Maximum Length: 24 The number of characters populated (excluding the time zone specification) specifies the precision. Format: YYYY[MM[DD[HH[MM[SS[.S[S[S[S]]]]]]]]][+/-ZZZZ]. February,

18 Chapter 4 Order Entry New Pharmacy Messages RDE - Pharmacy/Treatment Refill Authorization Request Message (Event O25) RRE - Pharmacy/Treatment Refill Authorization Request Acknowledgment (Event O26) Pharmacy Query/Response Message Pair (Event Q31) February,

19 Chapter 4 Order Entry New Pharmacy Messages (cont.) Pharmacy Query/Response Message Pair (Event Q31) May specify patient, medication, a date range, and how the response is to be sorted. This query is used to retrieve patient pharmacy dispense history information from the Server. The response is sorted by Medication Dispensed unless otherwise specified in SortControl. February,

20 Chapter 4 Order Entry Blood Transfusion Messages OMB Blood Product Order Message (Event O27) ORB Blood Product Order Acknowledgment (Event O28) BPS Blood Product Dispense Status Message (Event O29) BRP Blood Product Dispense Status Acknowledgment (Event O30) February,

21 Chapter 7 Observation Reporting New Messages: ORU Unsolicited New Point-Of-Care Observation Message Search For An Order (Event R31) New Segment SPM (Specimen): The intent of this segment is to describe the characteristics of a specimen. An advantage afforded by a separate specimen segment is that it generalizes the multiple relationships among order(s), results, specimen(s) and specimen container(s). February,

22 Remaining Issues Small errata always seems to remain Any substantive issue found late is documented to the membership in a letter from the TSC Chair. Addendums with recommended workarounds are published from the TSC Chair for serious problems discovered interim to revisions. Known outstanding issues that were not able to be resolved are identified in a last section of appropriate chapters. February,

23 Version 2.6* Chapters 1. Introduction 2. Control 3. Patient Administration 4. Order Entry 5. Queries 6. Financial Management 7. Observation Reporting 8. Master Files 9. Medical Records / Information Management 10. Scheduling 11. Patient Referral 12. Patient Care 13. Clinical Laboratory Automation 14. Application Management 15. Personnel Management 16. Non-US Claims (new to 2.6) 17. Materials Mgmt. (new to 2.6) Appendix: A. Data Definition Tables B. Lower Layer Protocol C. BNF Definitions D. Glossary * 2.6 is scheduled for publication later this year February,

24 Version 2 Messaging Standard February,