Www.hl7.org



V2_IG_LTCF_R2_DSTU_2013JUNEHL7 Version 2.5.1 Implementation Guide:S&I Framework Laboratory Test Compendium Framework, Release 2US RealmJune 2013Also referred to as eDOS (Electronic Directory Of Service)HL7 DSTU BallotSponsored by: Orders and Observations Work Groupin collaboration with the Health and Human Services Standards and Interoperability Framework Laboratory Orders Interface Working Group eDOS Work Group Co-chair: John Mooney, BioReference Laboratories Inc.eDOS Work Group Co-chair: Freida Hall, Quest Diagnostics eDOS Pilot Support Patrick E. Loyd, ICode SolutionsLOI Work Group Co-ChairHans Buitendijk, Siemens HealthcareLOI Work Group Co-ChairKen McCaslin, Quest DiagnosticsLOI Vocabulary Work Group Co-chair:Cindy Johns, LabCorpLOI Vocabulary Work Group Co-chair:Riki Merrick, iConnect ConsultingLOI Vocabulary Work Group Co-chairVirginia Sturmfels, Quest DiagnosticsQuestions or comments regarding this document should be directed to the Orders and Observations Workgroup (ord@lists.).Copyright ? 2013 Health Level Seven International ? ALL RIGHTS RESERVED. The reproduction of this material in any form is strictly forbidden without the written permission of the publisher. HL7 International and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.Use of this material is governed by HL7's HYPERLINK "" IP Compliance Policy.CopyrightsThis material includes SNOMED Clinical Terms ? (SNOMED CT?) which is used by permission of the International Health Terminology Standards Development Organization (IHTSDO). All rights reserved. SNOMED CT was originally created by The College of American Pathologists. "SNOMED ?" and "SNOMED CT ?" are registered trademarks of the IHTSDO.This material contains content from LOINC? (). The LOINC table, LOINC codes, and LOINC panels and forms file are copyright (c) 1995-2013, Regenstrief Institute, Inc. and the Logical Observation Identifiers Names and Codes (LOINC) Committee and available at no cost under the license at to BallotersThis is the first Draft Standard for Trial Use (DSTU) ballot; Release 1 was published in July 2011 as an Informative Implementation Guide.HL7 Version 8 definitions have been included pending final publication of Version 2.8; these will be removed in the publication of the eDOS IG following V2.8 publication.The following tables list the changes that have been applied and additional alignment edits to synch with LOI and LRI Implementation Guides.SectionSection NameChange TypeProposal #SubstantiveY/NLineItem5.1M08 – Master File Notification – Test/ObservationChange OM2 and OM3 segments from C to RE and update M08 usage note7315.5.4MFI-1 Master File IdentifierCorrect Example (technical correction)732N5.5.11CDM-7 Procedure CodeCorrect delimiter(technical correction)733N5.2M10 – Master File Notification – Test/Observation BatteriesChange OM5 usage from C to R to synch with Cardinality of 1..1OM5-1 Sequence Number changed from O to R and Cardinality changed 0..1 to 1..1OM4 segment optional, add missing [] brackets734Y5.5.9OM4 -15 Specimen Handling CodeRevise OM4-15 Length, Usage, and Cardinality in OM4 Segment definition746Y5.3M04 – Charge Description Master FileAdd NTE – Notes and Comments Segments pre-adopted V2.8.1745Y5.2M10 - Master File Notification – Test/Observation BatteriesChange message structure to synch with base standard752Y (but was out of synch with base standard)5.3M04 – Charge Description Master FileCorrect CDM segment cardinality to match base standard753Y (but was out of synch with base standard)5.5.6OM1 SegmentAdd new fields identified by S&I Work Groups (Lab Pilots and Lab Order Interface [LOI]) Work Group)754YAdditional edits to synch with LOI and LRI Implementation Guides:SectionSection NameChange TypeSegmentsChanged Usage of ‘X’ Not Supported to ‘O’ where appropriate. Changed elements with ACLA usage notes or proposed addition to V2.8 in Release 1 to RE to retain notes.Segments, Field Definitions, TablesAdd pre-adopt notes where applicableProfilesRevised to synch with LRI/LOI profilesVariousDelete content in base HL7 standard, with exception of Version 2.8 which is pending publicationVariesCWE data type for eDOS elements which appear in LOI and LRI are revised to synch with the appropriate CWE flavor data types used in LOI and LRI (CWE_CR, CWE_CR). Refer to Appendix B for list of elementsTable of Contents TOC \o "1-3" \h \z \u \* MERGEFORMAT 1Introduction PAGEREF _Toc246636957 \h 101.1Purpose PAGEREF _Toc246636958 \h 111.2Audience PAGEREF _Toc246636959 \h 111.2.1Relevant Laboratory Implementation Guides PAGEREF _Toc246636960 \h 111.2.2Requisite Knowledge PAGEREF _Toc246636961 \h 111.3Organization of this Guide PAGEREF _Toc246636962 \h 111.3.1Conventions PAGEREF _Toc246636963 \h 111.3.2Message Element Attributes PAGEREF _Toc246636964 \h 121.3.3Keywords PAGEREF _Toc246636965 \h 131.3.4Usage Conformance Testing Recommendations PAGEREF _Toc246636966 \h 141.3.5Pilots PAGEREF _Toc246636967 \h 162Use Case – Exchange of Directory of Services PAGEREF _Toc246636968 \h 172.1Preface PAGEREF _Toc246636969 \h 172.2Scope PAGEREF _Toc246636970 \h 172.2.1In Scope PAGEREF _Toc246636971 \h 172.2.2Out of Scope PAGEREF _Toc246636972 \h 172.3Use Case and Context Diagrams PAGEREF _Toc246636973 \h 182.4Scenario 1 – Compendium Producer Sends Directory of Services to the Compendium Consumer PAGEREF _Toc246636974 \h 182.4.1User Story PAGEREF _Toc246636975 \h 192.4.2Activity Diagram PAGEREF _Toc246636976 \h 192.4.3Base Flow PAGEREF _Toc246636977 \h 202.4.4Sequence Diagram PAGEREF _Toc246636978 \h 202.5Scenario 2 – Compendium Producer Sends Incremental Updates to Compendium Consumer PAGEREF _Toc246636979 \h 202.5.1User Story PAGEREF _Toc246636980 \h 212.5.2Activity Diagram PAGEREF _Toc246636981 \h 212.5.3Base Flow PAGEREF _Toc246636982 \h 212.5.4Sequence Diagram PAGEREF _Toc246636983 \h 222.6Functional Requirements PAGEREF _Toc246636984 \h 232.6.1Information Interchange Requirements PAGEREF _Toc246636985 \h 232.6.2System Requirements PAGEREF _Toc246636986 \h 233Message Exchange PAGEREF _Toc246636987 \h 243.1Message Use Examples PAGEREF _Toc246636988 \h 243.2Message Data Dependencies PAGEREF _Toc246636989 \h 253.3Key Technical Decisions PAGEREF _Toc246636990 \h 253.3.1Use of ISO Object Identifier (OID) PAGEREF _Toc246636991 \h 253.3.2Use of Vocabulary Standards PAGEREF _Toc246636992 \h 253.3.3Field Length and Truncation PAGEREF _Toc246636993 \h 263.3.4Scope of Implementation PAGEREF _Toc246636994 \h 263.3.5Ask at Order Entry Observations PAGEREF _Toc246636995 \h 263.4Referenced Profiles – Antecedents PAGEREF _Toc246636996 \h 263.5Conformance to this Guide PAGEREF _Toc246636997 \h 263.5.1edos Profile Components PAGEREF _Toc246636998 \h 273.5.2eDOS Profiles (Pre-Coordinated Components) PAGEREF _Toc246636999 \h 293.5.3Response Components PAGEREF _Toc246637000 \h 293.5.4Response Profiles (Pre-Coordinated Components) PAGEREF _Toc246637001 \h 293.5.5Extended Profile Use PAGEREF _Toc246637002 \h 303.6Delivery PAGEREF _Toc246637003 \h 303.7Maintenance Updates PAGEREF _Toc246637004 \h 303.8File Naming Conventions PAGEREF _Toc246637005 \h 303.9Transport Layer PAGEREF _Toc246637006 \h 304Data Types PAGEREF _Toc246637007 \h 314.1CNE – Coded With No Exceptions PAGEREF _Toc246637008 \h 314.2CWE – Coded with Exceptions PAGEREF _Toc246637009 \h 314.2.1CWE – Coded with Exceptions – Base PAGEREF _Toc246637010 \h 314.2.2CWE_CRE – Coded with Exceptions – Code Required, but May Be Empty PAGEREF _Toc246637011 \h 324.2.3CWE_RC – Required Components PAGEREF _Toc246637012 \h 344.2.4CWE_RC1 – Required Components PAGEREF _Toc246637013 \h 354.3CQ – Composite Quantity with Units PAGEREF _Toc246637014 \h 364.4EI – Entity Identifier PAGEREF _Toc246637015 \h 364.4.1EI_GU – Entity Identifier (Globally Unique) PAGEREF _Toc246637016 \h 364.4.2EI_NG – Entity Identifier (Non-Globally Unique) PAGEREF _Toc246637017 \h 364.5HD_GU – Hierarchic Designator PAGEREF _Toc246637018 \h 374.5.1HD_GU – Hierarchic Designator (Globally Unique) PAGEREF _Toc246637019 \h 374.5.2HD_NG – Hierarchic Designator (Non-Globally Unique) PAGEREF _Toc246637020 \h 374.6MSG – Message Type PAGEREF _Toc246637021 \h 384.7NR – Numeric Range PAGEREF _Toc246637022 \h 384.8PT – Processing Type PAGEREF _Toc246637023 \h 384.9RFR – Reference Range PAGEREF _Toc246637024 \h 384.10TS_1 – Time Stamp 1 PAGEREF _Toc246637025 \h 394.11VID – Version Identifier PAGEREF _Toc246637026 \h 394.12XAD – Extended Address PAGEREF _Toc246637027 \h 395Messages PAGEREF _Toc246637028 \h 415.1MFN^M08^MFN_M08 – Master File Notification – Test/Observation (Numeric) PAGEREF _Toc246637029 \h 415.2MFN^M10^MFN_M10 – Master File Notification – Test/Observation Batteries PAGEREF _Toc246637030 \h 425.3MFN^M04^MFN_M04 – Charge Description Master File Message PAGEREF _Toc246637031 \h 425.4MFK^VARIES^MFK_M01 PAGEREF _Toc246637032 \h 435.5Segment and Field Descriptions PAGEREF _Toc246637033 \h 445.5.1MSH – Message Header Segment PAGEREF _Toc246637034 \h 445.5.2MSA – Acknowledgement Segment PAGEREF _Toc246637035 \h 475.5.3ERR – Error Segment PAGEREF _Toc246637036 \h 475.5.4MFI – Master File Identification Segment PAGEREF _Toc246637037 \h 485.5.5MFE – Master File Entry Segment PAGEREF _Toc246637038 \h 485.5.6OM1 – General Segment PAGEREF _Toc246637039 \h 495.5.7OM2 – Numeric Observation Segment PAGEREF _Toc246637040 \h 575.5.8OM3 – Categorical Service/Test/Observation Segment PAGEREF _Toc246637041 \h 605.5.9OM4 – Observations That Require Specimens Segment PAGEREF _Toc246637042 \h 615.5.10OM5 – Observation Batteries (Sets) Segment PAGEREF _Toc246637043 \h 655.5.11CDM – Charge Description Master Segment PAGEREF _Toc246637044 \h 666Code Systems and Value Sets PAGEREF _Toc246637045 \h 706.1LOINC PAGEREF _Toc246637046 \h 706.2SNOMED CT PAGEREF _Toc246637047 \h 706.3Unconstrained Code Systems PAGEREF _Toc246637048 \h 716.4Constrained HL7 Tables – Value Sets PAGEREF _Toc246637049 \h 736.4.1HL7 Table 0003 – Event Type PAGEREF _Toc246637050 \h 736.4.2HL7 Table 0076 – Message Type PAGEREF _Toc246637051 \h 736.4.3HL7 Table 0125 – Value Type (V2.5.1) PAGEREF _Toc246637052 \h 736.4.4HL7 Table 0180 – Record-Level Event Code PAGEREF _Toc246637053 \h 756.4.5HL7 Table 0301 – Universal ID Type (V2.7.1) PAGEREF _Toc246637054 \h 756.4.6HL7 Table 0354 – Message Structure PAGEREF _Toc246637055 \h 766.4.7HL7 Table 0919 – Exclusive Test (V2.8) PAGEREF _Toc246637056 \h 766.4.8HL7 Table 0920 – Preferred Specimen/Attribute Status (V2.8) PAGEREF _Toc246637057 \h 777Appendix A – Ask at Order Entry PAGEREF _Toc246637058 \h 787.1Example AOE for Employer Address PAGEREF _Toc246637059 \h 797.2Proposed AOEs with a LOINC Code PAGEREF _Toc246637060 \h 797.3Proposed AOEs without a LOINC Code PAGEREF _Toc246637061 \h 867.4Specimen List PAGEREF _Toc246637062 \h 877.5Common AOEs Which Should be Messaged Elsewhere in HL7 PAGEREF _Toc246637063 \h 888Appendix B – eDOS-LOI-LRI Field Comparison PAGEREF _Toc246637064 \h 919Key Changes eDOS R1 to R2 PAGEREF _Toc246637065 \h 93Index of Tables TOC \f F \t "Caption" \c "Table" \ MERGEFORMATTable 11. Message Element Attributes PAGEREF _Toc246637066 \h 12Table 21. Actors PAGEREF _Toc246637067 \h 18Table 22. Base Flow PAGEREF _Toc246637068 \h 20Table 23. Base Flow PAGEREF _Toc246637069 \h 21Table 24. Information Interchange Requirements PAGEREF _Toc246637070 \h 23Table 25. System Requirements PAGEREF _Toc246637071 \h 23Table 31. Message Type Benefits PAGEREF _Toc246637072 \h 24Table 32. Message Use Examples PAGEREF _Toc246637073 \h 24Table 41. Coded With No Exceptions (CNE) PAGEREF _Toc246637074 \h 31Table 42. Coded With Exceptions – Base (CWE) PAGEREF _Toc246637075 \h 31Table 43. Coded with Exceptions – Code Required But May Be Empty (CWE_CRE) PAGEREF _Toc246637076 \h 32Table 44. Coded with Exceptions – Required Components (CWE_RC) PAGEREF _Toc246637077 \h 34Table 45. Coded with Exceptions – Required Components (CWE_RC) PAGEREF _Toc246637078 \h 35Table 46. Composite Quantity with Units (CQ) PAGEREF _Toc246637079 \h 36Table 47. Entity Identifier (EI_GU) PAGEREF _Toc246637080 \h 36Table 48. Entity Identifier (EI_NG) PAGEREF _Toc246637081 \h 36Table 49. Hierarchic Designator (HD_GU) PAGEREF _Toc246637082 \h 37Table 410. Hierarchic Designator (HD_NG) PAGEREF _Toc246637083 \h 37Table 411. Message Type (MSG) PAGEREF _Toc246637084 \h 38Table 412. Numeric Range (NR) PAGEREF _Toc246637085 \h 38Table 413. Processing Type (PT) PAGEREF _Toc246637086 \h 38Table 414. RFR – Reference Range PAGEREF _Toc246637087 \h 38Table 415. Stamp 1 (TS_1) PAGEREF _Toc246637088 \h 39Table 416. Version Identifier (VID) PAGEREF _Toc246637089 \h 39Table 417. Extended Address (XAD) PAGEREF _Toc246637090 \h 39Table 51. Trigger Events and MEssages PAGEREF _Toc246637091 \h 41Table 52. M08 – Master File Notification – Test/Observation (Numeric) PAGEREF _Toc246637092 \h 41Table 53. M10 – Master File Notification – Test/Observation Batteries PAGEREF _Toc246637093 \h 42Table 54. M04 – Charge Description Master File Message PAGEREF _Toc246637094 \h 43Table 55. MFK^Mxx^MFK Abstract Message Syntax PAGEREF _Toc246637095 \h 44Table 56. Message Header Segment (MSH) PAGEREF _Toc246637096 \h 44Table 57. Acknowledgment Segment (MSA) PAGEREF _Toc246637097 \h 47Table 58. Error Segment (ERR) PAGEREF _Toc246637098 \h 47Table 59. Master File Identification (MFI) PAGEREF _Toc246637099 \h 48Table 510. Master File Entry (MFE) PAGEREF _Toc246637100 \h 48Table 511. General Segment (OM1) PAGEREF _Toc246637101 \h 49Table 512. OM2 – Numeric Observation PAGEREF _Toc246637102 \h 58Table 513. Reference Interval PAGEREF _Toc246637103 \h 60Table 514. OM3 – Categorical Service/Test/Observation PAGEREF _Toc246637104 \h 60Table 515. OM4 – Observations that Require Specimens PAGEREF _Toc246637105 \h 61Table 516. OM5 – Observation Batteries (Sets) PAGEREF _Toc246637106 \h 65Table 517. CDM – Charge Description Master PAGEREF _Toc246637107 \h 66Table 518. Example CPT Test Codes PAGEREF _Toc246637108 \h 68Table 61. Unconstrained Code System Summary PAGEREF _Toc246637109 \h 71Table 62. Constrained Code System Summary PAGEREF _Toc246637110 \h 73Table 63. HL7 Table 0003 – Event Type Code PAGEREF _Toc246637111 \h 73Table 64. HL7 Table 0076 – Message Type PAGEREF _Toc246637112 \h 73Table 65. HL7 Table 0125 – Value Type (V2.5.1) PAGEREF _Toc246637113 \h 73Table 66. HL7 0180 – Record-Level Event Code PAGEREF _Toc246637114 \h 75Table 67. HL7 Table 0301 – Universal ID Type (V2.7.1) PAGEREF _Toc246637115 \h 75Table 68. HL7 Table 0354 – Message Structure PAGEREF _Toc246637116 \h 76Table 69. HL7 Table 0919 – Exclusive Test (v2.8) PAGEREF _Toc246637117 \h 77Table 610. HL7 Table 0919 – Impact on OM1-49 PAGEREF _Toc246637118 \h 77Table 611.HL7 Table 0920 – Preferred Specimen/Attribute Status (V2.8) PAGEREF _Toc246637119 \h 77Table 71. Example LOINC AOE Questions PAGEREF _Toc246637120 \h 81Table 72. Example AOE Questions (Without LOINC Code) PAGEREF _Toc246637121 \h 86Table 73. Example Specimen LOINC AOE Questions PAGEREF _Toc246637122 \h 88Table 74. Common AOEs which should be messaged elsewhere in HL7 PAGEREF _Toc246637123 \h 89Table 81. Field Comparison PAGEREF _Toc246637124 \h 91Index of Figures TOC \h \z \t "Figure Caption" \c Figure 11. eDOS Data Flow PAGEREF _Toc246637125 \h 10Figure 21. Use Case Diagram PAGEREF _Toc246637126 \h 18Figure 22. Context Diagram PAGEREF _Toc246637127 \h 18Figure 23. Scenario 1 Activity Diagram PAGEREF _Toc246637128 \h 19Figure 24. Scenario 1 Sequence Diagram PAGEREF _Toc246637129 \h 20Figure 25. Scenario 2 Activity Diagram PAGEREF _Toc246637130 \h 21Figure 26. Scenario 2 Sequence Diagram PAGEREF _Toc246637131 \h 22Figure 31. Message Exchange Sequence PAGEREF _Toc246637132 \h 24IntroductionThe American Clinical Laboratory Association (ACLA) represents national, regional and local laboratories that collectively have an extensive history of providing the nation’s hospitals and physicians with leading-edge Health Information Technology (HIT) to streamline the laboratory test requisition process and speed the delivery of test results. A subgroup of ACLA, the HIT Data Standards Committee is dedicated to the review and development of HIT initiatives (standards and government regulatory items) that might impact the clinical laboratory industry.The development of a framework for the Laboratory Test Compendium and associated capability of electronic exchange of Directory of Services (eDOS) content as outlined in this implementation guide is a critical step in the increased interoperability required between Clients [hereafter defined as commercial Electronic Health Record (EHR), Hospital Laboratory Information System (HLIS), HIE vendors and Laboratory Information systems (LIS) and/or other entities] and laboratory providers. This development effort fills a gap in the current electronic data exchange and will enable the reduction of costs for providers, laboratories and vendors while further decreasing error rates by simplifying the exchange of data related to a DOS.Release 2 of the eDOS Implementation Guide is the result of work by the eDOS Work Group under the sponsorship of the Office of National Coordinator (ONC) Standards and Interoperability Framework (SIF) and is designed to work in concert with the companion Lab Result Interface (LRI) and Lab Order Interface (LOI) implementation guides.The SIF Lab Result Interface Work Group published a V2.5.1 draft for trial use (DSTU) Implementation Guide for Lab Results through the Health Level Seven (HL7) standards development organization (SDO) in July 2012. This Implementation Guide was selected by ONC for Meaningful Use Stage 2.The SIF Lab Orders Interface Work Group plans to publish a V2.5.1 draft for trial use (DSTU) Implementation Guide for Lab Orders through the Health Level Seven (HL7) standards development organization (SDO) in 2013.The SIF eDOS Work Group plans to publish this V2.5.1 draft for trial use (DSTU) Implementation Guide for the electronic director of service (test compendium) through the Health Level Seven (HL7) standards development organization (SDO) in 2013.Several elements in the laboratory’s test compendium are subsequently used in the lab order and lab result. For additional detail, refer to Appendix B. Figure 1 below illustrates the flow of some of the data elements from eDOS to LOI and LRI uses.-15875444500Figure STYLEREF 1 \s 1 SEQ Figure \* ARABIC \s 1 1. eDOS Data FlowARRA/HITECH rules have specified HL7 Version 2.5.1 as the requirement for laboratory reporting for both Meaningful Use 1 and Meaningful Use 2. Release 1 of the Laboratory Test Compendium Framework (eDOS) was developed using Chapter 8 of the HL7 Version 2.6 but Release 2 is defined for V2.5.1 to synch with the LOI and LRI Implementation Guides.PurposeThe content of the Laboratory Test Compendium Framework is a Laboratory’s DOS. The content is owned by the sending laboratory for the purpose of being used by the receiving Client to be able to order laboratory services and to understand the requirements and components of those services. The Client and those Client Systems should not modify or delete the content unless instructed to do so by the lab either with eDOS updates or some other form of written communication. Adding to the content to provide additional information specific to the client such as cross reference to client codes and/or other performing labs or other information that does not change or conflict with the content of the original information provided by the performing laboratory is permitted.AudienceThis guide is designed for use by analysts and developers who require guidance on data elements and components of the HL7 Version 2 Implementation Guide: Laboratory Test Compendium Framework, Release 2 relative to the Laboratory Orders Interface (LOI) initiative. Users of this guide must be familiar with the details of HL7 message construction and processing. This guide is not intended to be a tutorial on that subject.Relevant Laboratory Implementation GuidesThere are several documents that are part of a product group to support multiple Implementation Guides in support of the Office of the National Coordinator (ONC) under the Standards and Interoperability Framework Initiative (SIF). The purpose is to provide consistent processes and documentation format criteria. The set includes but is not limited to:This publication; the Laboratory Test Compendium Framework Implementation Guide (eDOS)Standards and Interoperability Laboratory Results Interface Use Case, Laboratory Results Reporting to Primary Care Providers (in an Ambulatory Setting) v1.0 (LRI)HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 – US Realm (LOI)The profiles that allow modifications of both the LRI and LOI IG to support the HL7 Version 2.5.1 Implementation Guide: Electronic Laboratory Reporting to Public Health, Release 1 (US Realm) (ELR) or the addendum to those guides.Requisite KnowledgeHL7 Version 2.5.1 Chapter 8 Master Files was used to develop this implementation guide. Pre-adoption from V2.7.1, V2.8 and V2.8.1 is indicated where appropriate.HL7 V2.5.1, V2.7.1, V2.8, V2.8.1 Messaging ()LOINC ()OIDS ()Organization of this GuideConventionsThis guide adheres to the following conventions:The guide is constructed assuming the implementer has access to the V2.5.1, V2.7.1, V2.8 and V2.8.1 versions of the HL7 Standard. Although some information from the standard is included in this implementation guide, much information from the standard has not been repeated here.References to Chapters, e.g., See Chapter 4, 2.2.4, indicate a chapter in the base V2.5.1 standard (unless otherwise noted.)The rules outlined in HL7 V2.7.1, Chapter 2B, Section 2B5, Conformance Using Message Profiles, were used to document the use case for, and constraints applied to, the messages described in this guide.Data types have been described separately from the fields that use the data types.No conformance information is provided for optional message elements and segments (“O”) or unsupported message elements and segments (“X”). This includes cardinality, value sets and descriptive information. Implementers who want to use optional message elements should refer to the base HL7 V2.5.1 Standard to determine how these optional message elements will be used. Conformance information is provided when a conditional predicate resolves to an “R” or “RE” on either the “a” or “b” part of the expression, regardless of the opposite value, e.g., C(R/O).Exceptions to this convention are V2.8 elements, which represent ACLA proposals to address limitations in HL7 V2, Chapter 8. These have been accepted by HL7 for inclusion in the final publication of V2.8; however at the time of this IG V2.8 publication this has not occurred. The V2.8 information is taken verbatim from the January 2013 ballot; upon publication this exception will be removed and this IG updated accordingly when appropriate.This guide provides conditional predicates for some fields; note that the condition may be dependent on data elements that are marked as “O” (optional). In these cases, the interpretation by the reader should be “if the optional element is used, then these additional constraints are now required.” That is, if the optional element is present, then these additional constraints are now active. This guidance is included as it is logically true but these conditional elements are not tested.This guide uses “X” as a conformance usage indicator very sparingly. Where the underlying standard indicates the segments/field/component is present for backwards compatibility (“B”) or withdrawn ("W") an “X” will be used. A small number of other message elements that are clearly out of scope for the use case have been given the "X" usage. All other message elements have either been further constrained to R/RE/C(a/b) or have been left as "O" to enable trading partners to explore additional capabilities. Note that without a clearly agreed to complementary profile between trading partners, a laboratory that is compliant with this implementation guide does not have to send any elements marked as an "O", nor does a receiver of an eDOS message that is compliant with this implementation guide have to process any elements marked as an "O". Neither trading partner can mandate the other to accept any such complementary profiles to enable basic laboratory eDOS interfacing "out-of-the-box".Message Element AttributesThe following table describes the various attributes used by this guide to document data type attribute tables, message structure attribute tables and segment attribute tables. Not all attributes apply to all attribute tables.Table STYLEREF 1 \s 1 SEQ Table \* ARABIC \s 1 1. Message Element AttributesAttributeDefinitionSEQSequence of the elements as numbered in the HL7 message element. The SEQ attribute applies to the data type attribute table and the segment attribute ponent NameShort name for the component.SegmentThree-character code for the segment and the abstract syntax (e.g., the square and curly braces): [ XXX ]Optional and singular{ XXX }Required and may repeat XXXRequired and singular[{ XXX }]Optional and may repeatNote that for segment groups there is no segment code present, but the square and curly braces will still be present.The Segment attribute only applies to the Message attribute table.DTData type used by this profile for HL7 element.The data type attribute applies to data type attribute tables and segment attribute tables.UsageUsage of the message element for this profile. Indicates whether the message element (segment, segment group, field, component, or subcomponent) is R, RE, O, X or C(a/b) in the corresponding message element. Usage applies to the message attribute table, data type attribute table and the segment attribute table, see Section REF _Ref224392525 \r \h 1.3.4 REF _Ref224392628 \h Usage Conformance Testing Recommendations.CardinalityMinimum and maximum number of times the element may appear.[0..0]Element never present.[0..1]Element may be omitted and can have, at most, one occurrence.[1..1]Element must have exactly one occurrence.[0..n]Element may be omitted or may repeat up to n times.[1..n]Element must appear at least once, and may repeat up to n times.[0..*]Element may be omitted or repeat an unlimited number of times.[1..*] Element must appear at least once, and may repeat unlimited number of times.[m..n]Element must appear at least m, and at most, n times.Cardinality applies only to message attribute tables and segment attribute tables.Value SetThe set of coded values to be used with the field. The value set attribute applies only to the data type attribute tables and the segment attribute tables. The value set may equate with an entire code system, part of a code system, or codes drawn from multiple code systems.Unconstrained, Constrained and User Defined tables are listed or included in Section REF _Ref225180151 \r \h 6 REF _Ref225180158 \h Code Systems and Value Sets.NameHL7 descriptor of the message element. Name applies to the message attribute table, data type attribute table and the segment attribute table.Description/CommentsContext and usage for the element. Description/Comments applies to the message attribute table, data type attribute table and the segment attribute table.KeywordsThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. The following definitions are excerpted from the RFC:MUST or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.MUST NOT or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification.SHOULD or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.SHOULD NOT or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.MAY or the adjective "OPTIONAL", mean that an item is truly optional. One software supplier may choose to include the item to enable certain capabilities while another software supplier may omit the same item. In either case, the communication partner cannot be expected to either provide it (sender) or process it (receiver) without clear and voluntary agreement between the partners.An implementation which does not include a particular segment/field/component marked as optional MUST be prepared to interoperate with another implementation which does include the optional segment/field/component, though perhaps with reduced functionality. In the same vein an implementation which includes a particular segment/field/component marked as optional MUST be prepared to interoperate with another implementation which does not include the optional segment/field/component.Usage Conformance Testing RecommendationsThe following text is pre-adopted from the HL7 V2.8.1 Conformance (Chapter 2B, 2.B.7.5). Please refer to the base standard documentation for a full explanation of conformance concepts. Usage is described here as it introduces the revised approach to conditional element handling.---------- start citation---------2.B.7.5 Usage xe "Conformance: usage"Message content is governed by the cardinality specification associated (explicitly or implicitly) with each element of an HL7 message. Usage rules govern the expected behavior of the sending application and receiving application with respect to the element. The usage codes expand/clarify the optionality codes defined in the HL7 standard. Usage codes are employed in a message profile to constrain the use of elements defined in the standard. The usage code definitions are given from a sender and receiver perspective and specify implementation and operational requirements.The standard allows broad flexibility for the message structures that HL7 applications must be able to receive without failing. But while the standard allows that messages may be missing data elements or may contain extra data elements, it should not be inferred from this requirement that such messages are conformant. In fact, the usage codes specified in a message profile place strict conformance requirements on the behavior of the application.DEFINITION OF CONDITIONAL USAGEThe conditional usage is defined as follows:C(a/b) - “a” and “b” in the expression are placeholders for usage codes representing the true (“a”) predicate outcome and the false (“b”) predicate outcome of the condition. The condition is expressed by a conditional predicate associated with the element (“See section 2.b.7.9, "Condition predicate"). “a” and “b” shall be one of “R”, “RE”, “O” and/or “X”. The values of “a” and “b” can be the same.The example C(R/RE) is interpreted as follows. If the condition predicate associated with the element is true then the usage for the element is R-Required. If the condition predicate associated with the element is false then the usage for the element is RE-Required but may be empty.There are cases where it is appropriate to value “a” and “b” the same. For example, the base standard defines the usage of an element as “C” and the condition predicate is dependent on the presence or non-presence of another element. The profile may constrain the element that the condition is dependent on to X; in such a case the condition should always evaluate to false. Therefore, the condition is profiled to C(X/X) since the desired effect is for the element to be not supported. Note it is not appropriate to profile the element to X since this breaks the rules of allowable usage profiling (see table HL7 Optionality and Conformance Usage).Usage Rules for a Sending ApplicationOptionality/Usage IndicatorDescriptionImplementation RequirementOperational RequirementRRequiredThe application shall implement “R” elements. The application shall populate “R” elements with a non-empty value.RERequired but may be emptyThe application shall implement “RE” elements.The application shall populate “RE” elements with a non-empty value if there is relevant data. The term “relevant” has a confounding interpretation in this definition. C(a/b)ConditionalAn element with a conditional usage code has an associated condition predicate (See section 2.B.7.9, “Condition predicate” that determines the operational requirements (usage code) of the element.If the condition predicate associated with the element is true, follow the rules for a which shall be one of “R”, “RE”, “O” or X”:If the condition predicate associated with the element is false, follow the rules for b which shall be one of “R”, “RE”, “O” or X”.a and b can be valued the same.XNot supportedThe application (or as configured) shall not implement “X” elements.The application shall not populate “X” elements.OOptionalNone. The usage indicator for this element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C(a/b), or X.Not Applicable. Usage Rules for a Receiving ApplicationOptionality/Usage IndicatorDescriptionImplementation RequirementOperational RequirementRRequiredThe application shall implement “R” elements. The receiving application shall process (save/print/archive/etc.) the information conveyed by a required element.A receiving application shall raise an exception due to the absence of a required element. A receiving application shall not raise an error due to the presence of a required element,RERequired but may be emptyThe application shall implement “RE” elements.The receiving application shall process (save/print/archive/etc.) the information conveyed by a required but may be empty element. The receiving application shall process the message if the element is omitted (that is, an exception shall not be raised because the element is missing).C(a/b)ConditionalThe usage code has an associated condition predicate true (See section 2.B.7.9, “Condition predicate").If the condition predicate associated with the element is true, follow the rules for a which shall one of “R”, “RE”, “O” or X”:If the condition predicate associated with the element is false, follow the rules for b which shall one of “R”, “RE”, “O” or X”.a and b can be the same.XNot supportedThe application (or configured) shall not implement “X” elements.None, if the element is not sent.If the element is sent the receiving application may process the message, shall ignore the element, and may raise an exception. The receiving application shall not process (save/print/archive/etc.) the information conveyed by a not-supported element.OOptionalNone. The usage indicator for this element has not yet been defined. For an implementation profile all optional elements must be profiled to R, RE, C(a/b), or X.None. --------- end citation ---------PilotsDuring eDOS Use Case development, the community decided that the eDOS pilots should pay particular attention to the notion of the "established escalation procedures" between the Compendium Consumer and the Compendium Producer. Pilots may decide that more detail is required, or that the term is sufficient. The process for removing a test from the compendium may need to be reviewed in greater detail by the Pilots.Use Case – Exchange of Directory of ServicesThe Laboratory Test Compendium Framework, or Electronic Directory of Services (eDOS), defines the format to deliver the laboratory test menu offerings to systems that support electronic laboratory ordering, results reporting and other functionality.This content will support the initial Laboratory Test Compendium build for each client as well as on-going maintenance updates throughout the life of the interface. The laboratory, in coordination with the client, will determine if a complete eDOS or a subset based on the client’s ordering history is appropriate for the client’s specific interface implementation. The laboratory may also provide maintenance updates to the client based on the test ordering history of the client.PrefaceThe Use Cases describes:The operational context for the data exchangeThe stakeholders with an interest in the Use CaseThe information flows that must be supported by the data exchangeThe types of data and their specifications required in the data exchangeScopeThe scope of this Use Case is the electronic communication of a laboratory’s directory of services (DOS) for the US Realm.In ScopeHighlights of the Laboratory Test Compendium Framework include the ability to communicate:Codesets used to order the laboratory tests (see Section REF _Ref225180151 \w \h 6 REF _Ref225180151 \h Code Systems and Value Sets).Descriptions of the laboratory tests.Effective date.Preferred name for test.Orderability of test (is the test orderable (y/n)).Nature of test (profile, single observation, etc.).Specimen requirements (including collection, storage and transportation instructions).Processing priorities (ability to order as stat, routine, or other priorities).Observation requirements (Ask at Order Entry (AOE) requirements).Reflex observations (list of what could be reflexed for this test).Test grouping requirements.Test components (analytes that will be included in the test).Procedure codes (CPT codes only).Out of ScopeA method for requesting a test compendium or update.Application level acknowledgement.Automated sub-set creation/selection.Automated messaging of subsets of the test compendium, for example, a subset for specific medical specialty.Application level maintenance processes relative to the receipt of an eDOS.The delivery mechanism has not been addressed in this document as existing technologies used for communication of laboratory orders and results messages already exist and can be adopted to accommodate an additional message to be delivered. ActorsThere are two actors that have responsibilities related to the conformance profiles defined in this document:Table STYLEREF 1 \s 2 SEQ Table \* ARABIC \s 1 1. ActorsActorRoleDescriptionCompendium ProducereDOS Sender A sender of messages that declares conformance to a profile defined in this guide, e.g.,. a pendium ConsumereDOS RequestoreDOS ReceiverA receiver of messages that declares conformance to a profile defined in this guide, e.g., an Ordering Provider’s EHR system.Use Case and Context DiagramsFigure STYLEREF 1 \s 2 SEQ Figure \* ARABIC \s 1 1. Use Case DiagramFigure STYLEREF 1 \s 2 SEQ Figure \* ARABIC \s 1 2. Context DiagramScenario 1 – Compendium Producer Sends Directory of Services to the Compendium ConsumerA Compendium Producer sends its Directory of Services electronically to a Compendium Consumer.User StoryA Compendium Producer and a Compendium Consumer agree to automate the process of delivering the eDOS. The initial build for a Compendium Consumer is the entire eDOS or a subset based on the Compendium Consumer’s ordering history, specialty, etc., as agreed to between the Compendium Consumer and the Compendium Producer.As scheduled or as requested, a Compendium Producer electronically sends the complete eDOS or subset. The eDOS is received and processed by a Compendium Consumer. If the Compendium Consumer is unable to process the file, or components of the file, they should notify the Compendium Producer immediately using their established escalation procedures.Activity DiagramFigure STYLEREF 1 \s 2 SEQ Figure \* ARABIC \s 1 3. Scenario 1 Activity DiagramBase FlowNote: This flow may begin with either Step 1A or Step 1B.Table STYLEREF 1 \s 2 SEQ Table \* ARABIC \s 1 2. Base FlowStepActorRoleEvent/DescriptionInputsOutputs1ACompendium ConsumerDOS Requestor, DOS ReceiverCompendium Consumer requests and receives an electronic Directory of Services from the Compendium Producer.Electronic Directory of Services RequestElectronic Directory of Services1BCompendium ProducerDOS SenderCompendium Producer electronically sends Directory of Services to the Compendium Consumer.Electronic Directory of ServicesElectronic Directory of Services2Compendium ConsumerDOS ReceiverCompendium Consumer electronically consumes the Directory of Services from the Compendium Producer and makes it available to the Ordering Provider.Electronic Directory of ServicesDirectory of Services available electronically to Compendium ConsumerSequence DiagramFigure STYLEREF 1 \s 2 SEQ Figure \* ARABIC \s 1 4. Scenario 1 Sequence DiagramScenario 2 – Compendium Producer Sends Incremental Updates to Compendium ConsumerA Laboratory (Compendium Producer) sends incremental updates to its Directory of Services electronically to an Ordering Provider’s EHR System (Compendium Consumer).User StoryA Laboratory (Compendium Producer) and an Ordering Provider and/or the Ordering Provider’s EHR Vendor (Compendium Consumer) agree to automate the process of updating the Laboratory’s Directory of Services throughout the life of the interface.As scheduled or as requested, a Compendium Producer sends maintenance files containing additions, deactivations and/or updates (collectively called incremental updates), rather than the entire Directory of Services, to the Compendium Consumer. The information is received and processed by a Compendium Consumer. If the Compendium Consumer is unable to process the file, or components of the file, they should notify the Compendium Producer immediately using their established escalation procedures.Activity DiagramFigure STYLEREF 1 \s 2 SEQ Figure \* ARABIC \s 1 5. Scenario 2 Activity DiagramBase FlowNote: This flow may begin with either Step 1A or Step 1B.Table STYLEREF 1 \s 2 SEQ Table \* ARABIC \s 1 3. Base FlowStepActorRoleEvent/DescriptionInputsOutputs1AEHR System (Compendium Consumer)DOS Requestor, DOS ReceiverCompendium Consumer requests and receives incremental updates to an electronic Directory of Services from the Compendium Producer.Incremental Updates to Electronic Directory of Services RequestIncremental Updates to Electronic Directory of Services1BLaboratory (Compendium Producer)DOS SenderCompendium Producer electronically sends incremental updates to the Compendium Consumer.Incremental Updates to Electronic Directory of ServicesIncremental Updates to Electronic Directory of Services2EHR System (Compendium Consumer)DOS ReceiverCompendium Consumer electronically consumes the incremental updates to the Directory of Services from the Compendium Producer and makes the updated Directory of Services available to the Ordering Provider.Incremental Updates to Electronic Directory of ServicesUpdated Directory of Services available electronically from Ordering Provider’s EHR System (Compendium Consumer)Sequence DiagramFigure STYLEREF 1 \s 2 SEQ Figure \* ARABIC \s 1 6. Scenario 2 Sequence DiagramFunctional RequirementsInformation Interchange RequirementsTable STYLEREF 1 \s 2 SEQ Table \* ARABIC \s 1 4. Information Interchange RequirementsInitiating SystemActionRequirementActionReceiving SystemEHR SystemSendRequest for Full Directory of Services or pre-defined subsetsReceiveLISLISSendFull Directory of Services or pre-defined subsetsReceiveEHR SystemEHR SystemSendRequest for Incremental Updates to Directory of ServicesReceiveLISLISSendIncremental Updates to Directory of ServicesReceiveEHR SystemSystem Requirements Table STYLEREF 1 \s 2 SEQ Table \* ARABIC \s 1 5. System RequirementsSystemRequirementLISBuild Electronic Directory of Services; Process Request for Electronic Directory of Services from EHR SystemEHR SystemCreate Request for Electronic Directory of Services from LIS; Consume Electronic Directory of Services; Make Available Electronic Directory of Services for Ordering ProvidersMessage ExchangeThis guide leverages three HL7 messages to communicate all Electronic Directory of Service information in the following order:MFN^M08 – Master File Notification – Test/Observation: listing each result observation.MFN^M10 – Master File Notification – Test/Observation Batteries: listing each orderable battery (group test, panel, profile, etc.).MFN^M04 – Master File Notification – Charge Description: listing procedure codes to compliment the orderable items.Note: Full message structures are found in Section REF _Ref240640050 \w \h 5 REF _Ref240640056 \h Messages.Table STYLEREF 1 \s 3 SEQ Table \* ARABIC \s 1 1. Message Type BenefitsTypeOrdering BenefitReporting BenefitMFN^M08Lists individually ordered testsProvides information on each potential resultMFN^M10Lists group tests & componentsProvides analyte grouping/sequence informationMFN^M04Provides Procedure code information for reference / administrative validation (Medical Necessity/ABN)None-114300160020Laboratory00Laboratory1600200845820All reportable analytes00All reportable analytes45720073152000342900502920M08 – Master File Notification – Test/Observation00M08 – Master File Notification – Test/Observation422656050228500342900502920003886200160020Client00Client4572001645920008001001760220Orderable group tests (Panels, Profiles, etc.)00Orderable group tests (Panels, Profiles, etc.)3429001417320M10 – Master File Notification – Test/Observation Batteries00M10 – Master File Notification – Test/Observation Batteries16002002674620Procedure Codes00Procedure Codes4572002560320005715002331720M04 – Master File Notification – Charge Description00M04 – Master File Notification – Charge Description4010025704913500Figure STYLEREF 1 \s 3 SEQ Figure \* ARABIC \s 1 1. Message Exchange SequenceMessage Use ExamplesTable STYLEREF 1 \s 3 SEQ Table \* ARABIC \s 1 2. Message Use ExamplesScenarioMFN^M08MFN^M10MFN^M04Individually Ordered (Atomic) TestOne recordN/AOne optional record, listing each CPT for the TestPanelOne record for each componentOne record for the panel, references to each componentOne record listing each CPT code for the panelSuperset (Profile)Same as above for either panel or individual testOne record for the superset, references to each component panel or individual test.Same as above for either panel or individual testIndividually Ordered (Atomic) Test – ExperimentalOne RecordN/ANoneMessage Data DependenciesThere are several dependencies amongst the data contained in each message:MFN^M10 – Test/Observation Batteries – reference the individually ordered components, contained in the MFN^M08 message.MFN^M04 – Charge Description – reference orderable items, contained in the MFN^M08 and MFN^M10 messages.Key Technical DecisionsOne of the primary features of this implementation guide is its focus on key points of broad interoperability. The HL7 implementation guides in Section REF _Ref215744437 \w \h 1.2.2 REF _Ref215744453 \h Requisite Knowledge informed the content of this specification.Use of ISO Object Identifier (OID)OIDs, or Object Identifiers, provide a strong identifier that uniquely identifies the object in question and is global in scope. Examples of information that OIDs can identify are items about patients, orders, providers and organizations. This means the identifier includes enough information to remain unique when taken out of the context within which the identifier was created. The ISO OID specification (ISO/IEC 8824:1990(E)) is the globally accepted technology for this purpose and is recommended as the means to satisfy the requirement for a universally unique identifier.This guide defines a Globally Unique Component (eDOS_GU_Component) (see Section REF _Ref215499751 \r \h \* MERGEFORMAT 3.5.1.2) that prescribes the use of an ISO Object Identifier (OID) for a specific set of fields.HL7 has developed an implementation guide for the use of OIDs, “HL7 Implementation Guidance for Unique Object Identifiers (OIDs), Release 1”, which provides guidance on how organizations can use and manage OIDs.Use of Vocabulary StandardsThis guide calls for specific vocabulary standards for the exchange of laboratory information such as LOINC. This terminology is updated periodically and it is best practice to use the most current version of the coding system.Field Length and TruncationThis guide is silent as to the field length definition conventions, lengths, and truncation rules and directs the reader to HL7 Version 2.7.1, Chapter 2 Control for informative guidance.Scope of ImplementationThe base standard indicates that receiving applications “…SHALL process (save/print/archive/etc.)…”. Due to receiving system variations and need, this guide does not specifically indicate for each field whether to store it or not. This is left to the individual system's scope and purpose.Ask at Order Entry ObservationsAsk at Order Entry responses are recorded as observations that provide critical information for the calculation or interpretation of some lab results or to satisfy state and federal health agency mandated information gathering requirements, e.g., for blood lead testing. For additional information on AOE, refer to OM1-31 (Observations Required to Interpret This Observation) and REF _Ref225180302 \h Appendix A – Ask at Order Entry.Referenced Profiles – AntecedentsThis specification documents a message profile for Electronic Directory of Service (eDOS) profile for Senders and Receivers based on the HL7 Version 2.5.1. Other laboratory ordering profiles were referenced and used as source materials in the development of this guide, including:HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 – US Realm January 2013EHR-Laboratory Interoperability and Connectivity Specification for Orders, ELINCS Orders, v1.0 June 28, 2011This document should not be considered the source of truth for any statement or assertion in regards to the referenced profiles. They are provided here as antecedent documentation and are not required for successful implementation of this Guide.Conformance to this GuideThis implementation guide (IG) conforms to the processes developed for the S&I Framework Initiatives with the intent to have all IGs conformance be consistent. The S&I Framework has attempted to build IGs that are consistent for all initiatives in a specific domain, such as Laboratory, and to provide profiles that further constrain the IG to accommodate other issues within the initiative. When profiles can be re-used across IGs within the domain the profile name will start with LAB_ and the OID will remain the same across all guides. In some cases profiles are providing unique constraints to the IG and will have a profile name and OID unique to the IG, e.g., LOI_ or LRI_.Profiles will always further constrain the IG and/or previously defined profiles as defined in the MSH-21 (Message Profile Identifier) field. While profiles should provide further constraints providing for a crisper more precise use of the interface, it should not violate the underlying HL7 standard. When possible, the combination of profiles should reduce the discussion between partners on what is expected of an interface. However, some profiles may be applicable to an instance of time to support the specific needs of the care situation. An example is the Newborn Profile in the Lab Order Interface (LOI) which adds the additional requirement of timestamps to include days and hours to assist with determining normal ranges but is only used when Newborn screening tests are ordered or reported.The Components must be combined to create a valid Profile for a particular transaction by populating MSH-21 (Message Profile Identifier) with the profile identifiers. Multiple profiles or component profiles can be present in MSH.21 provided the combination of profiles does not conflict with each other (as noted above). Additional definitions and guidance for MSH-21 can be found in Section REF _Ref225180401 \w \h 5.5.1 REF _Ref225180407 \h MSH – Message Header Segment.As of this version a valid eDOS profile consists of a minimum of two components:The eDOS_Common_Component ( REF _Ref221853522 \w \h 3.5.1.1)The eDOS_GU_Component (Globally Unique) OR the eDOS_NG_Component (Non-Globally Unique) ( REF _Ref221853567 \w \h 3.5.1.2, REF _Ref221853601 \w \h 3.5.1.3)Additional components are optional but may be included when supported by both trading partners. This guide includes one such component:LAB_XO_Component (Exclusions) ( REF _Ref221855107 \w \h 3.5.1.4)As of this version a valid response profile consists of a minimum of two components:The eDOS_Acknowledgement_Component ( REF _Ref233009718 \w \h 3.5.3.1)The GU_Acknowledgement_Component ( REF _Ref233009784 \w \h 3.5.3.2) OR the NG_Acknowledgement_Component ( REF _Ref233009801 \w \h 3.5.3.3)edos Profile ComponentsNote: the OIDs with red text will be updated once comment resolution is completed.The components that can be assembled into profiles are:eDOS_Common_Component – ID: 2.16.840.1.113883.9.AAThis component indicates that the message adheres to the rules set out in this implementation guide.Note: This component sets the minimum constraints on the base specification for all profiles defined by this guide and may be further constrained by additional components.eDOS_GU_Component (Globally Unique) – ID: 2.16.840.1.113883.9.BBThis component indicates that the following fields use Globally Unique Identifiers according to Section REF _Ref215744570 \r \h 3.3.1 REF _Ref215744581 \h Use of ISO Object Identifier (OID) for at least the assigning authority within the data type used.MSH-3 – Sending ApplicationMSH-4 – Sending FacilityMSH-5 – Receiving ApplicationMSH-6 – Receiving FacilityMFI-2 - Master File Application IdentifierThese fields must use the GU version of their data type definition.edos_NG_Component (Non-Globally Unique) – ID: 2.16.840.1.113883.This component indicates that the identification method has been negotiated between the trading partners where none or some may use ISO OIDs according to Section REF _Ref215744570 \r \h 3.3.1 REF _Ref215744581 \h Use of ISO Object Identifier (OID) while others use any of the identification methods allowed through the base standard. Consequently, these identifiers are not guaranteed to be globally unique.MSH-3 – Sending ApplicationMSH-4 – Sending FacilityMSH-5 – Receiving ApplicationMSH-6 – Receiving FacilityMFI-2 - Master File Application IdentifierThese fields must use the NG version of their data type definition.LAB_XO_Component (Exclusions) – ID: 2.16.840.1.113883.9.23This component is adopted as stated in the Standards and Interoperability Laboratory Results Interface Use Case, Laboratory Results Reporting to Primary Care Providers (in an Ambulatory Setting) v1.0, SectionOne of the basic premises of this guide is to enable senders to compose transactions that may satisfy multiple purposes, e.g., multiple implementation guides that share the same required fields and vocabulary. They therefore may populate any of the fields/components marked O (optional). At the same time this implementation guide wants to expressly reinforce that if data is sent in optional fields/segments, the receiver can completely ignore those. Therefore, the usage code X is used sparingly, while the usage code O is mostly used when the field/component is not necessary for the use case at hand. The rationale is that according to the definition of “X” per the base standard, “X” is "For conformant sending applications, the element shall not be sent. Conformant receiving applications may ignore the element if it is sent, or may raise an application error."However to accommodate those implementations where the population of any optional fields remaining is not desirable, the LAB_XO_Component is defined to indicate?that all of the remaining optional segments and fields that are marked O (Optional) are now considered to be marked with an X (Not Supported). Its use yields, in combination with the other profile components,?a fully implementable?profile in accordance with Chapter 2B. Note though that this component is strictly voluntary and cannot be mandated by either trading partner to be used to enable a successful results transaction.edos_INFO_Component – ID: 2.16.840.1.113883.9.ZZThis optional component indicates support for the exchange of additional information that is informative in nature where the information may be of use to the consuming system but is not required in an order. This component provides a pre-determined template provide additional content in a common model to facilitate implementation across systems. This profile currently provides guidance on the exchange of the following:OM2 – OM2.6, .7, .8 are RERFR – Reference Range - RFR.…eDOS Profiles (Pre-Coordinated Components)One may either enumerate the component IDs in MSH-21 (in no particular order), or use one of the profile IDs provided for each of the valid combinations:edos_GU_Profile ID: 2.16.840.1.113883.9.DDThis profile pre-coordinates the use of the eDOS_Common_Component and eDOS_GU_Componentedos_NG_Profile ID: 2.16.840.1.113883.9.EEThis profile pre-coordinates the use of the eDOS_Common_Component, and eDOS_NG_Component.Response Componentsedos_Acknowledgement_Component – ID: 2.16.840.1.113883.9.FFThis component indicates that the acknowledgement message adheres to the rules set out in this implementation guide.Note: This component sets the minimum constraints on the base specification for the acknowledgement and may be further constrained by additional components.GU_Acknowledgement_Component – ID: 2.16.840.1.113883.9.GGThis profile ID is used to identify an acknowledgment that is constrained for the profiles defined within this Guide in response to the eDOS Master File messages where MSH-21 contains 2.16.840.1.113883.9.DD (eDOS_GU_Component)NG_Acknowledgement_ Component – ID: 2.16.840.1.113883.9.HHThis profile ID is used to identify an acknowledgment that is constrained for the profiles defined within this Guide in response to the eDOS Master File messages where MSH-21 contains 2.16.840.1.113883.9.EE (eDOS_NG_Component).Response Profiles (Pre-Coordinated Components)One may either enumerate the component IDs in MSH-21 (in no particular order), or use one of the profile IDs provided for each of the valid combinations:edos_GU_Response_Profile ID: 2.16.840.1.113883.9.IIThis profile pre-coordinates the use of the eDOS_Acknowledgement_Component and the GU_Acknowledgement_Componentedos_NG_Response_Profile ID - 2.16.840.1.113883.9.JJThis profile pre-coordinates the use of the eDOS_Acknowledgement_Component and the NG_Acknowledgement_ComponentExtended Profile UseThe sender may?create other components?or profiles that are defined outside of this implementation guide for use in conjunction with the profiles/components defined in this guide. However, those profiles/components are strictly voluntary, must be agreed to by trading partners, and shall?be properly constrained against the base standard and the profiles/components defined in this IG.DeliveryThe complete laboratory test compendium should be delivered to initialize an interface. Additional points for consideration are:The delivery of the complete compendium should also be available at any time upon request.The delivery of the test compendium, either full or partial, should be an automated process between the Compendium Producer and Compendium Consumer.The delivery of the compendium should not negatively impact the successful delivery of patient results into the recipient’s system. Therefore, it is recommended that a separate channel of communication be instituted for transmission of the Master Files data.The compendium is expected to be processed by the Compendium Consumer upon receipt.Maintenance UpdatesMaintenance files should only contain additions, deactivations and/or updates to the test compendium. The frequency of delivery of an updated compendium is a decision between the Compendium Producer and the Compendium Consumer; “best practice” intervals are not recommended in this document.The content of the current message?will replace the contents from a prior message for the same information object.? Therefore, for each update or reactivation or deactivation to the test compendium, all the information for a given test, panel, etc. must be resent -? not just the new or revised information for that test or panel.File Naming ConventionsWhen applicable, file-naming conventions should be implemented for routing of the compendium into a client’s system. The MSH identifier in MSH-9 will identify the type of message being transmitted. It is not the intention of this guide to recommend specific file name conventions.Transport LayerThis specification does not address network protocols or the transport layer.Data TypesData types are further defined in this implementation guide for all fields that?have a usage of?R, RE, C(a/b). Data types used only for optional fields are not included. Please?refer to the base standard for those data types.Depending on the components used, the usage of data type components for some data types varies. To clearly indicate when to use specific data type components, each data type that has a varying definition based on profile will be documented with multiple variations, e.g., CX_GU vs. CX_NG. Composite data types indicate which variety of the component's data type is applicable, while the data type of a field is marked as "varies" where the comment indicates the data type choices based on the declared profile or E – Coded With No ExceptionsTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 1. Coded With No Exceptions (CNE)SEQComponent NameDTUsageValue SetComments1IdentifierSTR2TextSTR3Name of Coding SystemIDRHL703964Alternate IdentifierO5Alternate TextO6Name of Alternate Coding SystemO7Coding System Version IDSTRE8Alternate Coding System Version IDO9Original TextOCWE – Coded with ExceptionsCWE – Coded with Exceptions – BaseNote: Components 10-22 are pre-adopted from V2.7.1 CWE.Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 2. Coded With Exceptions – Base (CWE)SEQComponent NameDTUsageValue SetComments1IdentifierSTC(R/O)Condition Predicate: if CWE.2 is not valued.2TextSTC(R/RE)Condition Predicate: if CWE.1 is not valued,3Name of Coding SystemIDC(R/X)HL70396Condition Predicate: if CWE.1 is valued.4Alternate IdentifierO5Alternate TextO6Name of Alternate Coding SystemO7Coding System Version IDSTC(RE/X)Condition Predicate: If CWE.3 (Name Of Coding System) is valued.8Alternate Coding System Version IDSTC(RE/X)Condition Predicate: If CWE.6 (Name Of Alternate Coding System) is valued.9Original TextO10Second Alternate IdentifierO11Second Alternate TextO12Second Name of Alternate Coding SystemO13Second Alternate Coding System Version IDO14Coding System OIDO15Value Set OIDO16Value Set Version IDO17Alternate Coding System OIDO18Alternate Value Set OIDO19Alternate Value Set Version IDO20Second Alternate Coding System OIDO21Second Alternate Value Set OIDO22Second Alternate Value Set Version IDOUsage NoteThe CWE data type is used where it is necessary to communicate a code, text, or coding system and the version of the coding system the code was drawn from and alternate codes drawn from another coding system. Many coded fields in this specification identify coding systems or value set attributes that must be used for the field. When populating the CWE data types with these values, this guide does not give preference to the triplet in which the standard code should appear. CWE_CRE – Coded with Exceptions – Code Required, but May Be EmptyNOTE: Components 10-22 are pre-adopted from V2.7.1 CWE.Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 3. Coded with Exceptions – Code Required But May Be Empty (CWE_CRE) SEQComponent NameDTUsageValue SetComments1IdentifierSTRE2TextSTC(RE/X)Condition Predicate: If CWE_CRE.1 (Identifier) is valued.It is strongly recommended that text be sent to accompany any identifier. When a coded value is not known, the original text element (CWE_CRE.9) is used to carry the text, not the text (CWE_CRE.2) element.3Name of Coding SystemIDC(R/X)HL70396Condition Predicate: If CWE_CRE.1 (Identifier) is valued.4Alternate IdentifierSTC(RE/X)Condition Predicate: If CWE_CRE.1 (Identifier) is valued.The alternate identifier (from the alternate coding system) should be the closest match for the identifier found in CWE_CRE.1 (Identifier).5Alternate TextSTC(RE/X)Condition Predicate: If CWE_CRE.4 (Alternate Identifier) is valued.It is strongly recommended that alternate text be sent to accompany any alternate identifier.6Name of Alternate Coding SystemIDC(R/X)HL70396Condition Predicate: If CWE_CRE.4 (Alternate Identifier) is valued.7Coding System Version IDSTC(RE/X)Condition Predicate: If CWE_CRE.3 (Name Of Coding System) is valued.8Alternate Coding System Version IDSTC(RE/X)Condition Predicate: If CWE_CRE.6 (Name Of Alternate Coding System) is valued.9Original TextSTC(R/RE)Condition Predicate: If CWE_CRE.1 (Identifier) and CWE.4_CRE (alternate identifier) are not valued.Original Text is used to convey the text that was the basis for coding.If neither the first or second triplet has values, this contains the text of the field.10Second Alternate IdentifierO11Second Alternate TextO12Second Name of Alternate Coding SystemO13Second Alternate Coding System Version IDO14Coding System OIDO15Value Set OIDO16Value Set Version IDO17Alternate Coding System OIDO18Alternate Value Set OIDO19Alternate Value Set Version IDO20Second Alternate Coding System OIDO21Second Alternate Value Set OIDO22Second Alternate Value Set Version IDOUsage NoteThe sender shall always populate the first triplet before populating other triplets; the receiver shall examine all triplets to find relevant values.The CWE_CRE data type is used where it is necessary to communicate a code, text, or coding system and the version of the coding system the code was drawn from and alternate codes drawn from another coding system. Many coded fields in this specification identify coding systems or value set attributes that must be used for the field. When populating the CWE_CRE data types with these values, this guide does not give preference to the triplet in which the standard code should appear. CWE_RC – Required ComponentsNOTE: Components 10-22 are pre-adopted from V2.7.1 CWE.Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 4. Coded with Exceptions – Required Components (CWE_RC)SEQComponent NameDTUsageValue SetComments1IdentifierSTR2TextSTR3Name of Coding SystemIDRHL703964Alternate IdentifierO5Alternate TextO6Name of Alternate Coding SystemO7Coding System Version IDSTC(RE/X)Condition Predicate: If CWE_RC.3 (Name Of Coding System) is valued.8Alternate Coding System Version IDO9Original TextO10Second Alternate IdentifierO11Second Alternate TextO12Second Name of Alternate Coding SystemO13Second Alternate Coding System Version IDO14Coding System OIDO15Value Set OIDO16Value Set Version IDO17Alternate Coding System OIDO18Alternate Value Set OIDO19Alternate Value Set Version IDO20Second Alternate Coding System OIDO21Second Alternate Value Set OIDO22Second Alternate Value Set Version IDOUsage NoteThe CWE_RC data type is used in OM1-2 Producer’s Service/Test/Observation ID to support the HL7 Standard requirement that the first three components should be non-null.CWE_RC1 – Required ComponentsNOTE: Components 10-22 are pre-adopted from V2.7.1 CWE.Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 5. Coded with Exceptions – Required Components (CWE_RC)SEQComponent NameDTUsageValue SetComments1IdentifierSTR2TextSTR3Name of Coding SystemIDRHL703964Alternate IdentifierRE5Alternate TextRE6Name of Alternate Coding SystemC(R/X)Condition Predicate: if CWE_RC.4 (Alternate Identifier) or CWE_RC.5 (Alternate Text) is valued.7Coding System Version IDSTC(RE/X)Condition Predicate: If CWE_RC.3 (Name Of Coding System) is valued.8Alternate Coding System Version IDC(RE/X)Condition Predicate: If CWE_RC.6 (Name Of Coding System) is valued.9Original TextO10Second Alternate IdentifierO11Second Alternate TextO12Second Name of Alternate Coding SystemO13Second Alternate Coding System Version IDO14Coding System OIDO15Value Set OIDO16Value Set Version IDO17Alternate Coding System OIDO18Alternate Value Set OIDO19Alternate Value Set Version IDO20Second Alternate Coding System OIDO21Second Alternate Value Set OIDO22Second Alternate Value Set Version IDOUsage NoteThe CWE_RC data type is used in OM1-2 Producer’s Service/Test/Observation ID to support the HL7 Standard requirement that the first three components should be non-null.CQ – Composite Quantity with UnitsTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 6. Composite Quantity with Units (CQ)SEQComponent NameDTUsageValue SetComments1QuantityNMR2UnitsCWEREUnified Code for Units of Measure (UCUM)EI – Entity IdentifierEI_GU – Entity Identifier (Globally Unique)Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 7. Entity Identifier (EI_GU)SEQComponent NameDTUsageValue SetComments1Entity IdentifierSTR2Namespace IDISRE.3Universal IDSTR4Universal ID TypeIDRFixed to ‘ISO’.Usage NoteThe EI_GU data type is used to carry identifiers. This GU profile requires that all entity identifiers be accompanied by assigning authorities. This allows the exchange of unique identifiers for the associated object across organizational and enterprise boundaries, enabling broad interoperability.In the EI data type, the Namespace ID, Universal ID and Universal ID type correspond to the HD data type identified elsewhere. These types, together, are commonly considered the assigning authority for the identifier.Conformance Statements: eDOS_GU ProfileeDOS-6: EI_GU.3 (Universal ID) SHALL be valued with an ISO-compliant OID.eDOS-7: EI_GU.4 (Universal ID Type) SHALL contain the value ‘ISO’.EI_NG – Entity Identifier (Non-Globally Unique)Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 8. Entity Identifier (EI_NG)SEQComponent NameDTUsageValue SetComments1Entity IdentifierSTR2Namespace IDISC(R/O)Condition Predicate: If EI_NG.3 (Universal ID) is not valued.3Universal IDSTC(R/O)Condition Predicate: If EI_NG.2 (Namespace ID) is not valued.4Universal ID TypeIDC(R/X)HL70301 (V2.7.1)Condition Predicate: If EI_NG.3 (Universal ID) is valued.Usage NoteThe EI_NG data type accommodates identifiers that are not globally unique and therefore may not have the assigning authority (components 3-4) populated. Local arrangements determine how uniqueness is established.HD_GU – Hierarchic DesignatorHD_GU – Hierarchic Designator (Globally Unique)Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 9. Hierarchic Designator (HD_GU)SEQComponent NameDTUsageValue SetComments1Namespace IDISREThe value of HD_GU.1 reflects a local code that represents the combination of HD_GU.2 and HD_GU.3.2Universal IDSTR3Universal ID TypeIDRFixed to ‘ISO’.Usage NoteThe actual value of and use of components must be negotiated between trading partners for each of the fields where this data type is used.The HD data type is used directly to identify objects such as applications or facilities. It is used also as a component of other data types, where it is typically an assigning authority for an identifier. Where this capability is used in this specification, the usage is described separately. Note that the HD_GU data type has been constrained to carry an OID identifying an application, a facility, or an assigning authority.Conformance Statements: eDOS_GU ProfileeDOS-8: HD_GU.2 (Universal ID) SHALL be valued with an ISO-compliant OID.eDOS-9: HD_GU.3 (Universal ID Type) SHALL contain the value ‘ISO’.HD_NG – Hierarchic Designator (Non-Globally Unique)Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 10. Hierarchic Designator (HD_NG)SEQComponent NameDTUsageValue SetComments1Namespace IDISC(R/O)Condition Predicate: If HD_NG.2 (Universal ID) is not valued.2Universal IDSTC(R/O)Condition Predicate: If HD_NG.1 (Namespace ID) is not valued.3Universal ID TypeIDC(R/X)HL70301 (V2.7.1)Condition Predicate: If HD_NG.2 (Universal ID) is valued.Usage NoteThe actual value of and use of components must be negotiated between trading partners for each of the fields where this data type is used.The HD_NG data type is used directly to identify objects such as applications or facilities. It is used also as a component of other data types, where it is typically an assigning authority for an identifier. Where this capability is used in this specification, the usage is described separately.MSG – Message TypeTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 11. Message Type (MSG)SEQComponent NameDTUsageValue SetComments1Message CodeIDRHL70076 (constrained)2Trigger EventIDRHL70003(constrained)3Message StructureIDRHL70354 (constrained)NR – Numeric RangeTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 12. Numeric Range (NR)SEQComponent NameDTUsageValue SetComments1Low ValueNMREIf the low value is unbounded, then the component is null.2High ValueNMREIf the high value is unbounded, then the component is null.PT – Processing TypeTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 13. Processing Type (PT)SEQComponent NameDTUsageValue SetComments1Processing ID IDRHL701032Processing Mode ORFR – Reference RangeNote: CWE is pre-adopted from HL7 V2.7.1Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 14. RFR – Reference RangeSEQComponent NameDTUsageValue SetComments1Numeric RangeNRR2Administrative SexCWEREHL70001This data type is used in OM2-6 (Reference (Normal) Range for Ordinal and Continuous Observations), OM2-7 (Critical Range for Ordinal and Continuous Observations), and OM2-8 (Absolute Range for Ordinal and Continuous Observations). This component shall use the HL7 2.5.1 User-defined Table 0001 - Administrative Sex.3Age RangeO4Gestational Age RangeO5SpeciesO6Race/subspeciesCWEREHL70005 (V2.7.1)This data type is used in OM2-6, OM2-7, and OM2-8. The eDOS IG treats RFR.6 as a CWE data type by defining the format for the component. This component shall use the HL7 2.7.1 User-defined Table 0005 - Race. 7ConditionsTXOTS_1 – Time Stamp 1Table STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 15. Stamp 1 (TS_1)SEQComponent NameDTUsageValue SetComments1 Time DTMR2 Degree of Precision XExcluded for this Implementation Guide, see Section REF _Ref215745732 \r \h 1.3.1.The DTM component of this Time Stamp has the following constraints:YYYYDTMRMMDTMRDDDTMRHHDTMRMMDTMRSSDTMR[.S[S[S[S]]]]O+/- ZZZZDTMVariesLAB_TO_Component Usage: ‘R’All other profiles Usage: ‘O’VID – Version IdentifierTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 16. Version Identifier (VID)SEQComponent NameDTUsageValue SetComments1 Version IDIDRConstrained to ‘2.5.1’ from HL701042 Internationalization CodeO3 International Version IDOConformance Statement – LOI_Common_ComponenteDOS-XX: VID.1 (Version Identifier) SHALL be valued with ‘2.5.1’.XAD – Extended AddressTable STYLEREF 1 \s 4 SEQ Table \* ARABIC \s 1 17. Extended Address (XAD)SEQComponent NameDTUsageValue SetComments1 Street Address SADRE2 Other Designation STO3 City STRE4 State or Province STREUSPS Alpha State Codes.5 Zip or Postal Code STRE.6 Country CodeIDREHL70399Use 3-character (alphabetic) form of ISO 3166 for HL7 Table 0399 as defined in HL7 Chapter 2, Section 2.15.9.17.7 Address Type IDREHL701908 Other Geographic Designation O9 County/Parish Code O10 Census Tract O11 Address Representation Code O12 Address Validity Range XExcluded for this Implementation Guide, see Section REF _Ref215745732 \r \h 1.3.1.13 Effective Date O14 Expiration Date OMessagesThe following trigger events and messages are supported in this specification:Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 1. Trigger Events and MEssagesTrigger EventMessageNameM08MFN^M08Master File Notification – Test/ObservationM10MFN^M10Master File Notification – Test/Observation BatteriesM04MFN^M04Master File Notification – Charge DescriptionMFKMFK^M08^MFK MFK^M10^MFK MFK^M04^MFKMessage AcknowledgementMFN^M08^MFN_M08 – Master File Notification – Test/Observation (Numeric)This message is used to transmit Master File/compendium information on all tests/observations. The OM2 and OM3 segments were Conditional in Release 1 of this Implementation Guide, however, there is no data in the OM1 segment to indicate whether the OM2 or OM3 segment should be included, and occasionally, it is possible that some tests would include both the OM2 and OM3 segments. Therefore the OM2 and OM3 segment usage in Release 2 is “RE-Required but may be empty”.Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 2. M08 – Master File Notification – Test/Observation (Numeric)SegmentNameUsageCardinalityDescriptionMSHMessage HeaderR[1..1][{SFT}]SoftwareO MFIMaster File IdentificationR[1..1] {MF TEST BeginR[1..*] MFEMaster File EntryR[1..1] OM1General Segment (Fields That Apply to Most Observations)R[1..1] OM2Numeric Observation SegmentVaries[0..1]eDOS_INFO_Component Usage: ‘RE’All other profiles Usage: ‘O’ OM3Categorical Service/Test/Observation SegmentRE[0..1] [{OM4}]Observations that Require SpecimensRE[0..*]Pre-adopted cardinality from V2.8. }MF TEST EndMFN^M10^MFN_M10 – Master File Notification – Test/Observation BatteriesThis message is used to transmit Master File / compendium information on all grouped orderable items (batteries, panels, profiles, etc.).Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 3. M10 – Master File Notification – Test/Observation BatteriesSegmentNameUsageCardinalityDescriptionMSHMessage HeaderR[1..1][{SFT}]SoftwareOMFIMaster File IdentificationR[1..1] {MF BATTERY BeginR[1..*] MFEMaster File EntryR[1..1] OM1General Segment (Fields That Apply to Most Observations)R[1..1] [BATTERY DETAIL BeginR OM5Observation Batteries (sets)R[1..1] [{OM4}]Observations that Require SpecimensRE[0..*] ]BATTERY DETAIL End }MF BATTERY EndMFN^M04^MFN_M04 – Charge Description Master File MessageThis message is used to capture generic procedure codes (CPTs) to describe the billable activities performed with each orderable item. Note: For the Lab Test Compendium, the Charge Description Master File Message (MFN^M04^MFN_M04) must be sent after the test master updates for the Order Codes. It may also be necessary for the receiving system to update those records into their master file prior to uploading this file. This file will contain only the Order Code and the CPT codes assigned to that Order Code. It is important to note that the CPT code under certain criteria repeats. See Usage Note in section 8.10.2.7 of the HL7 Standard Version 2.5.1 (CDM-7) re: Procedure Code repetitions.The NTE segment may also contain other information to the provider to convey other requirements or context. For example:“Convey the status of Federal Drug Administration (FDA) approval of the test. For example, the test may have FDA approval but is not validated yet because of limited gathering of data to confirm the validity of the test.” Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 4. M04 – Charge Description Master File MessageSegmentNameUsageCardinalityDescriptionMSHMessage HeaderR[1..1][{SFT}]SoftwareO MFIMaster File IdentificationR[1..1] [{NTE}]Notes and CommentsRE[0..*]Pre-adopted V2.8.1. {MF_CDM BeginR[1..*] MFEMaster File EntryR[1..1] [{NTE}]Notes and CommentsRE[0..*]Pre-adopted V2.8.1. CDMCharge Description MasterR[1..1] [{NTE}]Notes and CommentsRE[0..*]Pre-adopted V2.8.1. [{PRC}]Price SegmentO }MF_CDM EndMFK^VARIES^MFK_M01The HL7 Message Structure as defined in HL7 Table 0354 – Message Structure, which is used for Master File Acknowledgment by the M04, M08, and M10, is the same structure: MFK_M01. Trigger event acknowledgments are identified in the base standard as: MFK^M04^MFK_M01, MFK^M08^MFK_M01, or MFK^M10^MFK_M01.Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 5. MFK^Mxx^MFK Abstract Message SyntaxSegment NameUsageCardinalityDescriptionMSHMessage HeaderR[1..1]The message header (MSH) segment contains information describing how to parse and process the message. This includes identification of message delimiters, sender, receiver, message type, timestamp, etc. [{SFT}]Software SegmentO MSAMessage AcknowledgmentR[1..1]The Message Acknowledgment Segment (MSA) contains the information sent as acknowledgment to the order message received by a LIS or EHR-S. [{ERR }]ErrorC(R/O)[0..*]Condition predicate: If MSA-1 (Message Acknowledgement) is not valued AA or CA.MFIMaster File IdentificationR[1..1][{MFA]}Master File ACK segmentOSegment and Field DescriptionsThis messaging guide provides notes for required (non-optional) fields for each of the non-optional segments. For each segment the segment table defines the applicable constraints on usage for its fields for this implementation guide (see Section REF _Ref215760553 \w \h 1.3.2 REF _Ref215770912 \h Message Element Attributes for a description of the columns in the Segment Attribute Tables.) All the relevant conformance statements and general Usage Notes are located at the end of each table.Note that any optional segments that are brought forward from the base will have to be used within the constraints set forth in this guide, and agreement about which CWE data type flavor to use needs to be reached.MSH – Message Header SegmentTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 6. Message Header Segment (MSH)SEQElement NameDTUsageCardinalityValue SetComment1Field SeparatorSTR[1..1]2Encoding CharactersSTR[1..1]Constrained to the literal values ‘^~\&’ or ‘^~\&#’, always appearing in the same order.3Sending ApplicationVariesRE[0..1]HL70361Field that may be used to identify the sending application uniquely for messaging purposes. If populated, it will contain an OID or other unique identifier that represents the sending application instance. Example: ^11A1234567^CLIAGU Data Type: HD_GUNG Data Type: HD_NG4Sending FacilityVariesR[1..1]HL70362GU Data Type: HD_GUNG Data Type: HD_NGIf acknowledgments are in use, this facility will receive any related acknowledgment message.5Receiving ApplicationO6Receiving FacilityVariesRE[0..1]HL70362GU Data Type: HD_GUNG Data Type: HD_NGIf acknowledgments are in use, this facility originates any related acknowledgment message.7Date/Time Of MessageTS_1R[1..1]Date of when the file was created.If the time zone offset is included in MSH-7 it becomes the default time zone for the message instance and applies to all other date/time fields in that same message instance where a time zone offset is not valued.8SecurityO9Message TypeMSGR[1..1]10Message Control IDSTR[1..1]String that identifies the message instance from the sending application. Example formats for message control IDs include GUID, timestamp plus sequence number, OID plus sequence number or sequence number. The important point is that care must be taken to ensure that the message control id is unique within the system originating the message.11Processing IDPTR[1..1]12Version IDVIDR[1..1]HL7 version number used to interpret format and content of the message. Constrained to the literal value ‘2.5.1’.13Sequence NumberO14Continuation PointerO15Accept Acknowledgment TypeIDR[1..1]HL7015516Application Acknowledgment TypeIDR[1..1]HL7015517Country CodeO18Character SetO19Principal Language Of MessageO20Alternate Character Set Handling SchemeO21Message Profile IdentifierEI_GUR[1..*]The sender asserts that the message conforms to a given profile and/or valid combination of components.Usage NoteMSH-15 – Accept Acknowledgment TypeThe MSH-15 (Accept Acknowledgment Type) field is fixed to the value of ‘AL’ (Always), while MSH-16 (Application Acknowledgment Type) is fixed to the value of ‘NE’ (Never).Conformance Statements: eDOS_Common_ComponenteDOS-10: MSH-1 (Field Separator) SHALL contain the constant value ‘|’.eDOS-11: MSH-2 (Encoding Characters) SHALL contain the constant value ‘^~\&’ or the constant value ‘^~\&#’.eDOS-12: MSH-12.1 (Version ID) SHALL contain the constant value ‘2.5.1’.eDOS-13: MSH-15 (Accept Acknowledgement Type) SHALL contain the constant value ‘AL’.eDOS-14: MSH-16 (Application Acknowledgement Type) SHALL contain the constant value ‘NE’.MSA – Acknowledgement SegmentTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 7. Acknowledgment Segment (MSA)SEQElement NameDTUsageCardinalityValue SetDescription/Comments1Acknowledgment CodeIDR[1..1]HL700082Message Control IDSTR[1..1]3Text MessageXExcluded for this Implementation Guide, see Section REF _Ref215770746 \w \h 1.3.1.4Expected Sequence NumberO5Delayed Acknowledgment TypeXExcluded for this Implementation Guide, see Section REF _Ref215770746 \w \h 1.3.1.6Error ConditionXExcluded for this Implementation Guide, see Section REF _Ref215770746 \w \h 1.3.1.ERR – Error SegmentTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 8. Error Segment (ERR)SEQElement NameDTUsageCardinalityValue SetDescription/Comments1Error Code and LocationXExcluded for this Implementation Guide, see Section REF _Ref215770746 \w \h 1.3.1.2Error LocationO3HL7 Error CodeCWER[1..1]HL703574SeverityIDR[1..1]HL705165Application Error CodeO6Application Error ParameterO7Diagnostic InformationTXRE[0..1]8User MessageO9Inform Person IndicatorO10Override TypeO11Override Reason CodeO12Help Desk Contact PointOMFI – Master File Identification Segment XE "HL7 Attribute Table - MFI" XE "HL7 Attribute Table - Master File Identification" Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 9. Master File Identification (MFI)SEQElement NameDTUsageCardinalityValue SetComment1Master File IdentifierCWER[1..1]HL70175Identifies an initial download of or an update to the Directory of Service. Example of populated CWE: OMC^Observation batteries master file^HL70175.2Master File Application IdentifierO3File-Level Event CodeIDR[1..1]HL70178Pre-adopted V2.7.1 Note:Note: The replace option allows the sending system to replace a file without sending delete record-level events for each record in that file. UPD means that the events are defined according to the record-level event code contained in each MFE segment in that message. 4Entered Date/TimeO5Effective Date/TimeXThe Effective Date/Time shall be specified at the test level in the OM1-22 (Effective Date/Time of Change).6Response Level CodeIDR[1..1]HL70179This Response Level Code acknowledgement type should be consistent with communication processes already established for orders and/or results interfaces.Constrained to the value ‘NE’ from HL70179 Response Level.Conformance Statements: Base ProfileeDOS-15: If MSH-9.2 (Message Type^Trigger Event) is valued ‘M04’ then MFI-1.1 (Identifier) SHALL be valued ‘CDM’.eDOS-xx: If MSH-9.2 (Message Type^Trigger Event) is valued ‘M08’ then MFI-1.1 (Identifier) SHALL be valued ‘OMA’.eDOS-xx: If MSH-9.2 (Message Type^Trigger Event) is valued ‘M10’ then MFI-1.1 (Identifier) SHALL be valued ‘OMC’.MFE – Master File Entry SegmentTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 10. Master File Entry (MFE)SEQElement NameDTUsageCardinalityValue SetComment1Record-Level Event CodeIDR[1..1]HL70180 (constrained)This field will be used to Add, Update, Deactivate, or Reactivate a test code. Delete has been removed due to historical needs.2MFN Control IDSTC(R/O)[0..1]Condition Predicate: Required if MFI-6 Response Level Code is any value other than ‘NE’.3Effective Date/TimeTS_1R[1..1]4Primary Key Value – MFECWE_RCR[1..1]MFE-4 (Primary Key Value – MFE) shall match OM1-2 (Producer's Service/Test/Observation ID).5Primary Key Value TypeIDR[1..1]Constrained value to ‘CWE’ from HL70355 Primary Key Value TypeConformance Statements: EDOS-XX: MFE-5 (Primary Key Value Type) SHALL be valued ‘CWE’.OM1 – General SegmentNote: This IG pre-adopts the V2.8 field deprecation of OM1-8 (Other Names) in favor of OM1-51 (Other Names), and OM1-16 (Observation Producing Department/Section) in favor of OM1-49 (Diagnostic Service Sector ID).Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 11. General Segment (OM1)SEQElement NameDTUsageCardinalityValue SetComment1Sequence Number - Test/Observation Master FileNMR[1..1]2Producer's Service/Test/Observation IDCWE_RCR[1..1]99993Permitted Data TypesO4Specimen RequiredIDR[1..1]HL70136This will be Y(es) for orderable tests. This may be N(o) for non-orderable components, like laboratory-performed calculations, administrative tests (24 hr urine volume).5Producer IDCWER[1..1]99996Observation DescriptionO7Other Service/Test/Observation IDs for the ObservationCWE_RCRE[0..*]Pre-adopt V2.8 definition.8Other NamesXExcluded for this Implementation Guide, see Section REF _Ref215770746 \w \h 1.3.1.9Preferred Report Name for the ObservationSTRE[0..1]10Preferred Short Name or Mnemonic for ObservationSTC(R/O)[0..1]Condition Predicate: If OM1-9 (Preferred Report Name for the Observation) and OM1-11 (Preferred Long name for the observation are not valued. 11Preferred Long Name for the ObservationSTC(R/O)[0..1]Condition Predicate: If OM1-9 (Preferred Report Name for the Observation) and OM1-10 (Preferred Short Name or Mnemonic for Observation) are not valued.12OrderabilityIDR[1..1]HL7013613Identity of Instrument Used to Perform this StudyO14Coded Representation of MethodO15Portable Device IndicatorO16Observation Producing Department/SectionXExcluded for this Implementation Guide, see Section REF _Ref215770746 \w \h 1.3.1.17Telephone Number of SectionO18Nature of Service/Test/ObservationISR[1..1]HL7017419Report SubheaderO20Report Display OrderO21Date/Time Stamp for any change in Definition for the ObservationO22Effective Date/Time of ChangeO23Typical Turn-Around TimeNMRE[0..1]Presented in minutes, upon receipt of specimen.24Processing TimeO25Processing PriorityO26Reporting PriorityO27Outside Site(s) Where Observation may be PerformedCWERE[0..*]999928Address of Outside Site(s)XADC(R/O)[0..*]Condition Predicate: If OM1-27 is valued.If the lab providing the Directory of Service is not the performing laboratory and sends the work to an outside facility this information shall be provided.29Phone Number of Outside SiteO30Confidentiality CodeO31Observations Required to Interpret the ObservationCWERE[0..*]9999This field will contain the Ask at Order Entry (AOE) question(s).CWE data type pre-adopted from V2.7.1; cardinality ( unlimited repeats) pre-adopted from V2.8.Refer to Appendix A – Ask at Order Entry for additional information.32Interpretation of ObservationsTXRE[0..1]Examples of information included in this field are Clinical Significance, Additional Notes, and Compliance Remarks.33Contraindications to ObservationsCWERE[0..*]9999Examples of information included in this field are Limitations or Contraindications that may affect the observations.Pre-adopt V2.8 cardinality34Reflex Tests/ObservationsCWE_RC1RE[0..*]9999This field contains all potential reflex tests for this test/observation.35Rules that Trigger Reflex TestingTXRE[0..*]This repeating field refers to the corresponding position within OM1-34 (Reflex Tests/Observations). For example, the third member of this field identifies the conditions for the third reflex test listed in OM1-34.Pre-adopt V2.8 cardinality36Fixed Canned MessageO[0..*]Pre-adopt V2.8 cardinality37Patient PreparationTXRE[0..*]This field indicates any patient preparation required prior to collecting the specimen(s) for this observation. For example, Patient fasting required for 12 hours.Pre-adopt V2.8 cardinality38Procedure MedicationO39Factors that may Affect the ObservationTXRE[0..1]This field shall contain information such as Causes for Rejection (i.e…Hemolyzed sample, Quantity not sufficient, Clotted sample, etc.).40Service/Test/Observation Performance ScheduleSTRE[0..*]An example of a performance schedule may be “every Monday, Wednesday, Friday”. Other ways that this might be displayed are “Mon, Wed, Fri” or “M, W, F.”41Description of Test MethodsO42Kind of Quantity ObservedO43Point Versus IntervalO44Challenge InformationO45Relationship ModifierO46Target Anatomic Site Of TestO47Modality Of Imaging MeasurementO48Exclusive TestIDRE[0..1]HL70919Pre-adopted V2.8HL7 Definition: This field defines if this test should be a specific event with no other tests to be performed with this test. Refer to HL7 Table 0919 – Exclusive Test for valid values and expected behaviors.When ‘D’ is specified for this field, field OM1-49 determines how tests must be grouped together. Tests within the same Diagnostic Service Sector may be on the same requisition, and therefore in the same message49Diagnostic Service Sector IDIDRE[0..1]HL70074Pre-adopted V2.8HL7 Definition: This field is the section of the diagnostic service where the observation was performed. If the study was performed by an outside service, the identification of that service should be recorded here. Refer to Chapter 4, Section 4.5.3.24, HL7 Table 0074 - Diagnostic service section ID for valid entries.The laboratory Performing Department; used in conjunction with OM1-48 to determine if the requisition/specimen must be packaged / sent separately from other tests on this order. This function is commonly known as “Split Requisitions” within the laboratory industry.ACLA recommends referring to HL7 Table 0074 Diagnostic Service Sector ID. This is consistent with messaging in OBR-24 for orders and results.50Taxonomic Classification CodeO51Other NamesSTRE[0..*]Pre-adopted V2.8 revision that depreciates OM1-8 in favor of this fieldList alll alias names for the test.HL7 Definition: This field contains any test aliases or synonyms for the name in the context of the ordering service. These are alternative names, not associated with a particular coding system, by which the battery, test, or observation (e.g., measurement, test, diagnostic study, treatment, etc.) is known to users of the system. Multiple names in this list are separated by repeat delimiters.52Replacement Producer’s Service/Test/Observation IDCWE_RC1C(RE/O)[0..*]9999Condition Predicate: If MFE-1 = MDCPre-adopted V2.8.1.Definition: This field is used in conjunction with a MFE-1 Record-Level Event Code ‘MDC’ defined as: “Deactivate: discontinue using record in master file, but do not delete from database”, in conjunction with an OM1 segment providing detail for the deactivate code. When the OM1-2 Producer’s Service/Test/Observation ID is being deactivated, use OM1-52 to indicate the producer’s replacement test or observation code(s), as it was defined in the OM1-2 Producer’s Service/Test/Observation ID when the new/replacement code was added.53Prior Resuts InstructionsTXRE[0..*]Pre-adopted V2.8.1Definition: This field is used to indicate when the test in OM1-2 Producer’s Service/Test/Observation ID is ordered, prior results should accompany the order (OML^O21^OML_O21: Laboratory Order Message). For example, when ordering a Thyroid FNA (Fine Needle Aspiration) Evaluation, send the prior results of Ultrasound Findings. The instructions may also indicate a timeframe; for example, send the prior results of CBC in past 60 days.54Special InstructionsTXRE[0..*]Pre-adopted V2.8.1Definition: This field is used to convey special instructions for the test, for example: “Chain-of-custody documentation is required for samples submitted for pre-employment, random employee testing, and forensic purposes. For other applications, use the standard request form.” (Note: this is for toxicology testing); “If reflex test is performed, additional charges/CPT code(s) may apply.”; “Please direct any questions regarding this test to Oncology Customer Service”; “Please include tentative diagnosis/treatment on the request form. This is necessary for proper culturing and result interpretation.” (Note: this is for chromosome analysis).Usage NoteOM1-1 – Sequence Number - Test/Observation Master FileThe OM1-1 contains a numeric value that indicates a unique set of OM1, OM2, OM3 and OM4 components; each OMn-1 in a set will have the same value as illustrated in the example below. Because the OM4 segment can repeat, but needs to have a unique number for use with OM4-17, the sequence number must be appended with a sequence number as shown in the second example below:MSH|...<cr>PID|...<cr>// start MFE Test Begin groupMFE|A|...<cr>OM1|1|...<cr>OM2|1|...<cr>OM3|1|...<cr>OM4|1|...<cr>// end MFE Test Begin group// start MFE_Test_Begin groupMFE|A|...<cr>OM1|2|...<cr>OM2|2|...<cr>OM3|2|...<cr>OM4|2.1|...<cr>OM4|2.2|...<cr>//end MFE_Test_Begin groupOM1-2 – Producer’s Service/Test/Observation IDThe OM1-2 (Producer’s Service/Test/Observation ID) contains the laboratory’s primary ID for the order code.OM1-7 – Other Service/Test/ObservationThe OM1-7 (Other Service/Test/Observation) ID(s) for the Observation XE “Other service/test/observation IDs for the observation” field contains any alternate IDs for the same order code. To identify a lab, use a unique identifier consistent with the CWE data type.; e.g., 99lab or similar. LOINC codes are identified with LN as the coding system.The field use will be:Primary Identifier for the Laboratory Order Code^Official Name Given by Receiver of Order for this Lab Test^ID SExample123456789^Glucose, Serum^99lab24338-6^ Gas panel in Blood ^LNOM1-27 – Outside Site(s) Where Observation may be PerformedIn many instances this field will be empty for a majority of tests, however; when the receiving lab receives the specimen and re-directs the testing to a referral lab, this field supports the identification of the outside site. When OM1-27 is valued, it is intended to be informative and the EHR vendor should provide this information to the ordering provider as part of the display regarding the test information. The performing lab is not finally determined until the test is directed and tested. When the test is resulted, the appropriate performing site disclosure information will be provided in the report record. Use OM1-27 (Outside Site(s) Where Observation may be Performed) when the performing location is not the same as the value in MFI-1 (Master File Identifier). This field shall identify the outside laboratory performing the service. When available, the CLIA number is recommended, however, other numbers may need to be used when CLIA is not supported or some other coding system is more approriate.Condition: If the lab providing the Directory of Service is not the performing laboratory and sends the work to an outside facility this will need to be provided.ExampleCLIA#^LabName^CLIA (Coding System)Conformance StatementseDOS-XX: If MSH-9.2 (Message Type^Trigger Event) is valued ‘M08’ then OM1-18 (Nature of Service/Test/Observation) SHALL be valued ‘A’ or ‘C’.eDOS-XX: If MSH-9.2 (Message Type^Trigger Event) is valued ‘M10’ then OM1-18 (Nature of Service/Test/Observation) SHALL be valued ‘F’, ‘S’, or ‘P’. OM2 – Numeric Observation Segment XE "numeric observation segment" xe "OM2"xe "Segments: OM2"This segment is applicable to the Test/Observation (Numeric) (Event M08) and is ‘O’ (optional) unless the eDOS_INFO_Profile is invoked, in which case it is ‘RE’ (required if known) ; see Section REF _Ref245362290 \w \h 5.1. It can be applied to the following observation batteries types (A, C) as defined in OM1-18 - Nature of Service/Test/Observation.CodeDescriptionAAtomic service/test/observation (test code).CSingle observation calculated via a rule or formula from other independent observations (e.g., Globulin or Albumin/Globulin Ratio).Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 12. OM2 – Numeric ObservationSEQElement NameDTUsageCardinalityValue Set Comment1Sequence Number - Test/Observation Master FileNMR[1..1]2Units of MeasureCWE_CRERE[0..1]99993Range of Decimal PrecisionO4Corresponding SI Units of MeasureO5SI Conversion FactorO6Reference (Normal) Range for Ordinal and Continuous ObservationsRFRRE[0..*]7Critical Range for Ordinal and Continuous ObservationsRFRRE[0..*]8Absolute Range for Ordinal and Continuous ObservationsRFRRE[0..*]9Delta Check CriteriaO10Minimum Meaningful IncrementsOUsage NoteOM2-2 – Units of MeasureThe OM2-2 (Units of Measure) value is identified by the sender of the compendium. The Units of Measure (UoM) coding system shall be identified in the third component of the CWE data type. However, UCUM is recommended.This IG strongly encourages compendium producers to use a standard coding system whenever possible. Coding systems from which the values may be drawn include UCUM, ISO+, ANSI X3.50 - 1986 and local coding systems.When processing HL7 results electronically, the OBX-6 Units value shall take precedence over the value contained in the compendium for the identified result code.Format for ExamplesUoM Value^Text^Coding SystemExamplemg/dL^milligrams per deciliter^UCUMmeq/L^milliequivalent per liter^UCUMmg/g{creat}^milligram per gram of creatinine^UCUMa^year^UCUM[lb_av]^pound^UCUMIf the UoM is specific to the sending laboratory and does not apply to an industry accepted standard, the UoM code system shall be identifed as ‘L’ or ‘99zzz’, where zzz are 3 characters as specified by HL7 Vocabulary Table 0396 to identify the (local)Name of Coding System (ID) as shown in the format example below.ExampleIV^Index Value^99LABIV^Index Value^LOM2-6 – Reference (Normal) Range for Ordinal and Continuous ObservationsThe OM2-6 (Reference (Normal) Range for Ordinal and Continuous Observations) XE "Reference (normal) range for ordinal and continuous observations" field is repeating and shall repeat for every occurrence of a normal reference range identified in the associated OM1 segment.Reference Ranges are applicable to the result code level. When processing HL7 results electronically, the OBX.7 Reference Ranges value shall take precedence over the value contained in the compendium for the identfied result code.ExampleThe Reference Interval Table below would be identfied in HL7 structure as:5.170&14.600^N^0D&3D~0.430&16.100^N^4D&30D~0.620&8.050^N^31D&12M~0.540&4.530^N^13M&5Y~0.660&4.140^N^6Y&10Y~0.530&3.590^N^11Y&19Y~0.450&4.4500^N^>19YTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 13. Reference IntervalAge(MIU/ML)0-3 d5.170-14.6004-30 d0.430-16.10031 d to 12 mo0.620-8.05013 mo to 5 y0.540-4.5306-10 y0.660-4.14011-19 y0.530-3.590>19 y0.450-4.500OM3 – Categorical Service/Test/Observation SegmentTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 14. OM3 – Categorical Service/Test/ObservationSEQElement NameDTUsageCardinalityValue SetComment1Sequence Number - Test/Observation Master FileNMR[1..1]2Preferred Coding SystemO3Valid Coded "Answers"O4Normal Text/Codes for Categorical ObservationsCWERE[0..*]9999Identifes the result(s) that are expected to be normal for that test. Example: A drug screen with an expected result of Negative. This is a repeating field and multiple normal text answers are possible.5Abnormal Text/Codes for Categorical ObservationsCWERE[0..*]9999Identifies the result(s) that are expected to be abnormal for that test. Example: A drug screen with an expected result of negative could have values as ‘Positive’ or ‘Equivocal’ for the abnormal value. This is a repeating field and multiple abnormal text answers are possible.6Critical Text/Codes for Categorical ObservationsO7Value TypeIDRE[0..1]HL70125The Data Value Type will be defined in OBX-2.OM4 – Observations That Require Specimens SegmentIf multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), multiple segments may be included, one for each specimen type.This segment will also allow for reporting Preferred and Alternate specimens, when applicable.Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 15. OM4 – Observations that Require SpecimensSEQElement NameDTUsageCardinalityValue SetComment1Sequence Number - Test/Observation Master FileNMR[1..1]2Derived SpecimenO3Container DescriptionTXRE[0..*]This field should contain the description of the container to be used for collection of the specimen. Examples: “Red-top tube~gel-barrier tube” or “Whole blood~paraffin-embedded normal tissue”.Pre-adopted revised HL7 definition and cardinality from V2.8; unlimited repeats.HL7 Definition: This field contains the physical appearance, including color of tube tops, shape, and material composition (e.g., red-top glass tube). Note that the color is not necessarily a unique identifier of the additive and/or use of the tube. This is especially true for black and some blue tube tops, as can be seen above. Color is included here for user convenience. This field repeats to accommodate all the possible specimen that will be allowed. If a container is preferred, only that container should be messaged here with the alternate containers messaged in a repeat OM4 segment.4Container VolumeNMRE[0..*]Pre-adopted revised HL7 definition and cardinality from V2.8; unlimited repeats.HL7 Definition: This field indicates the capacity of the container. This field repeats to accommodate all the possible specimens that will be allowed. If a container is preferred, only that container should be messaged here with the alternate containers messaged in a repeat OM4 segment.5Container UnitsCWERE[0..*]9999Pre-adopted CWE data type from V2.7.1; pre adopt revised HL7 definition and cardinality from V2.8; unlimited repeats.HL7 Definition: This field contains the units of measure of the container volume. If the units are ISO+ units, they should be recorded as single case abbreviations. If the units are ANS+ or L (local), the units and the source code table must be recorded, except that in this case, component delimiters should be replaced by subcomponent delimiters. For example, 1 indicates liters, whereas pt&&ANS+ indicates pints (ANSI units). The default unit is milliliters (ml), which should be assumed if no units are reported. This field repeats to accommodate all the possible specimens that will be allowed. If a container is preferred, only that container’s units should be messaged here with the alternate containers messaged in a repeat OM4 segment.6SpecimenCWE_CRERE[0..1]SNOMED CT and/or HL70487This field should identify the specimen value or code when applicable. Refer to HL7 Table 0487 – Specimen Type for valid codes, in Chapter 7, Observation Reporting, Section 7.18.Pre-adopted CWE data type from V2.7.1; pre adopt revised HL7 definition from V2.8.HL7 Definition: Describes the specimen from an appropriate controlled vocabulary. If multiple kinds of specimen are associated with this observation (as in the case for a creatinine clearance), multiple segments may be included, one for each specimen type. 7AdditiveCWERE[0..1]HL703718PreparationO9Special Handling RequirementsXExcluded for this Implementation Guide, see Section 1.3.1 Use OM4-12 instead.10Normal Collection VolumeCQRE[0..1]This field should contain the preferred volume requirements for the specimen. The normal and minimum values can be the same depending on the laboratories policies.Example: 1.0^mL&mililiter&ISO+11Minimum Collection VolumeCQRE[0..1]This field should contain the minimum volume requirements for the specimen. The test may not be performed if the minimum volume is not received. The normal and minimum values can be the same depending on the laboratories policies.Example: 0.5^mL&mililiter&ISO+12Specimen RequirementsTXRE[0..1]This field should be used to identify specimen requirements necessary for collection and delivery of the specimen. For example, ship frozen on dry ice, ship at room temp, remove plasma from cells within one hour of collection, etc.13Specimen PrioritiesO14Specimen Retention TimeO15Specimen Handling Code CWERE[0..*]HL70376Pre-adopted V2.8HL7 Definition: This describes how the specimen and/or container need to be handled from the time of collection through the initiation of testing. As this field is not required, no assumptions can be made as to meaning when this field is not populated.Refer to User-defined Table 0376 – Special Handling Code for suggested values.This field should be used to identify specimen temperature.16Specimen PreferenceIDRE[0..1]HL70920Pre-adopted V2.8HL7 Definition: This field indicates whether the Specimen/Attribues are Preferred or alternate for collection of the specimen. There can only be one occurrence of a Preferred or Alternate Specimen/Attribute for the code referenced in OM4-6 Specimen. For example, if two OM4 segments are received for specimen type of Serum, only one can be marked as Preferred. Refer to HL7 Table 0920 – Preferred Specimen/Attribute Status for suggested values.This field should be used to identify whether the specimen/attributes contained within this OM4 segment are Preferred or Alternate. If this field is null, then preference has not been indicated by the sender. Valid values are P, A or Null as referenced in the HL7 Definition. 17Preferred Specimen/Attribute Sequence IDNMRE[0..1]Pre-adopted V2.8.Usage NoteOM4-7 – Additive XE “Additive” (CWE) 00647This field should contain the description of the additive to be used for collection of the specimen. If multiple additives are referenced, then either are acceptable for the specimen attributes.HL7 Table 0371 – Additive/Preservative can be extended with site specific values.Example^With 6N HCLOrWith HCL6^With 6N HCL^HL7T0371 ~Without HCL6^Without 6N HCL^HL7T0371(Using table 0371)OM4-17 Preferred Specimen/Attribute SEQUENCE (NM) 03312HL7 Definition: This field contains the value of the sequence number of the Preferred Specimen that these specimens are the alternative. Note: For the preferred specimen (i.e., OM4-16 = ‘P’), this field is not populated. This field is used by the Alternate Specimen (i.e., OM4-16 = ‘A’) to point to the preferred specimen that it is to replace or be used as an alternative.This field will be used for Alternate Specimen/Attributes only and will refer to the Preferred Specimen/Attribute sequence number from OM4-1 for correlation between the segments.Example: Preferred specimenOM4|0001||Tiger Top|… to field16|Y||OM4|0002||Plastic Screw Top|0.5|mL|Urine|without 6N HCI| … to field16|Y||Example: Alternate specimenOM4|0003||Red Top|… to field16|A|0001|ExampleOM4 sequence 0001.1 references a Preferred Specimen of Whole Blood. The alternate specimen allowed for the test is a Paraffin-Embedded Normal Tissue. The OM4-17 for the alternate specimen will reference sequence number ‘0001.1’ as the parent preferred specimen/attribute.OM4|0001.1||Red Top|0.5|mL|^Blood|… to field16|P||OM4|0002.2||Lavender Top|||ParaffinEmbedded Tumor Tissue|| … to field16|P||OM4|0003.3||Plastic Screw Top|||ParaffinEmbedded Normal Tissue|| … to field16|A|0001.1|OM5 – Observation Batteries (Sets) Segment XE "observation batteries (sets) segment" xe "OM5"xe "Segments: OM5"Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 16. OM5 – Observation Batteries (Sets)SEQElement NameDTUsageCardinalityValue SetComment1Sequence Number - Test/Observation Master FileNMR[1..1]2Test/Observations Included Within an Ordered Test BatteryCWE_RC1R[1..*]Pre-adopted V2.7.1 CWE data type.3Observation ID SuffixesOUsage NoteOM5-2 Tests/Observations Included Within an Ordered Test Battery XE “Tests/observations included within an ordered test battery” (CWE) 00655This field repeats as many times as is necessary to provide?all components of the Order Code. The data type has the ability to message two identifiers where one could be the LOINC code and the other the local code for a given analyte. There is no instruction regarding if the Universal code (LOINC, etc.) should be first. Regardless, it is recommended that when sending two codes, there should be a consistent method for placing the codes that includes?defining the “Name of the Coding System”, i.e., OM5.2-3 (Name of Coding System)?and OM5.2-6 (Name of Alternate Coding System).Example|345A1^Glucose^99lab^456-8^Glucose Random^LN|CDM – Charge Description Master SegmentThe CDM Master Segment should only be sent for valid procedure codes. The CDM segment below is a specially designed master file segment for interfacing charge description masters. In the M04 message, the MFI-master file identifier should equal ‘CDM.’ For the Lab Test Compendium, the Charge Description Master File Message (MFN^M04^MFN_M04) must be sent after the test master updates for the Order Codes. It may also be necessary for the receiving system to update those records into their master file prior to uploading this file. This file will contain only the Order Code and the CPT codes assigned to that Order Code. It is important to note that the CPT code repeats under certain criteria, see the Usage Note in the HL7 Standard Version 2.5.1, Chapter 8, Section 8.10.2.7 CDM-7 Procedure Code. Note: The CDM does not support CPT modifiers to depict quantity (i.e., “x12”).Table STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 17. CDM – Charge Description MasterSEQElement NameDTUsageCardinalityValue SetComment1Primary Key Value – CDMCWE_RCR[1..1]HL70132Pre-adopted V2.7.1 CWE data type.Same code that is messaged in OM1-2 (Producer's Service/Test/Observation ID) and OBR-4 (Universal Service Identifier) in order and result messages.2Charge Code AliasO3Charge Description ShortSTR[1..1]This element should match CDM-2.2 (Charge Code Alias).4Charge Description LongO5Description Override IndicatorO6Exploding ChargesO7Procedure CodeCNER[1..*]Pre-adopted V2.7.1 CNE data type.Constrained to the value ‘C4’ from HL70088 Procedure Codes.Provide each instance of the CPT codes. In some cases, the CPT code will be repeated. When the CPT code is repeated, each repeat will be adjacent to each other. For display purposes, vendors can display the CPT code once with the repeat listed in (xn) or as a superscript(n) to be consistent with how displays work best in the receivers system (note: n represents the number of repeats). Refer to example following the segment for an example of the variety of ways that Lab Order Codes could be applied.8Active/Inactive FlagO9Inventory NumberO10Resource LoadO11Contract NumberO12Contract OrganizationO13Room Fee IndicatorOUsage NoteThe CDM-7 (Procedure Code) field has pre-adopted and constrained Table 0088 from V2.8.Coding ExamplesTable STYLEREF 1 \s 5 SEQ Table \* ARABIC \s 1 18. Example CPT Test CodesTestCPT Code(s)CBC (includes Differential and Platelets)85025CBC (includes Differential and Platelets with Pathologist review85025, 85060CAH Panel 8 (17-Hydroxylase Deficiency in Males)82088,82528,82533,83498,84144,84403Legionella Ab Evaluation, Comprehensive (A&G)86713 (x2)Lupus (SLE) Panel83516 (x3), 86038, 86160 (x2), 86235 (x5), 86255 (x5), 86376, 86431Legionella Ab Evaluation Comprehensive Panel|86713^ ANTIBODY; LEGIONELLA ^C5C4~86713^ ANTIBODY; LEGIONELLA ^C5C4|Lupus Panel|83516^IMMUNOASSAY FOR ANALYTE OTHER THAN INFECTIOUS AGENT ANTIBODY OR INFECTIOUS AGENT ANTIGEN; QUALITATIVE OR SEMIQUANTITATIVE, MULTIPLE STEP METHOD^C5C4~83516^IMMUNOASSAY FOR ANALYTE OTHER THAN INFECTIOUS AGENT ANTIBODY OR INFECTIOUS AGENT ANTIGEN; QUALITATIVE OR SEMIQUANTITATIVE, MULTIPLE STEP METHOD^C5C4~83516^IMMUNOASSAY FOR ANALYTE OTHER THAN INFECTIOUS AGENT ANTIBODY OR INFECTIOUS AGENT ANTIGEN; QUALITATIVE OR SEMIQUANTITATIVE, MULTIPLE STEP METHOD^C5C4~86038^ANTINUCLEAR ANTIBODIES (ANA)^C5C4~86160^COMPLEMENT; ANTIGEN, EACH COMPONENT^C5C4~86160^COMPLEMENT; ANTIGEN, EACH COMPONENT^C5C4~86235^EXTRACTABLE NUCLEAR ANTIGEN, ANTIBODY TO, ANY METHOD (EG, NRNP, SS-A, SS-B, SM, RNP, SC170, J01), EACH ANTIBODY^C5C4~86235^^C5C4~86235^EXTRACTABLE NUCLEAR ANTIGEN, ANTIBODY TO, ANY METHOD (EG, NRNP, SS-A, SS-B, SM, RNP, SC170, J01), EACH ANTIBODY^C5C4~86235^EXTRACTABLE NUCLEAR ANTIGEN, ANTIBODY TO, ANY METHOD (EG, NRNP, SS-A, SS-B, SM, RNP, SC170, J01), EACH ANTIBODY^C5C4~86235^EXTRACTABLE NUCLEAR ANTIGEN, ANTIBODY TO, ANY METHOD (EG, NRNP, SS-A, SS-B, SM, RNP, SC170, J01), EACH ANTIBODY^C5C4~86255^FLUORESCENT NONINFECTIOUS AGENT ANTIBODY; SCREEN, EACH ANTIBODY^C5C4~86255^FLUORESCENT NONINFECTIOUS AGENT ANTIBODY; SCREEN, EACH ANTIBODY^C5C4~86255^FLUORESCENT NONINFECTIOUS AGENT ANTIBODY; SCREEN, EACH ANTIBODY^C5C4~86255^FLUORESCENT NONINFECTIOUS AGENT ANTIBODY; SCREEN, EACH ANTIBODY^C5C4~86255^FLUORESCENT NONINFECTIOUS AGENT ANTIBODY; SCREEN, EACH ANTIBODY^C5C4~86376^MICROSOMAL ANTIBODIES (EG, THYROID OR LIVER-KIDNEY), EACH^C5C4~86431^RHEUMATOID FACTOR; QUANTITATIVE^C5C4|Code Systems and Value SetsSuccessful message implementation requires that transmitted messages (message instances) contain valid values for coded fields. It is important to note that code sets are relatively dynamic and subject to change between publications of these implementation guides.Every code value passed in a message instance is drawn from a code system that either may have a globally unique identifier, such as an OID, an HL7 identifier (Table 0396), or a locally defined identifier. In general, the coded values allowed in a field (a) may be drawn from more than one code system, and (b) may be a subset of the codes from a given coding system. Combining (a) and (b) makes it possible for the allowed code value to be a combination of multiple subsets drawn from multiple coding systems. In most cases, only subsets of the codes defined in a code system are legal for use in a particular message.The subsets of the codes that are allowed for a particular field is identified by an HL7 construct known as a "value set." A value set is a collection of coded values drawn from code systems. Value sets serve to identify the specific set of coded values for the message from the universe of coded values across all coding systems.The segment tables in previous sections identify the value set or coding system used for each supported field containing a coded value. Some of these pre-coordinated value sets must be updated, or new ones created, as new needs are identified.A unique identifier identifies value sets, but this identifier is not transmitted in the message. The identifier or code for the coding system from which the value is derived is sent in the message. However, the value set identifier is useful and important when vocabulary items are modified or replaced.LOINCThe laboratory’s local test code and coding system shall be used to identify the orderable test in its electronic Directory of Services. LOINC shall be used as the standard alternate vocabulary to identify an orderable test. The performing laboratory makes the determination of an applicable LOINC order code. When no applicable LOINC code exists, the local code may be the only code defined in the eDOS.LOINC Codes may be used for both orders and observations and are applicable in the following fields:OM1-2 - Producer's Service/Test/Observation IDOM1-7 - Other Service/Test/Observation IDs for the ObservationOM1-31 - Observations Required to Interpret the Observation (Ask at Order Entry)OM5-2 - Tests/Observations Included Within an Ordered Test For further information on LOINC and access to tools, please visit CTSNOMED CT is a recommended vocabulary as specified in this guide, e.g., for specimen source terms in OM4-6 (Specimen) when a SNOMED CT code is available. Note that in some instances a code must be drawn from a declared hierarchy in SNOMED CT, e.g., OM4-6 (Specimen) terms should be drawn from the “specimen hierarchy”; see the field comments wherever SNOMED CT is identified as the value set.SNOMED CT may be used in the following fields:OM3-4 – Normal Text/Codes for Categorical ObservationsOM3-5 – Abnormal Text/Codes for Categorical ObservationsFor fields where 9999 is the specified value set, SNOMED CT may be used when agreed upon by trading partners. Support for SNOMED CT shall include the code and the description text as described by IHTSDO, following CWE requirements as defined in Section 4.3.Further information on SNOMED CT can be found at the National Library of Medicine ().Unconstrained Code SystemsThis section provides a list of unconstrained code systems and value sets used in this IG; refer to the base standard for all values. It also provides information about the source of the vocabulary and an identifier for the vocabulary. The name found in the Value Set/Code System Name column corresponds with the value set identified in the Value Set column of the data type and segment attribute tables found above.Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 1. Unconstrained Code System SummaryNameValue SetSourceCommentsAdministrative SexHL70001HL7 Version 2.5.1Race CategoryHL70005HL7 Version 2.5.1Acknowledgment CodeHL70008HL7 Version 2.5.1Diagnostic Service Section IDHL70074HL7 Version 2.5.1Processing IDHL70103HL7 Version 2.5.1HL70125HL7 Version 2.5.1Nature of Service/Test/ObservationHL70174HL7 Version 2.5.1Master file identifier codeHL70175HL7 Version 2.5.1Refer to HL7 V2.5.1 Appendix A.File Level Event CodeHL70178HL7 Version 2.7.1Response LevelHL70179HL7 Version 2.5.1Address TypeHL70190HL7 Version 2.5.1.HL70357 HL7 Version 2.5.1ApplicationHL70361HL7 Version 2.5.1HL70362HL7 Version 2.5.1HL70371HL7 Version 2.5.1Special Handling CodeHL70376HL7 Version 2.5.1HL70920 (used in OM4-16)Coding SystemsHL70396HL7 Version 2.5.1HL7 Table 0396 defines the standard coding systems recognized by HL7. The table defines a mechanism by which locally defined codes can be transmitted. Any code/coding system not defined in HL7 Table 0396 is considered a “local” coding system from the HL7 perspective. Coding systems that are identified in this implementation guide will be identified according to the recommended HL7 nomenclature from table 0396 as “99-zzz” where “zzz” represents a string identifying the specific non-standard coding system. HL7 now maintains HL7 table 0396 “real time”. This means that values may be added to the table at any time so that implementers can have an up-to-date source of truth for the codes to be used to identify coding systems in any 2.x message. CodeHL70399HL7 Version 2.5.1Externally or Locally defined9999If the field is of data type CE, CF, CNE or CWE and one or more externally or locally defined tables may be used, the symbolic number 9999 will appear in the column. This is to indicate that table values are used, but no HL7/User-defined table can be allocated. The narrative may constrain which external tables can be used. Specimen TypeSNOMED CT and/or HL70487HL7 Version 2.5.1Error severityHL70516HL7 Version 2.5.1LOINCLOINCLOINCLogical Observation Identifiers Names and Codes. Value SetUSPSUSPS Identifies addresses within the United States are recorded using the USPS two-letter alphabetic codes for the State, District of Columbia, or an outlying area of the United States or associated area. See HL7 Tables – Value SetsThis section provides a list of the constrained code systems and value sets used in this IG. It also provides information about the source of the vocabulary and an identifier for the vocabulary. The name found in the Value Set/Code System Name column corresponds with the value set identified in the Value Set column of the data type and segment attribute tables found above.The OIDS that are assigned to value sets are not to be used in components -3 (Name of Coding System) or -6 (Name of Alternate Coding System) of CWE_xxx Data Types.Testing tools, etc., can use these OIDS, but not in those components.Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 2. Constrained Code System SummaryNameValue SetSourceCommentsEvent TypeHL70003HL7 Version 2.5.1Message TypeHL70076HL7 Version 2.5.1Value TypeHL70125HL7 Version 2.5.1Record-Level Event CodeHL70180HL7 Version 2.5.1Universal ID typeHL70301HL7 Version 2.7.1Message structureHL70354HL7 Version 2.5.1Exclusive TestHL70919HL7 Version 2.8Preferred Specimen/Attribute StatusHL70920HL7 Version 2.8HL7 Table 0003 – Event TypeTable STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 3. HL7 Table 0003 – Event Type CodeValueDescriptionCommentM04MFN/MFK - Master files charge descriptionM08MFN/MFK - Test/observation (numeric) master fileM10MFN/MFK - Test /observation batteries master fileHL7 Table 0076 – Message Type Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 4. HL7 Table 0076 – Message TypeValueDescriptionCommentMFNMaster File Notification messageACKGeneral acknowledgment messageHL7 Table 0125 – Value Type (V2.5.1)Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 5. HL7 Table 0125 – Value Type (V2.5.1)ValueDescriptionUsageData Type FlavorCommentCECoded EntryRWhen sending text data in OBX-5, use either the ST, TX or FT data types.CWECoded with ExceptionsRCWE_CROData type to be used where it is important to communicate the coding system and coding system version with the coded result being reported. Pre-adopted from Version 2.6.This Implementation Guide has specially constrained versions of the CWE data type in Section REF _Ref245787506 \w \h 4.2 REF _Ref245787527 \h CWE – Coded with Exceptions. The CWE_CR format shall be used for OBX-5. When sending text data in OBX-5, use either the ST, TX or FT data types.CXExtended Composite ID With Check DigitOVariesUse the appropriate CX flavor (CX-GU or CX-NG or base standard) depending on the format of the observation value and as agreed to between the sender/receiver.DTDateREDEncapsulated DataOWhen using the Source Application ID component it should use the HD data type formatting considerations outlined in the base standard, not the constrained HD definitions in this IG. FTFormatted Text (Display)RField using the FT data type to carry a text result value. This is intended for display. The text may contain formatting escape sequences as described in the data types section. Numeric results and numeric results with units of measure should not be reported as text. These should be reported as NM or SN numeric results, with the units of measure in OBX-6.NMNumericRField using the NM data type to carry a numeric result value. The only non-numeric characters allowed in this field are a leading plus (+) or minus (-) sign. The structured numeric (SN) data type should be used for conveying inequalities, ranges, ratios, etc. The units for the numeric value should be reported in OBX-6.RPReference PointerOWhen using the Application ID component it should use the HD data type formatting considerations outlined in the base standard, not the constrained HD definitions in this IG.SNStructured NumericRField using the SN data type to carry a structured numeric result value. Structured numeric include intervals (^0^-^1), ratios (^1^/^2 or ^1^:^2), inequalities (<^10), or categorical results (^2^+). The units for the structured numeric value should be reported in OBX-6.STString DataRField using the ST data type to carry a short text result value. Numeric results and numeric results with units of measure should not be reported as text. These shall be reported as NM or SN numeric results, with the units of measure in OBX-6.TMTimeRThe timezone offset shall adhere to the use of the TimeZone Offset profile.TSTime Stamp (Date & Time)RTS_0The timezone offset shall adhere to the use of the TimeZone Offset profile and associated discussion if the granularity involves ‘hh’ or ‘more’.TXText Data (Display)RField using the TX data type to carry a text result value this is intended for display. Numeric results and numeric results with units of measure should not be reported as text. These should be reported as NM or SN numeric results, with the units of measure in OBX-6.HL7 Table 0180 – Record-Level Event CodeTable STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 6. HL7 0180 – Record-Level Event CodeValueDescriptionCommentMADAdd record to master fileMUPUpdate record for master fileMDCDeactivate: discontinue using record in master file, but do not delete from databaseMACReactivate deactivated recordHL7 Table 0301 – Universal ID Type (V2.7.1)Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 7. HL7 Table 0301 – Universal ID Type (V2.7.1)ValueDescriptionUsageCommentsCLIAClinical Laboratory Improvement Amendments. Allows for the ability to designate organization identifier as a CLIA assigned number (for labs)REDNSAn Internet dotted name. Either in ASCII or as integers C(X/O)Condition Predicate: If Component GU is used on the field using this value set.GUIDSame as UUID.C(X/O)Condition Predicate: If Component GU is used on the field using this value set.CENThe CEN Healthcare Coding Scheme Designator. (Identifiers used in DICOM follow this assignment scheme.)C(X/O)Condition Predicate: If Component GU is used on the field using this value set.HL7Reserved for future HL7 registration schemesC(X/O)Condition Predicate: If Component GU is used on the field using this value set.ISOAn International Standards Organization Object IdentifierRUsed as the Universal ID Type in the CNN, EI and HD data types.L,M,NThese are reserved for locally defined coding schemes.C(X/O)Condition Predicate: If Component GU is used on the field using this value set.RandomUsually a base64 encoded string of random bits.The uniqueness depends on the length of the bits. Mail systems often generate ASCII string _unique names from a combination of random bits and system names. Obviously, such identifiers will not be constrained to the base64 character set.C(X/O)Condition Predicate: If Component GU is used on the field using this value set.URIUniform Resource IdentifierRUsed as the Universal ID Type in the RP data type.UUIDThe DCE Universal Unique IdentifierC(X/O)Condition Predicate: If Component GU is used on the field using this value set.x400An X.400 MSH format identifierC(X/O)Condition Predicate: If Component GU is used on the field using this value set.x500An X.500 directory nameC(X/O)Condition Predicate: If Component GU is used on the field using this value set.HL7 Table 0354 – Message StructureTable STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 8. HL7 Table 0354 – Message StructureValueDescriptionUsageCommentsMFN_M04Charge Description Master File MessageRMFN_M08Master File Notification – Test/Observation (Numeric)RMFN_M10Master File Notification – Test/Observation BatteriesRMFK_M01Master File AcknowledgmentRHL7 Table 0919 – Exclusive Test (V2.8)HL7 Definition: This field defines if this test should be the a specific event with no other tests to be performed with this test. Refer to HL7 Table 0919 – Exclusive Test for valid values.If not populated, the default value of ‘N’ is assumed and that this test can be included with any number of other tests.When ‘D’ is specified for this field, using field OM1-49 determines how tests must be grouped together. Tests within the same Diagnostic Service Sector maybe on the same requisition, and therefore in the same message.Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 9. HL7 Table 0919 – Exclusive Test (v2.8)ValueDescriptionCommentYThis test should be exclusiveNThis test can be included with any number of other testsDefault – will be assumed when this field is empty.DIn some cases, this test should be only exclusively with like tests (examples are cyto or pathology)When ‘D’ is specified for this field, using field OM1-49 determines how tests must be grouped together. Tests within the same Diagnostic Service Sector maybe on the same requisition, and therefore in the same messageUsage NoteThis is conditional, used in conjunction with OM1-16 (Observation Producing Department/Section) to determine if this test must be presented on its own printed requisition. Tests of this nature are often stored and/or processed separately for a combination of Clinical, Storage or Laboratory Workflow reasons.HL7 Table 0919 – Exclusive Test Impact on OM1-49 Diagnostic Serv Sect IDTable STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 10. HL7 Table 0919 – Impact on OM1-49OM1-48OM1-49ExpectationNullIgnoreTest can be on requisition with any other tests.NIgnoreSame as if the field was Null or empty.YIgnoreThe test must be exclusively on a requisition by itself. Example: Tests that require chain of custody to be complaint with SAMSHA but be on a requisition by itself because of the special handling required for those tests.DMatchThe tests that have a D in OM1-48 can be on the same requisition as those that have a matching Diagnostic Serv Sect ID in OM1-49. HL7 Table 0920 – Preferred Specimen/Attribute Status (V2.8)Table STYLEREF 1 \s 6 SEQ Table \* ARABIC \s 1 11.HL7 Table 0920 – Preferred Specimen/Attribute Status (V2.8)ValueDescriptionCommentPPreferredThis specimen is Preferred for all attributes (Container and Additive) identified in the OM4 segment.AAlternateThis is a specimen that is acceptable as a replacement for a preferred specimen. In the following field (OM4-17), the sequence number of the preferred specimen must be messaged.Appendix A – Ask at Order EntryThe initial text below is excerpted from HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 – US Realm, Section 2.6.6 Ask at Order Entry (AOE) Observations, to explain how Ask at Order Entry questions are “answered” in a laboratory order.---------- start citation---------2.6.6 Ask at Order Entry (AOE) ObservationsAsk at Order Entry (AOE) responses are recorded as observations that provide critical information for the calculation or interpretation of some lab results or to satisfy state and federal health agency mandated information gathering requirements, e.g., for blood lead testing. Not every order will have the need for AOE questions and associated observations.Examples of the type of information gathered from a patient include employment information, pregnancy status, the date of the last menstrual period, mother’s age, and questions about family and personal history. In some cases there may be AOEs that request the outcome of previous results phrased as a question, e.g., “Was your previous pap abnormal?”AOE responses can take several formats, including but not limited to:Yes/No (and coded) to answer questions like “Is this your first pregnancy?”A code drawn from a value set to provide a coded response to, e.g., “What ethnicity do you consider yourself to be?”A number with units for the mother’s ageA date format for the patient’s last menstrual period.The OBX segments under the ORC/OBR pair must be used in the order messages to convey these Ask at Order Entry questions.Although not strictly asked at order entry, other supporting clinical information about the patient collected during specimen collection, e.g., fasting status of the patient, are considered AOE observations for purposes of this guide and must be communicated using the OBX segment under the ORC/OBR segments as well.The lab will indicate if and which AOEs to include with the order in their test compendium, either using paper or electronically via the “Implementation Guide: ACLA Test Compendium Framework (eDOS), Release 1, January 11, 2011”. The eDOS implementation guide uses the OM1-31 (Observations Required to Interpret this Observation) to indicate which Ask at Order Entry questions to use upon ordering the test and specimen collection. Note that each instance in the OM1-31 (Observations Required to Interpret this Observation) represents a single AOE question.LOINC shall be used as the standard coding system for AOE questions if an appropriate and valid LOINC code exists. The LOINC and local code describing the question will be placed in OBX-3 (Observation Identifier). Appropriate and valid status is defined in the LOINC Manual Section 11.2 Classification of LOINC Term Status. If a local coding system is in use, both the LOINC and the local code should also be sent to help with identification of coding issues. When no valid LOINC exists, the local code may be the only code sent.2.6.6.1 Special ConsiderationsNote that various Ask at Order Entry questions may appear to have specific fields in PID, NK1, or other segments. When a value is asked through an Ask at Order Entry question it must be conveyed through the OBX segments as described above as these values are used for clinical interpretations rather than through a seemingly similar field in PID, NK1, or other segment. The following provide specific examples and guidance whether to use an existing field or the OBX segment. This is list is not meant to be exhaustive.Date of Birth - Always use PID-7 (Date/Time of Birth) and should never be asked as an AOE as there is only one at any point in time.Race - PID-10 (Race) is provided for demographic (administrative/billing), not clinical use. The lab must provide an AOE for those tests where Race drives the interpretation of results. The value must be determined by the Ordering Provider and must be sent as an AOE OBX. Note that state and/or national regulations may dictate other behaviors.Ethnicity – PID-22 (Ethnic Group) is provided for demographic (administrative/billing), not clinical use. The lab must provide an AOE where Ethnicity drives the interpretation of results. The value must be determined by the Ordering Provider and must be sent as an AOE OBX. Note that state and/or national regulations may dictate other behaviors.Note: More specific PID-10 (Race) and PID-22 (Ethnicity) values are available, but not limited to, those found in the CDCREC document ().---------- end citation---------Example AOE for Employer AddressThe example below illustrates how an AOE messaged in OM1-31 Observations Required to Interpret This Observation is “answered” in a laboratory order:AOE Question in eDOS (electronic Directory of Service) message63758-7^What was the location of this company^LN ^345^Employer Address^99lab|AOE Answer in LOI IG (Laboratory Orders Interface Implementation Guide) messageOBX|1|XAD|63758-7^What was the location of this company^LN^345^Employer Address^99lab||1000 Hospital Lane^Suite 123^Ann Arbor ^MI^99999^USA^B^^WA|||||||||201210310800|Example AOE for Race using CDC Race and Ethnicity Code Set (CDCREC)The example below illustrates how an AOE messaged in OM1-31 Observations Required to Interpret This Observation is “answered” in a laboratory order. This example uses the expanded terminology available in CDC's Race and Ethnicity Code Set (CDCREC):AOE Question in eDOS (electronic Directory of Service) message32624-9^Race^LNAOE Answer in LOI IG (Laboratory Orders Interface Implementation Guide) messageOBX|1|CWE|32624-9^Race^LN||1010-8^APACHE^CDCREC|||||||||201210310800|Proposed AOEs with a LOINC CodeIn the eDOS Implementation Guide, ask at order entry questions are associated with an orderable test using OM1-31 (Observations Required to Interpret this Observation). OM1-31 lists all observations that must be captured at the time the order is created. Multiple AOE questions are allowed for an individual orderable test; each instance in the OM1-31 represents a single AOE question.Because Meaningful Use has supported “Structured Data” for lab results, beginning with Meaningful Use Stage 1, the AOE examples below suggest HL7 data types to be used when the EHR system returns the “answer” to the lab’s compendium test question. For example, the XAD (Extended Address), data type is suggested when reporting the employer address “answer” for blood lead test question about employer address.The LOINC encoded AOE examples in the table below are provided as guidance and focus on the most commonly used Ask at Order Entry questions. This is not an exhaustive list and does not attempt to include all possible AOEs. Implementers can incorporate additional AOEs as needed for their specific environment.LOINC codes may change in newer versions of the data base so it is suggested you verify that the LOINC codes are valid before using. Some LOINC codes in the list below were “Trial” codes at the time of publication and are designated with an ‘*’ following the LOINC code. As defined on the LOINC website “Trial terms are experimental in nature. Use with caution as they may change.”A direct hyperlink to each LOINC code is provided in the table below. You will need to “Accept” the Copyright Notice and License to enable the hyperlinks. Additional information, including related names, is available on the LOINC website.For numeric data types (e.g. age) Unified Code for Units of Measure (UCUM) is recommended but not required. If used, be sure to populate OBX-6 Units (e.g. years, months, days). Further information on UCUM can be found at data types below are suggested but not required; other data types may be used where applicable. LOINC codes may dictate additional structure for the AOE, please refer to LOINC for additional information. We encourage implementers to use the HL7 defined message structure to communicate AOE information where possible.Recommended value sets for the answers are included in the Usage Notes. Other value sets may be used as agreed upon by trading partners.Table STYLEREF 1 \s 7 SEQ Table \* ARABIC \s 1 1. Example LOINC AOE QuestionsLOINCCodeLOINC Long NameAlias NameSuggested HL7 Data Type OBX responseUsage Note49089-6[Identifier] SonographerSonographer IDST63746-2About how long have you worked for your employer in your occupationNMBe sure to populate the units in OBX-6.30525-0AgeNMBe sure to populate the units in OBX-6.63888-2 *Age at first menstrual periodNMBe sure to populate the units in OBX-6.42797-1Age at first pregnancyNMBe sure to populate the units in OBX-6. 63890-8 *Age at last menstrual periodNMBe sure to populate the units in OBX-6.35659-2Age at specimen collectionNMBe sure to populate the units in OBX-6.71471-7 *Antibiotic administered Medication CWEIf using CWE RxNorm or other code system may be used, or you may use the CWE.9 (Original Text) component of the CWE data type.8302-2Body Height (Methodless)Patient Height (inches)NMBe sure to populate the units in OBX-6.3137-7Body height MeasuredNMBe sure to populate the units in OBX-6.3138-5Body height StatedNMBe sure to populate the units in OBX-6.29463-7Body weightNMMethodlessBe sure to populate the units in OBX-6.3141-9Body weight (measured)Patient weight (measured)NMBe sure to populate the units in OBX-6.3142-7Body weight (stated)Patient weight (stated)NMBe sure to populate the units in OBX-6.8344-4Body weight Measured --post dialysisBody weight^post dialysisNMFor Kt/v – DialysisBe sure to populate the units in OBX-6.8347-7Body weight Measured --pre dialysisBody weight^pre dialysisNMFor Kt/v – DialysisBe sure to populate the units in OBX-6.69461-2 *Body weight mother -- at deliveryNMBe sure to populate the units in OBX-6. 55752-0Clinical informationPrevious cytologyST66477-1 *Country of current residence PhenXCWEISO-3166 Country CodeInternational Organization for Standardization (ISO)11294-6Current employment Narrative - reportedCurrent employmentTX64234-8Current smokerCWERefer to LOINC for suggested answer list.30952-6Date and time of vaccinationDT63936-9 *Date of start of treatment or therapy PhenXDT29742-4Date last doseDT8665-2Date last menstrual periodDT60431-4Date of previous biopsyDT60432-2Date of previous PAP smearDT11778-8Delivery date EstimatedEstimated due dateDT33248-6Diabetes statusCWEY/N (HL7 Table 0136)This guide recommends CWE in case additional diabetic statuses are indicated, for example, “Suspected”.8462-4Diastolic blood pressureCWE53948-6Donated egg [Presence]Donor eggCNEY/N (HL7 Table 0136)42784-9Ethnic background StatedCWEPID-22 (Ethnic Group) value is provided for demographic, not clinical use. An AOE must be provided for those tests where Ethnic Group drives the interpretation of results. The value must be determined by the Ordering Provider and must be sent as an AOE OBX.More specific ethnicity values are available, but not limited to, those found in the CDCREC document if needed for AOE. ()69490-1Ethnicity OMB 1997EthnicityCWERefer to LOINC for suggested answer list.49541-6Fasting status [Presence] - reportedFasting statusCWEY/N (HL7 Table 0136)If extending HL7 Table 0136, additional values may be found in HL7 Table 0532 - Expanded Yes/no Indicator.11951-1Fetal [Identifier] IdentifierFetus IDST11957-8Fetal Crown Rump length USFetal Crown Rump lengthNM‘US’ is UltrasoundBe sure to populate the units in OBX-6.42479-6Fetal Narrative Study observation general, multiple fetuses USST12146-7Fetal Nuchal fold thickness USNuchal translucencyNM‘US’ is UltrasoundBe sure to populate the units in OBX-6.63741-3For whom did you work at your main job or businessXONEmployer Name – Organization example.63741-3 *For whom did you work at your main job or businessXPNEmployer Name - Person example.46098-0GenderCWERefer to LOINC for suggested answer list.Answer list may be extended by agreement of trading partners to support other clinical genders.11884-4Gestational age EstimatedSNBe sure to populate the units in OBX-6.49052-4Gestational age in daysGestational age (days)NMBe sure to populate the units in OBX-6.49051-6Gestational age in weeksGestational age (weeks)NMBe sure to populate the units in OBX-6.21299-3Gestational age methodGestational age calculation methodSTExample response may include:US, LMP, Estimated date of delivery8867-4Heart rateNMBe sure to populate the units in OBX-6.58957-2Heparin given [Type]ST8670-2History of family member diseasesHistory of Cystic FibrosisCWERefer to LOINC for suggested answer list.53827-2History of neural tube defect QualitativeHistory of ONTDCNEY/N (HL7 Table 0136)67803-7History of Procedures - ReportedPrevious treatmentST8691-8History of TravelCWEISO-3166 for Countries or United States Postal Service (USPS) for States.11368-8Illness or injury onset date and timeDT44877-9Insulin dependent diabetes mellitus [Presence]Insulin dependent DMCWEY/N (HL7 Table 0136)53796-9Interferon drug given [Identifier]ST3145-0Last menstrual period startDT29303-5Medication administeredCWEIf using CWE RxNorm or other code system, you may use the CWE.9 (Original Text) component of the CWE data type.29305-0Medication prescribedCWE54125-0NamePartner NameXPN11878-6Number of Fetuses by USNumber of FetusesNM‘US’ is UltrasoundBe sure to populate the units in OBX-6.67471-3 *PregnancyCWERefer to LOINC for suggested answer list.11449-6Pregnancy status – ReportedCWEY/N/No Information (HL7 Table 0532 - Expanded Yes/no Indicator).18771-6Provider signing nameReading physician IDXPN32624-9RaceCWEPID-10 (Race) value is provided for demographic, not clinical use. An AOE must be provided for those tests where Race drives the interpretation of results. The value must be determined by the Ordering Provider and must be sent as an AOE OBX. Refer to LOINC for suggested answer list.More specific race values are available, but not limited to, those found in the CDCREC document if needed for AOE. ().49088-8Sonographer nameXPN8480-6Systolic blood pressureCWE72166-2Tobacco Smoking StatusCWERefer to LOINC for suggested answer list.34970-4Ultrasound DateDT13620-0Volume of 12 hour UrineSpecimen VolumeNMBe sure to populate the units in OBX-6.Can also be calculated (if available) from:SPM-4 (Specimen Type) (CWE_CRE);SPM-12 (Specimen Collection Amount);Or messaged in OBR-9 (Collection Volume)3167-4Volume of 24 hour UrineSpecimen VolumeNMBe sure to populate the units in OBX-6.Can also be calculated (if available) from:SPM-4 (Specimen Type) (CWE_CRE);SPM-12 (Specimen Collection Amount);Or messaged in OBR-9 (Collection Volume).8280-0?Waist Circumference at umbilicus by Tape measureNMWaist Circumference, inches.Be sure to populate the units in OBX-6.63758-7 *What was the location of this company [Address]XADEmployer AddressProposed AOEs without a LOINC CodeThe common AOE questions below are examples encountered, that are being submitted for LOINC code requests to Regenstrief and should be available in the future. The table provides these suggested terms, data type and Usage Note - all may be modified through this process. If attempting to use any of these concepts, proceed with caution and refer to LOINC to determine if a code has been assigned before using a local code.Table STYLEREF 1 \s 7 SEQ Table \* ARABIC \s 1 2. Example AOE Questions (Without LOINC Code)aAOE QuestionSuggested HL7 Data Type OBX responseUsage NoteAnimal Exposed to RabiesCWEThis is related to rabies testing.Y/N (HL7 Table 0136)This guide recommends CWE in case additional codes are indicated, for example “Unknown”.Animal speciesCWEIdentifies the species name; SNOMED Organism Hierarchy may be used for the answer list.Any history of exposure to infectious disease?CWEY/N/UNK (HL7 Table 0532 - Expanded Yes/No Indicator)This is typically asked in conjunction with “Type of Exposure”.Biparietal DiameterNMBe sure to populate the units in OBX-6.Blood lead purposeCWERefer to LOINC for suggested answer list.Blood lead sourceCWERequired for State reporting; should also be reported in SPM-4 (Specimen Type) (CWE_CRE).Date of animal’s deathDTThis is related to rabies testing.Date of treatment endDTDurationNMTreatment time for dialysis.Be sure to populate the units in OBX-6.Egg Provider's RaceCWEMore specific race values are available, but not limited to, those found in the CDCREC document if needed for AOE. ()Hip circumference, centimetersNM Be sure to populate the units in OBX-6.Hip circumference, inchesNM Be sure to populate the units in OBX-6.History of exposure to animalCWEY/N/UNK (HL7 Table 0532 - Expanded Yes/no Indicator)If the egg was frozen or not from the patient, what was the age of the egg at the time of egg retrieval?NMBe sure to populate the units in OBX-6.Insulin Dependent Diabetic Egg ProviderCWEY/N/UNK (HL7 Table 0532 - Expanded Yes/no Indicator)Is this your first pregnancy (Y/N)CNE(Y/N) HL7 Table 0136 Partner EthnicityCWEMore specific ethnicity values are available, but not limited to, those found in the CDCREC document if needed for AOE. ()Travel date rangeDRViral loadNMBe sure to populate the units in OBX-6.Specimen ListThis AOE information is provided to indicate how to map former AOEs to the Specimen (SPM) segment. This IG recommends using the SPM segment instead of AOEs for the following items. If you are implementing the HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Orders from EHR, Release 1 – US Realm (LOI) or HL7 Version 2.5.1 Implementation Guide: S&I Framework Laboratory Results Interface (LRI), Release 1, published July for Meaningful Use in the US Realm, the SPM segment is required in the Lab Order and Lab Result messages.Table STYLEREF 1 \s 7 SEQ Table \* ARABIC \s 1 3. Example Specimen LOINC AOE QuestionsLOINCCodeLOINC Long NameAlias NameSuggestedHL7 DataType OBX responseUsage Note14725-6[Type] of Body fluidSPM-4 (Specimen Type) (CWE_CRE)13363-7Collection duration of StoolCan be calculated from:SPM-4 (Specimen Type) (CWE_CRE)SPM-17 (Specimen Collection Date/Time) (DR_1)13362-9Collection duration of UrineCan be calculated from:SPM-4 (Specimen Type) (CWE_CRE)SPM-17 (Specimen Collection Date/Time) (DR_1) 49049-0Collection time of Unspecified SpecimenSPM-17 (Specimen Collection Date/Time)(DR_1.1 [Range Start Date/Time])48557-3Origin of StoneSPM-8 (Specimen Source Site)CWE_CRE19151-0Specimen drawn [Date and time] of Serum or PlasmaSPM-17 (Specimen Collection Date/Time) (DR_1.1 [Range Start Date/Time])19763-2Specimen source [Identifier] in Cervical or vaginal smear or scraping by Cyto stainGynecological SourceSPM-8 (Specimen Source Site) (CWE_CRE)31208-2Specimen source [Identifier] of Unspecified specimenSPM-4 (Specimen Type) (CWE_CRE)Common AOEs Which Should be Messaged Elsewhere in HL7In the process of developing this implementation guide, participants submitted candidate AOE terms for inclusion. Several proposed AOEs submitted should be messaged elsewhere in the HL7 message. This IG recommends using the HL7 segment/field as documented in the Usage Note, instead of messaging as an AOE. The table below is informative guidance to indicate how to map commonly used AOEs to the specified HL7 segment. If the appropriate HL7 field is optional, trading partners should change the usage of the ‘O’ fields to 'RE', if the information is required for processing.Prior laboratory results needed for testing or interpretation should be messaged in the Prior Results segment group of the lab order message, versus messaging as an AOE; refer to OM1-53 (Prior Resuts Instructions) for additional information.Table STYLEREF 1 \s 7 SEQ Table \* ARABIC \s 1 4. Common AOEs which should be messaged elsewhere in HL7LOINCCodeLOINC Long NameAlias NameSuggested HL7 Data Type OBX ResponseUsage Note56799-0Address^PatientPID-11 (Patient Address) (XAD).21112-8Birth datePatient Date/Time of Birth in PID-7 (Data Type format varies based on profile, refer to LOI IG).N/ACall or Fax Results BackOBR-49 (Result Handling) where HL70507 Observation Result Handling table Code = N (Notify provider when ready). (IS).29308-4DiagnosisDG1-3 (Diagnosis Code) (CWE_CR).56794-1Internal identifierPID-3 (Patient Identifier List) where HL70203 Identifier type table code = PI (Patient internal identifier) (Data Type format varies based on profile, refer to LOI IG).22020-2Maiden namePatient Maiden Name can be sent in PID-5 (XPN);Mother’s Maiden Name in PID-6.21484-1Mother's raceNK1-35 (Race), if NK1-3 (Relationship) (CWE_CR) = ‘MTH’ (Mother).18780-7Ordering Practitioner IDOBR-16 (Ordering Provider) component 1(ID Number) (ST).44951-2Physician NPI [Identifier]LOINC Term Definition: The NPI (National Provider Identifier) code for another physician involved in the care of the patient. The NPI equivalent of Physician 3 [2490].PRT (Participation Information Segment).PRT-5 (Participation Person) (XCN, data type format varies based on profile, refer to LOI IG).44833-2Preliminary diagnosisDG1-3 (Diagnosis Code) (CWE_CR).45396-9Social security numberPID-3 (Patient Identifier List) where identifier type = ‘SS (CX, format varies refer to LOI IG).46499-0State of residencePID-11 (Patient Address) (XAD).42077-8TelephonePatient phone per LOINC definition.PID-13 (Phone Number – Home) (XTN).PID-14 (Phone Number – Business) (XTN).Refer to LOINC for suggested answer list.45401-7ZIP codePID-11 (Patient Address) (XAD).Appendix B – eDOS-LOI-LRI Field ComparisonThe table below illustrates how elements from the laboratory’s electronic directory of service (eDOS) are used in the laboratory order and laboratory result messages. There are nine data elements in common across the three implementation guides.There may be process issues that should be addressed during the pilot projects and outcomes/best practices documented in a subsequent version of the eDOS implementation guide.Legend used in the table below:Segment-positionElement nameDatatypeCommentTable STYLEREF 1 \s 8 SEQ Table \* ARABIC \s 1 1. Field ComparisoneDOS Release 2LOI – January 2013 Ballot LRI (July 2012 DSTU)OM1-2Producer’s Service/Test/Observation IDCWE_CROBR-4Universal Service IdentifierCWE_CR OBR-4Universal Service IdentifierCWE_CR OM1-31Observations Required to Interpret this ObservationCWE_CROBX-3Observation IdentifierCWE_CRAsk at Order EntryOBX-3Observation IdentifierCWE_CRAsk at Order EntryOM1-34OM1-34 Reflex Tests/ObservationsCWE_CROBR-4Universal Service IdentifierCWE_CROBR-4Universal Service IdentifierCWE_CROM1-49Diagnostic Serv Sect IDIDOM-49 did not exist in V2.5.1, pre-adopted from V2.8 by eDOSOBR-24Diagnostic Serv Sect IDIDOptional in LRI; defer to baseOBR-24Diagnostic Serv Sect IDIDOptional in LRI; defer to baseOM2-2Units of MeasureCWE_CREOBX-6UnitsCWE_CREOBX-6UnitsCWE_CRE OM2-6Reference (Normal) Range for Ordinal and Continuous ObservationsRFROBX-7References RangeSTOM5-2Test/Observations Included Within an Ordered Test BatteryCWE_CROBX-3Observation IdentifierCWE_CROBX-3Observation IdentifierCWE_CR CDM-1Primary Key Value – CDMCWE_CROBR-4Universal Service IdentifierCWE_CR OBR-4Universal Service IdentifierCWE_CRCDM-7Procedure CodeCNE (pre-adopted V2.7.1)OBR-44Procedure CodeCE (optional, from base V2.5.1)OBR-44Procedure CodeCE (optional, from base V2.5.1)Key Changes eDOS R1 to R2This document recaps key changes between Release 1 and Release 2 of the Laboratory Test Compendium Framework Implementation Guide (IG), also known as eDOS (electronic directory of service).ExceptionsRelease 1 was based on V2.6 but Release 2 is based on V2.5.1. New V2.6 elements that were not supported (X) were excluded from the IG.In Release 2 of the eDOS Implementation Guide optional elements are not further defined to indicate Usage, Data Type, or Cardinality; optional elements default to the base HL7 standard as explained in the Conventions section (excerpt below). These elements are not included in the list below. No conformance information is provided for optional message elements and segments (“O”) or unsupported message elements and segments (“X”). This includes cardinality, value sets and descriptive information. Implementers who want to use optional message elements should refer to the base HL7 V2.5.1 Standard to determine how these optional message elements will be used. Conformance information is provided when a conditional predicate resolves to an “R” or “RE” on either the “a” or “b” part of the expression, regardless of the opposite value, e.g., C(R/O).M08 MessageSFT segment X to OUAC segment omittedOM2 segment usage C to VariesOM3 segment C to REOM4 segment O to REM10 MessageSFT segment X to OUAC segment omittedOM5 segment C to ROM4 segment O to REM04 MessageSFT segment X to OUAC segment omittedOptional, repeating NTE segments addedPRC segment added per base V2.5.1 standard but is optional MSH SegmentMSH-3 Usage O to RE, Data Type HD to Varies (profile driven)MSH-4 Usage O to R, Data Type HD to Varies (profile driven), Cardinality [0..1] to [1..1]MSH-6 Usage O to RE, Data Type HD to Varies (profile driven)MSH-7 Data Type DTM to TS_1MSH-8 Usage X to OMSH-13 Usage X to OMSH-14 Usage X to OMSH-15 Usage O to R, Cardinality [0..1] to [1..1]MSH-16 Usage O to R, Cardinality [0..1] to [1..1]MSH-18 Usage X to OMSH-19 Usage X to OMSH-20 Usage X to O MSH-21 Usage O to R, Data Type EI to EI_GU, Cardinality [0..1] to [1..*]MFI SegmentMFI-4 Usage X to OMFE SegmentMFE-4 Usage Varies to CWE_RC, Cardinality [1..*] to [1..1]MFE-5 Cardinality [1..*] to [1..1]OM1 SegmentOM1-2 Data Type CWE to CWE_RCOM1-3 Usage X to OOM1-9 Usage C to REOM1-13 Usage X to OOM1-14 Usage X to OOM1-15 Usage X to OOM1-17 Usage X to OOM1-19 Usage X to OOM1-20 Usage X to OOM1-22 Usage O to REOM1-23 Usage O to REOM1-24 Usage X to OOM1-26 Usage X to OOM1-27 Usage CE to REOM1-28 Usage CE to C(R/O)OM1-29 Usage X to OOM1-30 Usage X to OOM1-31 Usage O to REOM1-32 Usage O to RE, Cardinality [0..*] to [0..1] OM1-33 Usage O to RE, Cardinality [0..*] to [0..1]OM1-34 Data Type CWE to CWE_RC1, Usage O to REOM1-35 Usage O to REOM1-36 Usage X to OOM1-37 Usage O to REOM1-38 Usage X to OOM1-39 Usage O to REOM1-40 Usage O to REOM1-42 Usage X to OOM1-43 Usage X to OOM1-44 Usage X to OOM1-45 Usage X to OOM1-46 Usage X to OOM1-47 Usage X to OOM1-48 Usage O to REOM1-49 Data Type CWE to ID (to match OBR-24 ID Data Type)OM1-51 Usage O to REOM1-52 addedOM1-53 addedOM1-54 addedOM2 SegmentOM2-1 Usage O to R, Cardinality [0..1] to [1..1]OM2-2 Data Type CWE to CWE_CRE, Usage O to REOM2-3 Usage X to OOM2-4 Usage X to OOM2-5 Usage X to OOM2-6 Usage O to REOM2-7 Usage O to REOM2-8 Usage O to REOM2-9 Usage X to OOM2-10 Usage X to OOM3 SegmentOM3-1 Usage O to R, Cardinality [0..1] to [1..1]OM3-2 Usage X to OOM3-3 Usage X to OOM3-4 Usage O to REOM3-5 Usage O to REOM3-6 Usage X to OOM3-7 Usage O to REOM4 SegmentOM4-2 Usage X to OOM4-3 Usage O to REOM4-4 Usage O to REOM4-5 Usage O to REOM4-6 Data Type CWE to CWE_CRE, Usage O to REOM4-7 Usage O to REOM4-10 Usage O to REOM4-11 Usage O to REOM4-12 Usage O to REOM4-13 Usage X to OOM4-14 Usage X to OOM4-15 Usage X to RE, Cardinality [0..1] to [0..*]OM4-16 Usage O to REOM4-17 Usage O to REOM5 SegmentOM5-1 Usage O to R, Cardinality [0..1] to [1..1]OM5-2 Data Type CWE to CWE_RC1, Usage O to R, Cardinality [0..*] to [1..*]OM5-3 Usage X to OCDM SegmentCDM-1 Data Type CWE to CWE_RCCDM-2 Usage X to OCDM-3 Data Type ST, Usage X to R, Cardinality [1..1]CDM-4 Usage X to OCDM-5 Usage X to OCDM-6 Usage X to OCDM-8 Usage X to OCDM-9 Usage X to OCDM-10 Usage X to OCDM-11 Usage X to OCDM-12 Usage X to OCDM-13 Usage X to O ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download