hl7 version 2.6 implementation guide: early hearing ......loss. because newborn hearing loss is a...

HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 February 2014 © 2014 Health Level Seven International. All rights reserved.

V26_IG_EHDI_DSTU_R1_2014FEB

HL7 Version 2.6 Implementation Guide: Early Hearing Detection and Intervention (EHDI)

Results, Release 1 Draft Standard for Trial Use

February 2014 Publication of this draft standard for trial use and comment has been approved by Health Level Seven International (HL7). This draft standard is not an accredited American National Standard. The comment period for use of this draft standard shall end 24 months from the date of publication. Suggestions for revision should be submitted at http://www.hl7.org/dstucomments/index.cfm.

Following this 24 month evaluation period, this draft standard, revised as necessary, will be submitted to a normative ballot in preparation for approval by ANSI as an American National Standard. Implementations of this draft standard shall be viable throughout the normative ballot process and for up to six months after publication of the relevant normative standard.

Sponsored By: Public Health/Emergency Response Group Name

PHER Work Group Co-chair: Joginder Madra Gordon Point Informatics, Ltd.

PHER Work Group Co-chair: Ken Pool, MD OZ Systems

PHER Work Group Co-chair: John Roberts Tennessee Department of Health

PHER Work Group Co-chair: Rob Savage, MS Rob Savage Consulting

Principal Author: Lura Daussat, MPH OZ Systems

Copyright © 2014 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.

http://www.hl7.org/dstucomments/index.cfm

HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 © 2014 Health Level Seven International. All rights reserved. February 2014

This material contains content from LOINC® (http://loinc.org). 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 http://loinc.org/terms-of-use.

IMPORTANT NOTES: HL7 licenses its standards and select IP free of charge. If you did not acquire a free license from HL7 for this document, you are not authorized to access or make any use of it. To obtain a free license, please visit http://www.HL7.org/implement/standards/index.cfm. If you are the individual that obtained the license for this HL7 Standard, specification or other freely licensed work (in each and every instance "Specified Material"), the following describes the permitted uses of the Material. A. HL7 INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS, who register and agree to the terms of HL7’s license, are authorized, without additional charge, to read, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part without paying license fees to HL7. INDIVIDUAL, STUDENT AND HEALTH PROFESSIONAL MEMBERS wishing to incorporate additional items of Special Material in whole or part, into products and services, or to enjoy additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS as noted below, must become ORGANIZATIONAL MEMBERS of HL7. B. HL7 ORGANIZATION MEMBERS, who register and agree to the terms of HL7's License, are authorized, without additional charge, on a perpetual (except as provided for in the full license terms governing the Material), non-exclusive and worldwide basis, the right to (a) download, copy (for internal purposes only) and share this Material with your employees and consultants for study purposes, and (b) utilize the Material for the purpose of developing, making, having made, using, marketing, importing, offering to sell or license, and selling or licensing, and to otherwise distribute, Compliant Products, in all cases subject to the conditions set forth in this Agreement and any relevant patent and other intellectual property rights of third parties (which may include members of HL7). No other license, sublicense, or other rights of any kind are granted under this Agreement. C. NON-MEMBERS, who register and agree to the terms of HL7’s IP policy for Specified Material, are authorized, without additional charge, to read and use the Specified Material for evaluating whether to implement, or in implementing, the Specified Material, and to use Specified Material to develop and sell products and services that implement, but do not directly incorporate, the Specified Material in whole or in part. NON-MEMBERS wishing to incorporate additional items of Specified Material in whole or part, into products and services, or to enjoy the additional authorizations granted to HL7 ORGANIZATIONAL MEMBERS, as noted above, must become ORGANIZATIONAL MEMBERS of HL7. Please see http://www.HL7.org/legal/ippolicy.cfm for the full license terms governing the Material.

http://loinc.org/terms-of-use

http://www.hl7.org/implement/standards/index.cfm

http://www.hl7.org/legal/ippolicy.cfm

Introduction

HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 Page 1-1 February 2014 © 2014 Health Level Seven International. All rights reserved.

Contents 1 Introduction ......................................................................................................................................... 1-3

1.1 Introduction ................................................................................................................................. 1-3 1.2 Intended Audience ..................................................................................................................... 1-3 1.3 Scope ......................................................................................................................................... 1-4 1.4 Other Related Profiles ................................................................................................................ 1-5 1.5 Conventions ............................................................................................................................... 1-5

2 Use Case and Conformance ................................................................................................................. 6 2.1 Conformance ................................................................................................................................. 6

2.1.1 Use Case Model .................................................................................................................... 6

2.2 Interaction Models ......................................................................................................................... 7 3 Messaging Infrastructure ..................................................................................................................... 10

3.1 HL7 Messaging Infrastructure ..................................................................................................... 10 3.1.1 HL7 definitions ..................................................................................................................... 10

3.2 Basic Message Construction Rules ............................................................................................ 11 3.2.1 Encoding Rules for Sending ................................................................................................ 11

3.2.2 Encoding Rules for Receiving ............................................................................................. 12

3.2.3 Implications of the Encoding Rules ..................................................................................... 12

3.3 Message Attributes Common to All Messages ........................................................................... 14 3.4 Segment Attributes Common to All Segments ............................................................................ 15

3.4.1 Table Data Types ............................................................................................................... 16

4 HL7 Data Types (4) ............................................................................................................................. 17 4.1 About Data Types ....................................................................................................................... 17 4.2 Data Types Used in ORU^R01 ................................................................................................... 17

4.2.1 CWE - Coded with Exceptions ............................................................................................ 18

4.2.2 CX – extended composite ID with check digits ................................................................... 19

4.2.3 DTM – Date/Time ................................................................................................................ 19

4.2.4 EI – Entity Identifier (EI) ...................................................................................................... 20

4.2.5 ERL – Error Location (ERL) ................................................................................................ 20

4.2.6 FN – Family Name .............................................................................................................. 21

4.2.7 HD- Hierarchic Designator .................................................................................................. 21

4.2.8 ID – Coded Value for HL7-defined Tables .......................................................................... 22

4.2.9 IS – Coded Value for User-defined Tables ......................................................................... 22

4.2.10 MSG – Message Type ........................................................................................................ 22

4.2.11 NM - Numeric ...................................................................................................................... 23

4.2.12 PL – Person Location .......................................................................................................... 23

4.2.13 PT- Processing Type ........................................................................................................... 23

4.2.14 SAD- Street Address ........................................................................................................... 24

4.2.15 SI - Sequence ID ................................................................................................................. 24

4.2.16 ST - String ........................................................................................................................... 24

2 HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 © 2014 Health Level Seven International. All rights reserved. February 2014

4.2.17 TX – Text Data .................................................................................................................... 25

4.2.18 VID – Version Identifier ....................................................................................................... 25

4.2.19 XAD – Extended Address ................................................................................................... 25

4.2.20 XCN – Extended Composite ID Number and Name for Persons ....................................... 26

4.2.21 XON – Extended Composite Name and Identification Number for Organizations ............. 26

4.2.22 XPN – Extended Person Name ........................................................................................... 27

4.2.23 XTN – Extended Telecommunication Number .................................................................... 27

5 Specification for an ORU^R01 Message ............................................................................................. 29 5.1 Specification of the EHDI Message ............................................................................................ 31 5.2 Message Transmission ............................................................................................................... 33 5.3 ACK^R01^ACK............................................................................................................................ 33 5.4 Messaging Infrastructure ............................................................................................................. 33

5.4.1 Message Header—MSH Segment ...................................................................................... 33

5.4.2 Patient Identification Segment—PID ................................................................................... 35

5.4.3 Patient Visit Segment—PV1 ............................................................................................... 37

5.4.4 NK1 Segment – Next of Kin Segment ................................................................................. 38

5.5 OBR Segments – Observation Request Segments .................................................................... 39 5.5.1 OBR for the Newborn Hearing Screening Panel ................................................................. 39

5.5.2 OBRs for Newborn Hearing Screen Panel of Ear – Right and Newborn Hearing Screen Panel of Ear - Left ............................................................................................................................... 39

5.6 OBX Segments – Observation Result Segments ....................................................................... 42 5.6.1 Observation Result Segment (OBX) for Hearing Loss Comments or Discussion .............. 44

5.6.2 Observation Result Segment (OBX) for Risk Factors of Hearing Loss .............................. 45

5.6.3 OBX Segments supporting the Newborn Hearing Screen Panel of Ear - Right OBR and the Newborn Hearing Screen Panel of Ear - Left OBR ............................................................................ 45

5.6.4 OBX Segments: Newborn Hearing screen right and Newborn Hearing Screen Left .......... 45

5.6.5 OBX Segments: Duration of screening of ear – right and Duration of screening of ear - left 46

5.6.6 OBX Segments: Reason Screen Not Done right ear and Reason Screen Not Done left ear 46

5.6.7 MSA Segment ..................................................................................................................... 49

5.7 Error Segment—ERR .................................................................................................................. 49 6 Code Tables ........................................................................................................................................ 51

6.1 MSH Table .................................................................................................................................. 51 6.2 PID Tables ................................................................................................................................... 51 6.3 NK1 Table ................................................................................................................................... 52 6.4 PV1 Tables .................................................................................................................................. 53 6.5 OBR Tables ................................................................................................................................. 55 6.6 OBX Tables ................................................................................................................................. 55

7 Appendix A – Sample Messages ........................................................................................................ 61

Introduction


1 Introduction

1.1 Introduction Early Hearing Detection and Intervention programs exist world-wide to help identify children with hearing loss. Because newborn hearing loss is a neuro-developmental emergency, children with hearing loss need to be identified shortly after birth to help them achieve better communication outcomes. Children identified with hearing loss can then be connected to appropriate services and speech and language delays can be reduced.

Early Hearing Detection and Intervention (EHDI) has evolved globally as a screening program where testing occurs at the point of care. To date, the format by which these data are transmitted, to the degree they are, has been by way of unstructured text or proprietary formats. Those formats do not provide consistency and interoperability. There are numerous device manufacturers and numerous potential recipient systems. The lack of a standard results in variations in data content, quality and reusability. The process of that constraint is most appropriately done under the auspices of HL7 so that uses of the message other than PCD-01 would be simultaneously served.

This implementation guide focuses on the transmission of these data elements from the hearing screening device to a recipient of data, which may be an EHR or a Public Health Information System. In fact, extensive work has been done to leverage the HL7 ORU^R01 message standard to target how patient care devices can functionally interoperate. This work has been done predominately under Integrating the HealthCare Enterprise (IHE) as the family of functional profiles known as PCD (Patient Care Devices). That effort establishes how actors in a process can use the HL7 message to enable different system actors to participate in such an exchange with fidelity. Specifically, the profile PCD-01 describes the functional profile that could apply to hearing screening data. In order to allow hearing screening to benefit from that extensive body of existing work, we will endeavor to follow the implementation constraints they required.

It is worth noting that by aligning this effort with the prior work underlying PCD-01 that it does not limit this standard implementation to only being used in that functional profile. Uses of the ORU^R01 message that are not conformant to the PCD-01 message can still be used. We expect that messages that are conformant to this standard will be conformant to IHE PCD-01 profile.

1.2 Intended Audience There are multiple intended audiences for this Implementation Guide. The first audience for this Guide is those involved in EHDI programs including implementers who will transmit data from point of care devices to public health. The second audience is hearing screening device manufacturers. In addition, this Guide is intended for review by those who may have hearing screening data they may need to send, for example an Electronic Health Record (EHR) or device manager system, and for those who have a need to receive hearing screening data, like Public Health or Electronic Health Record Systems (EHR-S).

This implementation guide is intended to specify the interface between a point of care device and public health or another entity. This does not specify how systems should be implemented to accomplish the goals of messaging.

4 HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 © 2014 Health Level Seven International. All rights reserved. February 2014

1.3 Scope EHDI program level protocols involve multiple screening results in each ear. They generally also include other information such as physical exam findings (atresia of an ear), risk factors, consent values, parent/contact information, and numerous other important data elements. A foundational element is the result of a screen performed on an ear. This Implementation Guide does not endeavor to provide a framework by which all aspects of an EHDI program can be exchanged but focus on the exchange of data from a device to public health or an EHR. This Guide is targeted in the belief that this will accelerate a foundational level of informational exchange and that it can be leveraged in subsequent projects as a contributor to broader information exchange standards for EHDI programs in general.

This Guide is intended to facilitate the exchange of newborn hearing screening results from a piece of equipment used for hearing screening to a recipient system, like public health or EHR system. This includes:

• Sending and receiving right ear results • Sending and receiving left ear results • Sending and receiving patient demographics specifically Patient Name, Patient ID • Sending and receiving the date and time of test(s) • Sending and receiving of Screener ID • Sending and receiving device details • Sending and receiving of test duration • Reporting errors about the messaging process • Acknowledging receipt of hearing screening information

The Guide is not intended to specify other issues such as:

• business rules, which are not implicit in HL7, applied when creating a message • business rules, which are not implicit in HL7, applied when processing a received message • the standard transport layer

Local implementations are responsible for the important issues described above. This Guide will identify some of the key issues that should be addressed in local profiles.

This Implementation Guide will use preferred standard vocabularies and adopt the vocabularies as they apply. Another effort, which promotes standards harmonization, is an organization called Integrating the Healthcare Enterprise (IHE)1. They produce profiles, which define how to accomplish various goals with common components. We expect that IHE profiles are conformant to this Implementation Guide.

This guide makes the following assumptions:

• Infrastructure is in place to allow accurate and secure information exchange from the device to an information system.

• Privacy and security has been implemented at an appropriate level. • Legal and governance issues regarding data access authorizations, data ownership and data use

are outside the scope of this document. • External business rules are assumed to be documented locally.

1 IHE is an industry-supported group, which creates implementable specifications, based on existing standards, to support accomplishment of selected use cases.

Introduction


1.4 Other Related Profiles Extensive work has been done to leverage the HL7 ORU^R01 message standard to target how patient devices can functionally interoperate. This work has been predominately done under Integrating the Healthcare Enterprise (IHE)1 as the family of functional profiles known as PCD (Patient Care Devices). That effort establishes how actors in a process can use the HL7 message to enable different system actors to participate in such an exchange with fidelity. Specifically, the PCD-01 describes the functional profile that could apply to hearing screening data. In order to allow the hearing screening to benefit from that extensive body of existing work, we will endeavor to follow the implementation constraints they required.

It is worth noting that by aligning this effort with the prior work underlying PCD-01 that it does not limit this standard implementation to being used only in that functional profile. Uses of ORU^R01 that are common outside of the PCD-01 framework will still be available.

1.5 Conventions This guide assumes that the implementer has access to the HL7 Standard 2.6 version. This implementation guide contains some of the standard; however some of the information has not been included. Please reference the version 2.6 HL7 standard for all details.

Use Case and Conformance

Page 6 HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 © 2014 Health Level Seven International. All rights reserved. February 2014

2 Use Case and Conformance

2.1 Conformance

2.1.1 Use Case Model This use case model covers the Messaging of Early Hearing Detection and Intervention (EHDI) data from a patient care device to an interested consumer such as public health.

Purpose: The use case focuses on the transmission of newborn hearing screening results, observations, from a device to an information system in a place like public health using the HL7 2.6 ORU^R01 message. The purpose is to exchange data directly from the device. This provides advantages for the receiving consumer of this information including protection from data changes in data transmission, more robust data, authenticated results, increased security and audit capabilities. This will allow EHDI programs or EHRs to have all the details associated with hearing screening, not just a pass or refer result.

Actors: The primary actors in the EHDI messaging use case include:

• Hearing Screening Devices • Public Health Information System • Electronic Health Record

This Implementation Guide will focus on the data elements sent from the hearing screening device used in newborn hearing screening to a Public Health Information System. The actors will be senders of information/data and consumers/requestors of data. An alternate flow would be to send the hearing screening results from the device to an Electronic Health Record (EHR). This message structure could also be used to send hearing screening result data from an EHR to public health.

Other actors who have an interest in the functions of an EHDI newborn screening message are:

• Patients • Parents/Guardians • Clinicians including pediatricians and audiologists • Hearing Screeners • Public Health staff • Billing Systems • Early Intervention Staff

These actors will not be specifically addressed but will interact with the primary actors to accomplish their needs.

Table 2—1 Actors and Goals for Messaging

Actor Responsibility Messaging Goals

Hearing Screening Device Capture data elements when a newborn hearing screening is performed on an infant Supply individual hearing screening results to authorized users and systems

Supply comprehensive individual hearing screening results to an interested consumer such as public health Receive an acknowledgement that data has been transmitted

Public Health Information System Provide access to a complete newborn Receives observations about the hearing


HL7 Version 2.6 IG: Early Hearing Detection and Intervention (EHDI) Results, DSTU R1 Page 7 February 2014 © 2014 Health Level Seven International. All rights reserved.

Actor Responsibility Messaging Goals screening record for each newborn born within the jurisdiction Support reporting and analysis of individual and aggregate EHDI data Provide information to ensure the child if identified with hearing loss is connected with the appropriate services

screening Sends acknowledgement of a receipt of the message

Electronic Health Record system (EHR-s)

Houses a patient’s electronic health record Makes a person’s health record electronically available and accessible to authorized personnel

Receives observations about the hearing screening Sends acknowledgement of a receipt of the message Alternate use case: to send hearing screening results to public health or another recipient using message.

Flow of Events: A newborn has a hearing screening administered by a hearing screener. The screener uses either an Otoacoustic Emissions (OAE) or an Automated Auditory Brainstem Response (AABR) device to conduct the hearing screening on the newborn. The right ear and left ear are screened and data elements including if the patient pass or referred, risk factors for hearing loss, demographic information and contact information, are collected in the device. Once the screening is complete, the data either comes directly from the device by a connection to a computer or the file is downloaded to the hearing screening device software where a HL7 ORU^R01 message is packaged containing the MSH, PID, PV1, NK1, OBR and OBX segments and it is then sent to a recipient like a Public Health Information System. The Public Health Information System then sends an acknowledgement message that they received the message.

One alternate flow is that the information is sent to the Electronic Health Record – System. The EHR-S sends an acknowledgement message that they received the message. The provider conducting the hearing screening test MAY also need to incorporate that information in the newborn EHR.

Another alternate flow include sending information on hearing screening results from the EHR-S to public health or another interested party. The Public Health Information System then sends an acknowledgement message that they received the message.

The message profile is required anytime data is sent electronically from a device to public health or an EHR-S.

2.2 Interaction Models This section describes the interaction between the hearing screening device and the Public Health Information System, the hearing screening device and an Electronic Health Record – System and an EHR-S and Public Health.


Figure 2—1 Interaction between a patient care device and a Public Health Information System

Figure 2—2 Interaction between a patient care device and an Electronic Health Record – System



Figure 2—3 Interaction between Electronic Health Record – System and Public Health


3 Messaging Infrastructure

3.1 HL7 Messaging Infrastructure This section will contain a basic description of the terms and definitions, which are used in this document in order to understand the Health Level 7 standard. More detail may be found in the HL7 2.6 standard in Chapters 2, 2A and 2B.

3.1.1 HL7 definitions This section contains the definitions that are used to compose a HL7 message.

Message: A message is the entire unit of data transferred between systems in a single transmission. It is made up of segments arranged in a particular order. Refer to Chapter 5 for the full message structure.

This is the message structure utilized in this Implementation Guide.

Table 3-1 Message Segments

Segment Description

MSH|… Message Header

PID|… Patient Information

NK1|… Next of Kin Information

PV1|… Patient Visit Information

OBR|… Newborn Screening Panel and Left ear panel and/or right ear panel

OBX|… Data for each hearing screen

Segment: A segment is a logical grouping of data fields. Segments may be required or optional, may occur only once, or may be allowed to repeat. Each segment is named and is identified by a segment ID, a unique 3-character code.

Segment ID: 3 character code that identifies the segment. Example: MSH for Message Header

Field: A field is a string of characters and is of a specific data type. Each field is identified by the segment it is in and its position within the segment

Component: A component is one of a logical grouping of items that comprise the contents of a coded or composite field. Within a field having several components, not all components are required to be valued.

Data Type: The unit that is used to construct or restrict the contents of the data field. They are 2 or 3 letter codes. Table 4.1 contains all data types used in this IG. Please refer to the data types chapter in the base 2.6 standard for all data type definitions.

Messaging Infrastructure


Item number: Each field is assigned a unique item number. Fields that are used in more than one segment will retain their unique item number across segments.

Null and empty fields: The null value is transmitted as two double quote marks (“”) between delimiters. A null-valued field differs from an empty field. An empty field should not overwrite previously entered data in the field, while the null value means that any previous value in this field should be overwritten.

Table 3-2 Value in Field

Value in Field Meaning

“” |””|

Nullify the value recorded in the receiving system data base.

<empty field> ||

Make no changes to the record in the receiving data base. The sending system has no information on this field.

Code Sets/Systems: Most data elements will have associated lists of acceptable values in tables supported by a standards organization such as HL7 or CDC. These code sets will include definitions to support common usage.

Delimiters: Delimiter characters are used to separate segments, fields and components in an HL7 message. The delimiter values are given in MSH-2 and used throughout the message. Applications must use agreed upon delimiters to parse the message. Messages used in this Guide shall use the following delimiters:

<CR> = Segment Terminator;

| = Field Separator;

^ = Component Separator;

& = Sub-Component Separator;

~ = Repetition Separator;

\ = Escape Character.

Message syntax: Each message is defined in special notation that lists the segment 3-letter identifiers in the order they will appear in the message. Braces, {}, indicate that one or more of the enclosed group of segments may repeat, and brackets, [ ], indicate that the enclosed group of segments is optional. Note that segments may be nested within the braces and brackets. This will indicate that the nested segments are units within a subgroup of segments. Their Usage is relative to the parent segment in the group.

3.2 Basic Message Construction Rules

3.2.1 Encoding Rules for Sending Encode each segment in the order specified in the abstract message format. MSH must be the first segment. OBX segments must immediately follow the corresponding OBR.

1. Place the Segment ID first in the segment.


2. Precede each data field with the field separator. 3. Encode the data fields in the order and data type specified in the segment definition table. 4. End each segment with the segment terminator. 5. Components, subcomponents, or repetitions that are not valued at the end of a field need not be

represented by component separators. 6. Components, subcomponents, or repetitions that are not valued, but precede components,

subcomponents or repetitions that are valued must be represented by appropriate separators. 7. If a field allows repetition (Cardinality maximum > 1), then the length of the field applies to EACH

repetition.

3.2.2 Encoding Rules for Receiving 1. If a data segment that is expected is not included, treat it as an error. 2. If a data segment is included that is not expected, ignore it; this is not an error. 3. If data fields are found at the end of a data segment that are not expected, ignore them; this is not

an error.

3.2.3 Implications of the Encoding Rules The approach for this HL7 version is so that it can act as a base that other Implementation Guides can use by either:

1. Extending this standard by adding additional supported segments and/or fields

OR

2. Constraining this standard by explicitly excluding segments, fields, and/or code values.

In this spirit, segment types other than MSH, PID, PV1, OBR and OBX may be included but are not supported and therefore may be ignored by the receiver implementing this Implementation Guide.

If a field is an encoded value and the code value for that field is not recognized or cannot be processed by the receiver then if that field is optional then the receiver should ignore the value. If the field is required but the segment that the field is in is an optional segment, then the receiver should ignore the entire segment. So, if the field is a required field in a required segment and the code is invalid then the entire message should be rejected.

This Implementation Guide also endeavors to specify coded values as those associated with a specific value set rather than explicitly enumerating the values in use at this time. It is possible that over time the codes for a given value set may add values that the receiver cannot process. That could be because the code is in fact invalid, because the current value set used by the receiver is out of date, or because the code value is one that they receiver is not prepared to process. In any of these cases the encoded field error should be treated as described above. Thus it is worth noting that a message can validly be rejected by a receiver even though the message itself is technically valid. Such a rejection just indicates that this specific exchange cannot be performed.

Table 3-3 Usage Code Interpretations for Fields, Components and Sub-Components

Usage Code Interpretation Comment

R Required A conforming sending application shall populate all “R” elements with a non-empty value.




Conforming receiving application shall process or ignore the information conveyed by required elements. A conforming receiving application must not raise an error due to the presence of a required element, but SHALL raise an error due to the absence of a required element.

RE Required but may be empty The element may be missing from the message, but must be sent by the sending application if there is relevant data. A conforming sending application must be capable of providing all "RE" elements. If the conforming sending application knows the required values for the element, then it must send that element. If the conforming sending application does not know the required values, then that element will be omitted. Receiving applications will be expected to process or ignore data contained in the element, but must be able to successfully process the message if the element is omitted (no error message should be generated because the element is missing).

C Conditional This usage has an associated condition predicate. This predicate is an attribute within the message. If the predicate is satisfied: A conformant sending application must always send the element. A conformant receiving application must process or ignore data in the element. It may raise an error if the element is not present. If the predicate is NOT satisfied: A conformant sending application must NOT send the element. A conformant receiving application must NOT raise an error if the condition predicate is false and the element is not present, though it may raise an error if the element IS present.

CE Conditional but may be empty

This usage has an associated condition predicate. This predicate is an attribute within the message. If the predicate is satisfied: If the conforming sending application knows the required values for the element, then the application must send the element. If the conforming sending application does not know the values required for this element, then the element shall be omitted. The conforming sending application must be capable of knowing the element (when the predicate is true) for all ‘CE’ elements. If the element is present, the conformant receiving application shall process or ignore the values of that element. If the element is not present. The conformant receiving application shall not raise an error due to the presence or absence of the element. If the predicate is not satisfied: The conformant sending application shall not populate the element. The conformant receiving application may raise an application error if the element is present.

O Optional This element may be present if specified in local profile. Local partners may develop profiles that support use of this element. In the absence of a profile, conformant sending applications will not send the element. Conformant receiving applications will ignore the element if it is sent, unless local profile specifies otherwise. Conformant receiving applications may not raise an error if it receives an unexpected optional element.



X Not Supported The element is not supported. Sending applications should not send this element. Receiving applications should ignore this element if present. A receiving application SHALL raise an error if it receives an unsupported element. Any profile based on this Guide should not specify use of an element that is not supported in this Guide.

Table 3-4 Usage Code Interpretation for Segments


R Required A conforming sending application shall include all “R” segments. A conforming receiving application must process all required segments. It should raise an error due to the absence of a required segment.

RE Required but may be empty

The segment may be missing from the message, but must be sent by the sending application if there is relevant data. A conforming sending application must be capable of providing all "RE" segments. If the conforming sending application has data for the required segment, then it must send that segment. Receiving applications will be expected to process the data contained in the segment. It must be able to successfully process the message if the segment is omitted (no error message should be generated because the segment is missing).

O Optional This segment may be present if specified in local profile. Local partners may develop profiles that support use of this segment. In the absence of a profile, conforming sending applications will not send the element. Conformant receiving applications will ignore the element if it is sent, unless local profile specifies otherwise.

X Not Supported The segment is not supported. Sending applications should not send this element. Receiving applications should ignore this element if present. Any profile based on this Guide should not specify use of an element that is not supported in this Guide.

3.3 Message Attributes Common to All Messages The following table describes the various attributes used by this guide to document message structure attributes. These terms will be used in the tables defining message profiles throughout this Guide.

Table 3-5 Message Attributes

Message Attributes

Attribute Description

Segment Three-character code for the segment and the abstract syntax (i.e., the square and curly braces) [ XXX ] Optional



Message Attributes

Attribute Description

{ XXX } Repeating XXX Required (not inside any braces) [{ XXX }] Optional and Repeating [ XXX [YYY] ] YYY is nested within the segment block starting with XXX. It is an optional sub-segment to XXX . The whole block is optional. Note: for Segment Groups there will not be a segment code present, but the square and curly braces will still be present.

Name Name of the Segment or Segment group element.

Usage Usage of the segment. Indicates if the segment is required, optional, or not supported in a message. See table with Usage Code Interpretation above.

Cardinality Indicator of the minimum and maximum number of times the element may appear. [0..0] Element never present. [0..1] Element may be omitted and it 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 for 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.

3.4 Segment Attributes Common to All Segments The abbreviated terms and their definitions, as used in the segment table headings, are as follows:

Table 3-6 Segment Attributes

Abbreviation Description

Seq Sequence of the elements (fields) as they are numbered in the segment

Len Recommended maximum length of the element. Lengths are provided only for primitive data types. Lengths should be considered recommendations, not absolutes. The receiver may truncate fields, components, and sub-components longer than the recommended length. The receiver should not fail to process a message simply because fields, components, or sub-components are too long.


Abbreviation Description

Data Type Data type used for HL7 element. Data type specifications can be found in Chapter 4.

Usage Indicates whether the field is supported in this Guide. Indicates if the field, component, or subcomponent is required, optional, or conditional in the corresponding segment, field, or component. See Usage Code Interpretation, above. Note: A required field in an optional segment does not mean the segment must be present in the

message. It means that if the segment is present, the required fields within that segment must be populated. The same applies to required components of optional fields. If the field is populated, then the required component must be populated. The same applies to required sub-components of optional components. If a component is populated, the required sub-components of that component must also be populated.

Cardinality Indicator of the minimum 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 for 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.

Item # Unique item identifier in HL7

HL7 Element Name HL7 descriptor of the element in the segment.

Comment Lists any constraints imposed and other comments in this Guide

3.4.1 Table Data Types Reader should refer to base standard, HL7 V2.6 for details on data types. Specific data type requirements for this Implementation Guide are addressed in Chapter 4.

HL7 Data Types (4)


4 HL7 Data Types (4)

4.1 About Data Types The foundation of successful interoperability is data types. In each message, a field, component or sub-component has a data type. When systems communicate between each other, agreement on the data type for each component ensures good communication. This Implementation Guide uses the standard V2.6 definitions for the data types. This chapter provides more information on how data types are used in this Implementation Guide.

4.2 Data Types Used in ORU^R01 The following is a list of data types used in the ORU^R01 message for EHDI.

Table 4-1. Data Types

Data type Data Type Name Segment Location

CWE Coded with Exceptions MSH 19, PID 10, PID 15, PID 22, NK1-3, OBR 4, OBR 39, OBX 3, OBX5, OBX 6, OBX 17, OBX20, ERR 3

CX Extended Composite ID with Check Digit PID 3, PID 18, PID 21

DTM Date/Time MSH 7, PID 7, PID 33, OBR 7, OBR 22, OBX 14, OBX 19

EI Entity Identifier OBR 2, OBR 3, OBX 18

ERL Error Location ERR 2

FN Family Name PID 5, PID 6, OBR 10, OBR 16, OBR 28, OBX 25

HD Hierarchic Designator MSH 3, MSH 4, MSH 5, MSH 6, PID 34

ID Coded Values for HL7 Tables MSH 15, MSH 16, MSH 17, MSA 1, ERR 4, PID 24, OBR 25, OBX 2, OBX 11

IS Coded value for User-Defined Tables PID 8, PV1-2, OBX 8

MSG Message Type MSH 9

NM Numeric PID 25, OBX 2, OBX 5

PL Person Location PV1-3

PT Processing Type MSH 11

SAD Street Address In the XAD data type, which is part of PID 11, NK1-4, OBX 24

SI Sequence ID PID 1, NK1-1, OBR 1, OBX 1

ST String MSH 1, MSH 2, MSH 10, PID 23, OBX 4, OBX 7,


Data type Data Type Name Segment Location

MSA 2,

TX Text Data OBX 5, ERR 7, ERR 8

Var Variable OBX 5

VID Version Identifier MSH 12

XAD Extended Address PID 11, NK1-4, OBX 24

XCN Extended Composite ID Number and Name

PV1-7, OBR 10, OBR 16, OBR 28, OBX 25

XON Extended Composite Name and ID Number for Organizations

OBX 23

XPN Extended Person Name PID 5, PID 6, NK1-2

XTN Extended telecommunications number PID 13, NK1-5, OBR 17, ERR 12

4.2.1 CWE - Coded with Exceptions

Table 4-2 Coded with Exceptions (CWE)

SEQ LEN DT Usage Value Set Component Name Comments

1 20 ST R Identifier The first component contains the sequence of characters (the code) that uniquely identifies the item be referenced by the CWE. The identifier is required and must be a valid code.

2 199 ST RE Text This contains the descriptive or textual name of the identifier; for example Newborn Hearing Screen Panel.

3 20 ID RE 0396 Name of Coding System This contains the code for the name of the coding system from which the value CWE.1 is obtained. For example, LN for LOINC terminology. Each coding system is assigned a unique identifier

Usage: This data type is used where it is necessary to communicate a code, text, coding system and the version of coding system the code was drawn from.

Example: |54111-0^Newborn hearing loss panel^LN |

HL7 Data Types (4)


4.2.2 CX – extended composite ID with check digits

Table 4-2 CX – Extended Composite ID with Check Digits (CX)

SEQ LEN DT Usage Value Set

Component Name

Comments

1 15 ST R ID Number The value of the identifier itself

4 227 HD RE Assigning Authority

The unique name of the system or organization, agency or department that creates the data.

5 5 ID RE HL7 0203 Identifier Type Code

A code corresponding to the type of identifier. For example MR for Medical record number.

6 227 HD RE Assigning Facility The place or location identifier where the identifier was first assigned to the patient. This helps with the history part of the identifier.

9 705 CWE RE HL7 0399 or HL7 0347 or HL7 0289

Assigning Jurisdiction

The geo-political body that assigned the identifier in component 1. This could be the Country, state/province, or the county. In the US, postal codes may be used.

10 705 CWE RE Assigning Agency or Department

The agency or department that assigned the identifier in component 1.

Usage: This data type is used for specifying an identifier with its associated administrative detail.

Example:

|12345^^^NPI&2.16.840.1.113883.19.3.2.1&ISO^MR^Hospital&2.16.840.

1.113883.19.3.2.1&ISO^^^TX^Hospital|

4.2.3 DTM – Date/Time

Table 4-3 Date/Time (DTM)


1 4.24 R Date/Time Format: YYYYMMDD[HH[MM[SS[.S[S[S[S]]]]]]]+/-ZZZZ.

Usage: Specific fields in this implementation guide may require Date/Time to a specific level of granularity, which may require the time zone offset.

Example: |20130523082-0600|


4.2.4 EI – Entity Identifier (EI)

Table 4-4 Entity Identifier (EI)


Component Name Comments

1 199 ST R Entity Identifier This is unique within the series of identifiers created by the assigning authority, defined by a hierarchic designator, represented by components 2 through 4.

2 20 IS RE Namespace ID This is the unique identifier of the system, organization, agency or department that creates the data.

3 199 ST RE Universal ID Must be an OID

4 6 ID RE Universal ID Type This governs the interpretation of the second component of the HD.

Usage: The entity identifier defines a given entity within a specified series of identifiers.

Example: |Maico~EroScan~Instance1~1234abc~WellBaby screener|

4.2.5 ERL – Error Location (ERL)

Table 4-5 Error Location (ERL)

SEQ LEN DT Usage Value Set Component Name

Comments

1 3 ST R Segment ID Specifies the 3 letter name for the segment

2 2 NM R Segment Sequence

Identifies the segment occurrence within the message.

3 2 NM RE Field Position Identifies the number of the field within the segment.

4 2 NM RE Field Repetition Identifies the repetition number of the field.

5 2 NM RE Component Number

Identifies the component number.

6 2 NM RE Sub-Component Number

Identifies the sub-component

HL7 Data Types (4)



Comments

number.

Usage: Used to communicate the location of the error in the message.

Example: |MSH^3|

4.2.6 FN – Family Name

Table 4-6. Family Name


Comments

1 50 ST R Surname The atomic element of the person’s family name. IN most Western usage, this is the person’s last name.

Usage: This data type allows full specification of the surname of a person.

4.2.7 HD- Hierarchic Designator Table 4-7 Hierarchic Designator (HD)

Table 4-8. Hierarchic Designator (HD)


Comments

1 20 IS R Namespace ID This is the unique identifier of the system, organization, agency or department that creates the data.

2 999 ST RE Universal ID This is a string formatted according to a scheme defined by the third component. It is recommended that this field be an OID.

3 6 ID RE HL7 0301 Universal ID Type This governs the interpretation of the second component of the HD.

Usage: 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, that usage is described separately in this implementation guide. In this implementation guide, you either must have the namespace ID or the Universal ID and Universal ID type. All 3 are also permitted.


Note: The HD data type has been constrained to carry an OID identifying an application, a facility, or an assigning authority.

Example: |Hospital^1.3.6.1.4.1.23437.12.51.32^HL7|

4.2.8 ID – Coded Value for HL7-defined Tables

Table 4-9. Coded Value for HL7 Defined-tables



1 15 R Coded Value for HL7-Defined Tables

Usage: The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal value. There shall be an HL7 table number associated with ID data types.

Example: |AL|

4.2.9 IS – Coded Value for User-defined Tables

Table 4-10 Coded Value for User-Defined Tables


Comments

1 20 R Coded Value for User-Defined Tables

Usage: The value of such a field follows the formatting rules for an ST field except that it is drawn from a table of legal values. There shall be an HL7 table number associated with IS data types.

Example: |F|

4.2.10 MSG – Message Type

Table 4-11 Message Type (MSG)


Comments

1 3 ID R 0076 Message Code Specifies the message type code. For EHDI messages, this is ORU.

2 3 ID R 0003 Trigger Event Specifies the trigger event code. For EHDI messages this is R01.

3 7 ID R 0354 Message Structure

Specifies the message structure. For EHDI messages, this is ORU^R01

HL7 Data Types (4)


Usage: This field contains the message type, trigger event, and the message structure ID for the message.

Example: |ORU^R01^ORU_R01|

4.2.11 NM - Numeric

Table 4-12 Numeric (NM)


Component Name

Comments

1 16 R Numeric HL7 allows only ASCII numeric characters as well as an optional leading plus or minus sign and an option decimal point. Note that use of scientific notation for numbers is not supported by this data type.

Example: |10|

4.2.12 PL – Person Location

Table 4-13 Person Location (PL)


1 20 IS RE Hl70302 Point of Care

Usage: This data type specifies a patient location within a healthcare institution. For example, this would be the location of the patient during the hearing screening. In newborn hearing screening, the point of care shall populated by the nursery location.

Example: |1245123555|

4.2.13 PT- Processing Type

Table 4-14 Processing Type (PT)


Comments

1 1 ID R HL7 0103 Processing ID A value that defines whether the message is part of a production, training or debugging system.

Usage: This data type indicates whether to process a message as defined in HL7 Application processing rules.

Example: |P|


4.2.14 SAD- Street Address

Table 4-15 Street Address (SAD)


Component Name

Comments

1 120 ST R Street or Mailing Address

Usage: The SAD is used only as a component of the XAD data type.

Example: |123 House Street|

4.2.15 SI - Sequence ID

Table 4-16 Sequence ID (SI)


Comments

4 R HL7 0103 Sequence ID Non-negative integer in the form of a NM field. Allows for a number between 0 and 9999 to be specified.

Usage: This data type indicates whether to process a message as defined in HL7 Application processing rules.

Example: |1|

4.2.16 ST - String

Table 4-17 String (ST)


Comments

999 R String Data

Usage: The ST data type is normally used for short text strings. No leading blanks are permitted. Trailing blanks are permitted.

Example: |almost any test data at all|

HL7 Data Types (4)


4.2.17 TX – Text Data

Table 4-18 Text Data (TX)


Comments

65536 R Text Data

Usage: The TX data type is used to carry string data intended for display. Leading spaces are allowed.

Example: | leading spaces are allowed|

4.2.18 VID – Version Identifier

Table 4-19 Version Identifier (VID)


1 5 ID R 0104 Version ID In this version it is 2.6

2 483 CWE RE 0399 Internationalization Code

3 483 CWE RE International Version ID

Usage: The TX data type is meant for user display.

Example: |2.6|

4.2.19 XAD – Extended Address

Table 4-20 Extended Address (XAD)



1 184 SAD RE Street Address This is the street address

2 120 ST RE Other Designation

3 50 ST RE City

4 50 ST RE State or Province

5 12 ST RE Zip or Postal Code

6 3 ID RE HL70399 Country

9 20 IS RE HL70289 County/Parish Code

Usage: This data type specifies the address of a person, place or organization.


Example |1000 Ear Street^Suite ABC^Dallas^TX^99999^USA^^^WA^|

4.2.20 XCN – Extended Composite ID Number and Name for Persons

Table 4-21 Extended Composite ID Number and Name for Persons (XCN)


1 15 ST RE ID Number Coded ID

2 194 FN RE Family Name Person’s surname

3 30 ST RE Given Name Person’s first name.

4 30 ST RE Second and Further Given Names or Initials Thereof

Multiple middle names may be included by separating them with spaces.

5 20 ST RE Suffix (e.g., JR or III) Person’s name suffix.

6 20 ST RE Prefix (e.g., DR) Person’s name prefix.

9 227 HD HD Assigning Authority The assigning authority is a unique identifier of the system that creates the data.

13 5 ID RE HL70203 Identifier Type Code A code corresponding to the type of identifier. In this IG, it is recommended it be the NPI.

Usage: This data type is used when there is a need to specify the ID number and name of a person.

Example: |1001001^Smith^Theodore^^^Dr^^^OPH^^^^NPI|

4.2.21 XON – Extended Composite Name and Identification Number for Organizations

Table 4-22 Extended Composite Name and Identification Number for Organizations (XON)


1 50 ST R Organization Name The name of the specified organization.

6 227 HD RE HL70363 Assigning Authority Unique identifier of the system that creates the data.

7 5 ID RE HL70203 Identifier Type Code A code representing the type of identifier.

8 227 HD RE Assigning Facility The place or location where the identifier

HL7 Data Types (4)



was first assigned to the person.

Usage: This data type is used when there is a need to specify the ID number and name of an organization.

Example: |Happy Ear Hospital^^^^^HN&Hospital Network&123^NPI^OPH|

4.2.22 XPN – Extended Person Name

Table 4-23 Extended Person Name (XPN)


Component Name

Comments

1 194 FN RE Family Name Person’s surname

2 30 ST RE Given Name Person’s first name.

3 30 ST RE Second and Further Given Names or Initials Thereof

Multiple middle names may be included by separating them with spaces.

4 20 ST RE Suffix (e.g., JR or III)

Person’s name suffix.

5 20 ST RE Prefix (e.g., DR) Person’s name prefix.

Usage: This data type is used to specify the person’s name.

Example |Last^John^Doe^JR^DR|

4.2.23 XTN – Extended Telecommunication Number

Table 4-24 Extended Telecommunication Number (XTN)


Component Name

Comments

2 3 ID RE HL70201 Telecommunication Use Code

This represents a specific use of a telecommunication number. Example: Primary Residence Number

3 8 ID RE HL70202 Telecommunication Equipment Type

This represents the type of telecommunication equipment, example: Fax

4 199 ST C Communication Address

This is required if neither XTN.7 or XTN.12 are populated.

5 3 NM RE Country Code This is the country code to access telephone



Component Name

Comments

services in another country.

6 5 NM RE Area/City Code This is the numeric code to access telephone services in another area/city within a country.

7 9 NM RE Local Number This is the numeric code used to contact the called party. The size of the local number is country specific.

8 5 NM RE Extension The numeric code to contact the called party used with an organization.

Usage: This data type is used to communication the telecommunication number of a person or organization.

Example: |^PRN^PH^^1^555^5552003|

Specification for an ORU^R01 Message


5 Specification for an ORU^R01 Message Below is the full definition of the ORU^R01 message profile. The segments in gray are not supported in this implementation guide. The key segments for this implementation guide are in bold and include the MSH, PID, NK1, PV1, OBR and OBX segments. The data found in these segments are key to reporting newborn hearing screening results. Data found in the other segments may be important but are not essential to interpreting the message.

Table 5-1 Full Definition of ORU^R01 Message Profile (non-supported segments included).

Segment Name Usage Cardinality Refer to Base Standard Chapter:

MSH Message Header R [1..1] 2

[{ SFT }] Software Segment X 2

[UAC] User Authentication Credential X 2

{ --- PATIENT_RESULT begin

[ --- PATIENT begin

PID Patient Identification R [1..1] 3

[PD1] Additional Demographics X 3

[{NTE}] Notes and Comments X 2

[{NK1}] Next of Kin/Associated Parties RE [0..*] 3

[{OBX}] Observation (for Patient ID) X 7

[ --- VISIT begin

PV1 Patient Visit R [1..1] 3

[PV2] Patient Visit - Additional Info X 3

] --- VISIT end

] --- PATIENT end

{ --- ORDER_OBSERVATION begin

[ORC] Order common X 4

OBR Observations Request R [1..3] 7

{[NTE]} Notes and comments X 2

[{ROL}] Role (for observation) X 15


Segment Name Usage Cardinality Refer to Base Standard Chapter:

[{ --- TIMING_QTY begin X

TQ1 Timing/Quantity X 4

[{TQ2}] Timing/Quantity Order Sequence

X 4

}] --- TIMING_QTY end X

[CTD] Contact Data X 11

[{ --- OBSERVATION begin RE

OBX Observation related to OBR RE [0..*] 7

{[NTE]} Notes and comments X 2

}] --- OBSERVATION end RE

[{FT1}] Financial Transaction X 6

{[CTI]} Clinical Trial Identification X 7

[{ --- SPECIMEN begin X

SPM Specimen X

[{OBX}] Observation related to Specimen

X

}] --- SPECIMEN end X

} --- ORDER_OBSERVATION end

X

} --- PATIENT_RESULT end X

[DSC] Continuation Pointer X 2



5.1 Specification of the EHDI Message Below is the specification of the EHDI ORU^R01 message used in this Implementation Guide with all the "O" and "X" omitted for clarity.

Table 5-2 Specification of EHDI ORU^R01 Message

ORU^R01^ORU_R01 Unsolicited Observation Message

Optionality Cardinality HL7 V2.6 Chapter

Description

MSH Message Header R 1..1 2 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.

{ --- PATIENT_RESULT begin

--- PATIENT begin PID Patient Identification R 1..1 3 The patient identification (PID)

segment is used to communicate patient identifying information.

[{NK1}] Next of Kin/Associated Parties

RE 0..* 3 The Next of Kin segment is used to communicate information on patient contacts.

[ --- VISIT begin

PV1 Patient Visit RE 0..1 3 The patient visit segment is used to communicate information on a visit-specific basis.

] --- VISIT end --- PATIENT end { ---

ORDER_OBSERVATION begin

OBR Observations Request R 1..3 7 The observation request (OBR) segment is used to capture information about the hearing screening panel performed. One OBR will report the newborn hearing loss panel. This SHALL be followed by an OBR for the newborn hearing screen panel of the right ear and an OBR for the newborn hearing screen panel of the left ear.

[{ --- OBSERVATION begin OBX Observation related to

OBR R 0..*

1..* (see note)

7 The Observation Result (OBX) segment contains information regarding hearing screening


ORU^R01^ORU_R01 Unsolicited Observation Message

Optionality Cardinality HL7 V2.6 Chapter

Description

results on the left ear and the right ear. This includes identification of the specific type of observation, the result for the observation, when the observation was made, etc. For newborn hearing screening there is a panel for hearing screening that has been promoted. This hearing screening panel will have 3 OBRs; 1 overarching, 1 for the left ear and 1 for the right ear and this structure resembles the structure used by LOINC in the newborn hearing loss panel. The overarching OBR MAY be supported by OBX segments that carry information on hearing comments/discussion or hearing loss indicators. The Newborn hearing screen panel of ear – right OBR, will be supported by OBX segments for the newborn hearing screening right ear, with the method in OBX-17, the duration, and if appropriate, the reason the screen was not performed. The Newborn hearing screen panel of ear – left, OBR, will be supported by OBX segments for the newborn hearing screening left ear, with the method in OBX-17, the duration, and if appropriate, the reason it was not done. The OBX segments should contain the result of the hearing screening, the technique, the equipment and the date and time of the screen.

}] --- OBSERVATION end

} --- ORDER_OBSERVATION end

} --- PATIENT_RESULT end

OBX NOTE: For the hearing screening panel OBR, the OBX Cardinality is [0..*], for the right ear and left ear OBRs, the OBX cardinality is [1..*].



5.2 Message Transmission The ORU^R01 message MAY contain a single Observation Request (OBR) for the newborn hearing screening panel, 0 to 1. The Observation Request (OBR) for the newborn hearing loss panel right ear shall be supported by at least 1 OBX. The Observation Request (OBR) newborn hearing loss panel left shall be supported by at least 1 OBX. There MAY be multiple OBX segments associated with OBRs for newborn hearing loss panel right ear and newborn hearing loss panel left ear. Batch messaging SHALL not be supported.

5.3 ACK^R01^ACK Guaranteed delivery is required. An ACK message should always be returned to the sender of this message as specified in this guide. All other acknowledgement methods are beyond the scope of this document.

Table 5—3 ACK^R01^ACK Abstract Message Syntax

Segment Name Usage Cardinality Comments/Descriptions

MSH Message Header R [1..1] This 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

MSA Message Acknowledgment

R [1..1] The Message Acknowledgment Segment (MSA) contains the information sent as acknowledgment to the result message received by the device or information system.

[{ERR}] Error CE [0..*] This segment is sent if there is an error identified in the message. If MSA-1 (Message Acknowledgment) is not valued as AA or CA.

5.4 Messaging Infrastructure

5.4.1 Message Header—MSH Segment 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.

Table 5-3 MSH Segment and Field Descriptions

Seq Len DT Cardinality Optionality

Value Set

HL7 Element Name

Comments/Descriptions

1 1 ST [1..1] R Field Separator

Character to be used as the field separator for the rest of the message. Literal value: ‘|’ [ASCII (124)].

2 5 ST [1..1] R Encoding Characters

Constrained to the literal values ‘^~\&’ or ‘^~\&#’, always appearing in the same order.



Value Set

HL7 Element Name


3 HD [1..1] R Sending Application

Field that may be used to uniquely identify the sending application for messaging purposes. The use of an OID for this field is recommended.

4 HD [1..1] R Sending Facility

This field uniquely identifies the sending facility associated with the device that will transmit the message on hearing screening results. Acknowledgments are in use, so this facility will receive any related acknowledgment message. The use of an OID for this field is recommended.

5 HD [1..1] R Receiving Application

This field is used to uniquely identify the receiving application that will receive the hearing screening results. The use of an OID for this field is recommended.

6 HD [1..1] R Receiving Facility

This field uniquely identifies the receiving facility, where hearing screening results will be received. The use of an OID for this field is recommended. Acknowledgments are in use, so this facility originates any related acknowledgment message.

7 DTM

[1..1] R Date/Time Of Message

Field containing the date/time the message was created by the sending system. Format: YYYYMMDDHHMMSS[.S[S[S[S]]]]+/-ZZZZ. Note that the time zone offset is required, and the minimum granularity is to the second, although more precise time stamps are allowed. The time zone will be defaulted throughout the message if it is specified in this element.

9 MSG

[1..1] R Message Type

For the result message Literal Value: ‘ORU^R01^ORU_R01’. For the acknowledgement message Literal Value: ‘ACK^R01^ACK’.

10 199 ST [1..1] R Message Control ID

A number or other identifier that uniquely 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. In the Message Acknowledgement Segment, this system sends the Message Control ID back to the sending system.

11 PT [1..1] R Processing ID

Field that may be used to indicate the intent for processing the message, such as "T" (training,) "D" (debugging,) or "P" (production.)

12 VID [1..1] R Version ID HL7 version number used to interpret format and content of the message. For this message, the version ID will always be Literal Value: 2.6

15 2 ID [0..1] R HL70155

Accept Acknowledg

This field points out the conditions under which accept acknowledgements that




Value Set

HL7 Element Name


ment Type should be returned regarding this message. This is a Required field and is constrained to the value AL, Always. For the sender of the acknowledgement it should always be NE.

16 2 ID [0..1] CE HL70155

Application Acknowledgment Type

The conditions under which application acknowledgements are required in response to this message.

17 3 ID [0..1] RE ISO 3166-1

Country Code

The country of origin is included in this field

19 CWE

[0..1] RE Principal Language Of Message

Example MSH Segment:

MSH|^~\&|EHDI Screening

Device^2.16.840.1.113883.4.3.48ÔID|SendingFacility^2.16.840.1.11

3883.4.3.47ÔID|Receiving

Application^2.16.840.1.113883.19.3.22ÔID|PublicHealth^2.16.840.1

.113883.19.3.21ÔID|20120701132554-

0400||ORU^R01ÔRU_R01|20120701132554000005|T|2.6|||AL|AL|USA|

|enÊnglishÎSO639-1|

5.4.2 Patient Identification Segment—PID This segment is used to communicate patient identification information. This segment contains patient identifying information that is usually permanent and is unlikely to change.

Table 5-4 Patient Identification Segment (PID)

Seq Len DT Cardinality

Optionality

Value Set

HL7 Element Name


1 4 SI [1..1] R Set ID – Patient ID

Literal Value: ‘1’.

3 CX [1..*] R Patient Identifier List

This field is used by the healthcare facility to uniquely identify a patient. This may include medical record number, billing number, birth certificate ID, national unique ID. NHSN Cardinality: NHSN currently supports up to 4 patient identifiers.



Optionality

Value Set

HL7 Element Name


5 XPN [1..*] R HL70200 Patient Name This field contains the patient’s name or aliases. When the name of the patient is not known, a value must still be placed in this field since the field is required. In that case, |~^^^^^^U| SHALL be used. The "U" for the name type code in the second name indicates that it is unspecified. Since there may be no name components populated, this means there is no legal name, nor is there an alias. This guide will interpret this sequence to mean there is no patient name. Refer to HL7 table 0200 – Name Type for valid values of the name type code are in HL70200.

6 XPN [0..1] RE Mother’s Maiden Name

This field contains the family name under which the mother was born.

7 DTM [0..1] R Date/Time of Birth

Patient’s date and time of birth. The time zone component is required. Format: YYYYMMDDHHMM[SS[.S[S[S[S]]]]]+/-ZZZZ [Note: If a birth date is not provided in the PID, then the patient age at specimen collecting must be reported as an observation associated with the Observation Request (OBR) for the newborn hearing screen panel.]

8 20 IS [0..1] RE HL70001 Administrative Sex

Patient’s sex

10 CWE [0..*] RE HL70005 Race This field refers to the patient’s race.

11 XAD [0..*] RE Patient Address The mailing address of the patient

13 XTN [0..*] RE Phone Number – Home

Patient’s Phone number

15 CWE [0..*] O PHVS_Language_ISO_639-2_Alpha3

Primary Language

Need language for communication with the patient (i.e., phone, email, letter, etc.)

18 CX [0..1] O Patient Account Number

Used to identify the patient’s account.

21 CX [0..*] O Mother’s Identifier

Typically a patient ID or an account number may be used and can contain multiple identifiers for the same mother. This can help serve as a link field for newborns.

22 CWE [0..1] RE HL70189 Ethnic Group This field further defines patient ancestry. The user MAY use table HL70189. Other value sets including the Australian Institute of Health and Welfare METeOR identifier 291036 MAY be used.




Optionality

Value Set

HL7 Element Name


23 250 ST [0..1] RE Birth Place Location of patient’s birth, i.e. hospital name. The address is in PID-11.

24 1 ID [0..1] O HL70136 Multiple Birth Indicator

This field indicates if a patient was part of a multiple birth.

25 2 NM [0..1] O Birth Order A number that indicates the patient’s birth order when they were part of a multiple birth.

33 DTM [0..1] RE Last Update Date/Time

Note: Used to indicate when demographics were last updated. Format: YYYYMMDDHHMM[SS[.S[S[S[S]]]]]+/-ZZZZ

34 HD [0..1] CE Last Update Facility

This is the facility that originated the demographic update. Condition Predicate: If PID-33, “Last Update Date/Time”, is valued, this field SHALL be populated. If PID-33 is empty, this field will not be populated.

Example PID Segment:

PID|1||MRN123||Jones^BabyGirl|James|201201300005-0600|F||2106-

3^White^HL70005~1002-5Âmerican Indian or Alaska

Native^HL70005|201

Street^Ârlington^TX^99999ÛSA||^PRN^PH^^011^555^555-

5555||engÊnglishÎSO6392|||98766|||1234555|N^Not Hispanic or

Latino^HL70189|HospitalABC|N|1|

5.4.3 Patient Visit Segment—PV1 The PV1 segment is used to communicate information on a visit-specific basis. For EHDI, this is important to indicate if the screening was done as an in-patient, or birth screen, or as an outpatient, follow-up screen.

Table 5-5 Patient Visit Segment (PV1)


Value Set

HL7 Element Name


2 1 IS [1..1] R HL70004

Patient Class

This field is used by systems to categorize patients by site. In this message, this field SHALL be used to categorize the patient as an Inpatient or Outpatient.


3 80 PL [0..1] RE HL70302

Assigned Patient location

This field contains the patient’s initial location or where the patient is being moved. If a patient is in the Neonatal Intensive Care Unit (NICU) or Special Care Nursery (SCN) this may impact when their hearing screening is performed or how the result is interpreted.

7 60 XCN

[0..1] RE Attending Doctor

This field contains the attending physician information. It is recommended to use a NPI to identify the Attending Doctor.

Example PV1 Segment:

PV1||I|427695007||||1001001^Smith^Theodore^^^Dr^^^^^^^NPI|

5.4.4 NK1 Segment – Next of Kin Segment The NK1 segment is used to communicate information on the patient’s Next of Kin, or associated parties, most commonly the parent or guardian in newborn screening. For EHDI, this is important if follow-up care or risk monitoring is necessary as a result of the screening.

Table 5-6 Next of Kin Segment


Optionality

Value Set

HL7 Element Name


1 4 SI [1..1] R Set ID – NK1 This field contains the number that identifies the transaction. For the first occurrence of the segment, the sequence number shall be one, for the second occurrence, the sequence number shall be two, etc.

2 250 XPN [0..*] RE HL0200

Name This is the name of the next of kin/associated party. Multiple names for the same person are allowed.

3 705 CWE [0..1] RE HL70063

Relationship This field contains the actual personal relationship that the next of kin/associated party has to the patient. This table has been constrained in this IG.

4 250 XAD [0..*] RE Address This field contains the address of the next of kin/associated party. Multiple addresses are allowed.

5 250 XTN [0..*] RE Phone Number

This field contains the telephone number of the next of kin/associated party. Multiple phone numbers are allowed.

Sample NK1 Segment:

NK1|1|Jones^Mary^James|MTH^Mother^HL70063|201

Street^^Arlington^TX^99999^USA |^PRN^PH^^011^555^555-5555|



5.5 OBR Segments – Observation Request Segments In the reporting of hearing screening data there are three possible observation request (OBR) segments that are used to capture information about the hearing screening panel performed. The first OBR will report the newborn hearing loss panel. This SHALL be followed by an OBR for the newborn hearing loss panel of the right ear and an OBR for the newborn hearing panel of the left ear.

5.5.1 OBR for the Newborn Hearing Screening Panel In the reporting of hearing screening data, one OBR is used to report the newborn hearing screening panel. This contains observations relevant to the hearing screening and It MAY be followed by supporting OBX segments that include details on any comments or discussion and/or the hearing loss risk indicators (risk factors). This OBR serves as the report header for the newborn hearing screening panel.

5.5.2 OBRs for Newborn Hearing Screen Panel of Ear – Right and Newborn Hearing Screen Panel of Ear - Left

There are two additional OBRs that support the Newborn Hearing Screening Panel; newborn hearing screen panel of ear - right and newborn hearing screen panel of ear - left. These OBRs SHALL be reported for each ear and MAY contain information about the ordering provider and the collector. The OBR for newborn hearing screen panel – right ear and the OBR for newborn hearing screen panel- left ear SHALL be supported by at least one OBX segment that indicates the result of the hearing screen. If a screen is not performed, this result MUST be recorded in the OBX segment. Other data elements relevant to hearing screening recorded in the OBX segment include details on the hearing screening technique, equipment, and screener.

Table 5-7 Observation Request Segments (OBR) for the EHDI ORU^R01 message

Note: the three OBRs have similar structure. The information in OBR-4 identifies whether it is the OBR for the Newborn Hearing

Screening panel, the Newborn Hearing Screen panel of Ear – Right or the Newborn Hearing Screen panel of Ear – left.

Seq Len DT Cardinality Optionality Value Set

HL7 Element Name


1 4 SI [1..1] R Set ID – OBR

For the first order to transmitted, the sequence shall contain the literal value of 1; for the second order it shall be 2; and so on.

2 EI [1..1] R Placer Order Number

A permanent identifier for an order and its associated observations. It is assigned by the by the organization or application requesting the test. The Placer Order number is required.

3 EI [1..1] R Filler Order Number

A permanent identifier for an order and its associated observations. It is assigned by the by the organization or application performing the test. The Filler Order number is required.



HL7 Element Name


4 CWE [1..1] R 54111-0,

73744-5 and 73741-

1

Universal Service Identifier

There may be three OBRs in this message. One OBR is for the newborn hearing screen panel. This will contain the identifier code for the newborn hearing screen panel as a LOINC code, 54111-0. The alternate code to use is a SNOMED-CT code: 417491009, Neonatal Hearing Test procedure There SHALL two other OBRs: One for the newborn hearing screen panel of the right ear and the other for the newborn hearing screen panel of the left ear. These will be identified by their respective LOINC codes 73744-5 and 73741-1.

7 DTM [1..1] RE Observation Date/Time

The date and time of hearing screening performed. A minimum of year, month, day, and time zone must be provided when the actual date/time is known. For unknown collection date/time use "0000". HL7 requires this field in an OBR in a result message. Format: YYYYMMDDHHMM[SS[.S[S[S[S]]]]]+/-ZZZZ except when reporting an unknown date of ‘0000”.

10 XCN [0..*] RE Collector Identifier

This field will identify the person, department or facility that performed the hearing screening, the hearing screener. Either the name or ID code, or both, may be present.

16 XCN [0..*] RE Ordering Provider

Identifier of the provider who ordered the screening being performed. The National Provider Identifier (NPI) is recommended as the identifier.

17 XTN [0..2] RE Order Callback Phone Number

This is the number that can be used for questions regarding the order. This should be a phone number associated with the original order placer.

22 DTM

[1..1] R Results Rpt/Status Chng - Date/Time

Required field in this message. Applies to the entire report. Receipt of a subsequent message with the same Filler Number and a different status in this field implies that processing may need to occur at the receiving application level to update a previous report. Format: YYYYMMDDHHMM[SS[.S[S[S[S]]]]]+/-ZZZZ For EHDI, this may be possible if a status has changed and the result is resent or if changes from zero result to 1 result. Most of the time this will be




HL7 Element Name


the same as the observation date and time. Time zone offset is required.

25 1 ID [1..1] R Table 0123

Result Status Value Set

Result Status

The status of results for this order. C should be used for a Correction to results. F should indicate the Final results; results stored and verified and can only be changed with a corrected result. I should be used to indicate No results are available, if the procedure was incomplete.

28 XCN [0..*] RE Result Copies To

The people who are to receive copies of the results.

Example OBR of Newborn Hearing Screening Panel:

OBR|1|123456^

HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7|54111

0^Newborn hearing loss panel^LN|||201201311234-

0600|||^Screener^Annie^S||||||^Smith^John^S^^Dr.|

^PRN^PH^^011^555^555-1234^333|||||201201311234-

0600|||F|||^Parent^Mama|

Example OBR for Newborn Hearing Screen Panel of Ear - Right:

OBR|2|123456^


-5^Newborn hearing screen panel of ear - right^LN|||201201311234-


^PRN^PH^^011^555^555-1234^333|||||201201311234-


Example of OBR for Newborn Hearing Screen Panel of Ear - Left:

OBR|3|123456^


-1^Newborn hearing screen panel of ear - left^LN|||201201311234-


^PRN^PH^^011^555^555-1234^333|||||201201311234-



5.6 OBX Segments – Observation Result Segments The Observation Result Segment (OBX) contains information regarding a single observation related to a single OBR. The OBR for the newborn hearing screening screen panel, will be supported by optional OBX segments for newborn hearing screen comments or discussion and/or OBX segments for hearing loss risk indicator(s).

The OBR segments for Newborn Hearing Screen panel of ear – right and Newborn Hearing Screen Panel of Ear - left will be supported by OBX segments that include the specific type of observation, the result for the observation, when the observation was made, etc. The newborn hearing screening OBX segments include information on hearing screening technique, equipment, results, reasons, screener and the duration of the screen. For these two OBRS, one OBX is always required. There may be additional OBX segments containing other observations such as percent myogenic, or waveform data that are not specified in this IG. The OBX Universal Service ID values will be drawn from the concept value set that is newborn hearing screening panel.

OBX Segment details are described in Table 5-8. Specific identifiers for each varying OBX segment are described in Table 5.9.

Table 5-8 Observation/Result Segment (OBX)

Seq Len DT

Cardinality

Optionality

Value Set

HL7 Element Name


1 4 SI [1..1] R Set ID – OBX For the first repeat of the OBX segment, the sequence number shall be one (1), for the second repeat, the sequence number shall be two (2), etc.

2 3 ID [1..1] R HL70125 Value Type This field identifies the data type used for OBX-5. See HL7 Table 0125 for the data types that will be supported for this field and OBX-5.

3 CWE

[1..1] R Var Observation Identifier

Unique identifier for the observation for the type of observation. This field provides a code for the type of observation. OBX-3 in conjunction with OBX-4 Observation Sub-ID should uniquely identify this OBX from all other OBXs associated with this OBR. LOINC is used as the coding system for this field.

4 20 ST [0..1] CE Observation Sub-ID

This field is used to distinguish between multiple OBX segments with the same observation ID organized under 1 OBR. Required if there is more than one OBX with the same OBX-3 Observation Identifier associated with the same OBR. This should be used with group observations.

5 Var

[0..*] RE Observation Value

This field contains the value observed by the observation producer. This field document



Seq Len DT

Cardinality

Optionality

Value Set

HL7 Element Name


each specific allowed data type. For coded observation values use the Coded Value set in Table 5-9. May repeat for multi-part, single answer results with appropriate data types.

6 CWE

[0..1] RE Unified Code for Units of Measure (UCUM)

Units UCUM® is an HL7-approved code system and shall be used for units of measure. {} should be used if the measure is unitless.

7 60 ST [0..1] RE Reference Ranges

Interpretation range that applies to the value reported in OBX-5. It should provide enough information to understand the abnormal flags reported in OBX-8. In newborn hearing screening - It is not appropriate to send the reference range for a result in an associated NTE segment.

8 20 IS [0..*] RE HL70078 Abnormal Flags

Indicator of the normalcy of the result found in OBX-5. Null should be used if there is no reference range.

11 1 ID [1..1] R HL70085 Observation Result Status

This field contains the observation result status. F should be used for the final results. C indicates a Correction to Results. P indicates Preliminary Results.

14 DTM

[0..1] RE Date/Time of the Observation

The date/time of observation is intended to carry the clinically relevant time of the observation. For observations carried out directly on a patient for instance, such as a hearing screening, the time the observation was performed also happens to be the clinically relevant time of the observation. The date/time the testing was performed should be reported in OBX-19 Format: YYYYMMDDHHMM[SS[.S[S[S[S]]]]]+/-ZZZZ except when reporting an unknown date of ‘0000”. Time zone offset is required.

17 CWE

[0..*] RE LA10387-1 LA10388-9 LA10389-7 LA10390-5 LA10391-3 LA12406-7

Observation Method

This field can be used to transmit the procedure by which an observation was obtained by the sending system. In hearing screening, this would be the physiological technique. For this OBX field, it should be drawn from the LOINC Value Set


Seq Len DT

Cardinality

Optionality

Value Set

HL7 Element Name


54106-0, EHDI Newborn Hearing Screening Method. The possible values are AABR, ABR, OAE, DPOAE, TOAE, and methodology unknown.

18 EI [0..*] RE Local Equipment Instance Identifier

This field contains the equipment instance responsible for the production of the observation. In hearing screening the relevant fields to report on a piece of equipment are: Brand, model, version, instance data, serial number, local name

19 DTM

[0..1] RE Date/Time of the Analysis

Time at which the hearing screening was performed. This field is used to transfer the time stamp associated with generation of the analytical result by the instrument specified in Equipment Instance Identifier. For automated analytics this is expected to match the Date and Time of OBX -14.

20 CWE

[0..1] RE Right ear SCT 368570004 Left ear SCT 368592000

Observation Site

This is the body site where the measurement being reported was obtained. This can be either the Right Ear or the Left ear. This is a SNOMED-CT Code.

23 XON

[1..1] R Performing Organization Name

This field contains the name of the organization responsible for performing the hearing screening. For hearing screening, this field specifies the hospital/clinic/provider where the hearing screening was conducted.

24 XAD

[0..1] RE Performing Organization Address

This field contains the address of organization/service responsible for performing the hearing screening.

25 XCN

[0..1] RE Performing Organization Medical Director

Name of the Medical Director of the hearing screening program.

5.6.1 Observation Result Segment (OBX) for Hearing Loss Comments or Discussion Hearing Screening devices may store comments or discussion on the newborn hearing screen conducted. That information should be included in an OBX segment supporting the Newborn Hearing Loss Panel OBR. This OBX can be used to communicate information on any comments or discussion that may be related to the hearing screening. For example, if the room was noisy or the baby may have atresia, these comments may be included in the device and included in the message transmission to public health or an EHR.



Example OBX Segment:

OBX|1|TX|57700-7^Hearing loss newborn screening

comment/discussion^LN|1|baby sleeping||||||F|||201201311234-

0600||||Maico~EroScan|201201311234-0600||||Hospital|123

Street^Suite

A^Dallas^TX^71211|1001001^Smith^Theodore^^^Dr^^^^^^^NPI|

5.6.2 Observation Result Segment (OBX) for Risk Factors of Hearing Loss Hearing screening devices may store information on risk factors or indicators of hearing loss. Details on the risk factors should be included in an OBX segment(s) supporting the Newborn Hearing Loss Panel OBR. The OBX segments can be used to communicate information on any risk factors for hearing loss the patient may have. For example, the baby was in the NICU for more than 5 days, this is a risk factor that may be of interest to public health. There may be one or many OBX segments for risk factors. SNOMED-CT codes are the preferred codes for these OBX segments. See Table on Risk Factors in Chapter 6 for details.

Example Hearing Loss Risk Indicator Segments:

OBX|2|CWE|58232-0^Hearing loss risk indicators^LN|1|266700009^ Assisted

breathing (procedure)^SCT|||A|||F|||201201311234-0600||||

Maico~EroScan|201201311234-0600||||Hospital|123 Street^Suite


OBX|3|CWE|58232-0^Hearing loss risk indicators^LN|2|439750006^Family

history of hearing loss(situation)^SCT|||A|||F|||201201311234-

0600|||| Maico~EroScan|201201311234-0600||||Hospital|123

Street^Suite


5.6.3 OBX Segments supporting the Newborn Hearing Screen Panel of Ear - Right OBR and the Newborn Hearing Screen Panel of Ear - Left OBR

In this IG, there is an OBR for the newborn hearing screen panel of the right ear and the newborn hearing screen panel of the left ear. Each panel MAY be supported by 3 OBX segments. The OBX segments addressed in this IG are:

• Newborn hearing screen of ear - right and newborn hearing screen of ear - left • Duration of screening right ear and Duration of screening left ear • Reason not done right ear and reason not done left ear

There may be additional OBX segments containing other observations such as stimulus parameters used in the screen or waveform data.

5.6.4 OBX Segments: Newborn Hearing screen right and Newborn Hearing Screen Left When a screening has been performed or attempted or not performed, then a result should be communicated in the OBX segment. There should be OBX segment or the result for the newborn hearing


screen – right and newborn hearing screen – left, and the method used in the screen should be contained in OBX-17.

Examples of OBX segments for Newborn hearing screen of ear – right and Newborn hearing screen of ear - left:

OBX|1|CWE|54109-4^Newborn hearing screen of ear–

right^LN|1|164059009^Pass^SCT|||N|||F|||201201311235-

0600|||LA10389-7ÔAE^LN|MaicoÊroScan|201201311235-

0600|368570004^Right ear^SCT|||Hospital|123 Street^Suite


OBX|2|CWE|54108-6^Newborn hearing screen of ear – left

^LN|1|183924009^Refer^SCT|||A|||F|||201201311235-0600||| LA10389-

7ÔAE^LN|MaicoÊroScan|201201311235-0600|368592000^Left

ear^SCT|||Hospital|123 Street^Suite


5.6.5 OBX Segments: Duration of screening of ear – right and Duration of screening of ear - left If a screening has been performed or attempted, then the duration of the test MAY be communicated in the OBX segment. Some devices capture duration measurements and this OBX is intended to support the communication of that data element. There can be a duration OBX for each screening performed.

Examples of OBX segments for Duration of screening right ear and Duration of screening left ear:

OBX|1|NM|73740-3^Duration of screening right

ear^LN|1|2|min^minute||N|||F|||201201311235-0600|||LA10389-

7ÔAE^LN|MaicoÊroScan|201201311235-0600|368570004^Right



OBX|2|NM|73743-7^Duration of screening left ear

^LN|1|2|min^minute||N|||F|||201201311235-0600||| LA10389-




5.6.6 OBX Segments: Reason Screen Not Done right ear and Reason Screen Not Done left ear If a hearing screening was not performed that information needs to be shared with public health or the EHR. Reasons can include parental refusal, the screening was attempted but unsuccessful, it was not performed, or it was not performed because of a medical exclusion. The Reason the screen was not done OBX Segment is Required when OBX-5 of the Newborn hearing Screen Right OBX and/or Newborn Hearing Screen Left OBX is Not Performed ; 262008008 SNOMED-CT



Examples of OBX segments for Reason screen not done right ear and Reason screen not done left ear:

OBX|1|CWE|73742-9^Newborn hearing screen reason not performed –

right^LN|1|103709008^Attempted but unsuccessful – technical

fail^SCT|||N|||F|||201201311235-0600|||LA10389-



A^Dallas^TX^71211|1001001^Smith^Theodore^^^Dr^^^^^^^NPI |


left^LN|1|103709008^Attempted but unsuccessful – technical fail

^SCT|||A|||F|||201201311235-0600||| LA10389-




Table 5-9. OBX Identifiers Table

Hearing Screening Supporting OBX Segments

OBX 2 - Value Type

OBX 3 0bservation Identifier

OBX 5 - Observation Value Code Description OBX 6 Units

OBX 7 Reference Range

OBX 8 Abnormal Flags

Hearing Loss Comments and Discussion

TX 57700-7 this is text of any comments or discussion

This records any comments or discussion related to the hearing screening

{} should be used if the measure is unitless.

May be populated

May be populated with codes from HL7 Table 0078

Evidence of Hearing Loss Risk Indicators

CWE 58232-0 Coded observation. SNOMED CT codes (Value Set: 1.3.6.1.4.1.19376.1.7.3.1.1.15.2.11 and 1.3.6.1.4.1.19376.1.7.3.1.1.15.2.12) for hearing loss risk factors shall be used when a code exists, otherwise use a LOINC Answer Code (Value Set 58232-0).

Field that documents the specific hearing loss indicator. It is recommended that SNOMED-CT codes be used to report the observation of a risk factor of hearing loss.


May be populated




OBX 2 - Value Type





Newborn hearing screen of Ear - right

CWE 54109-4 Evidence of Hearing Screening Performed Value Set

The OBX segments with the hearing screening result provides coded result values for pass, refer and not performed. The coded values shown are drawn from the value sets for Evidence of Hearing Screening Performed, Pass, Refer and Not Performed. There should be separate OBX segments for each result for the Right Ear and each result for the left ear. SNOMED-CT codes should be used to document the result of the hearing screening. Please see Chapter 6 for the SNOMED-CT codes for pass, refer, and not performed. If the OBX-5 value is not performed, an OBX segment for the reason screen not performed is required.


May be populated


Newborn Hearing Screening Left

CWE 54108-6 Evidence of Hearing Screening Performed Value Set

The OBX segments with the hearing screening result provides coded result values for pass, refer and not performed. The coded values shown are drawn from the value sets for Evidence of Hearing Screening Performed, Pass, Refer and Not Performed. There should be separate OBX segments for each result for the Right Ear and each result for the left ear. SNOMED-CT codes should be used to document the result of the hearing screening. Please see Chapter 6 for the SNOMED-CT codes for pass, refer, and not performed. If the OBX-5 value is not performed, an OBX segment for the reason screen not performed is required.


May be populated


Duration of Screening Right Ear

NM 73740-3 Unit of Time The observation value is the length of time recorded for the duration of the screen. It is a numeric value.

UCUM units

Duration of Screening Left Ear

NM 73743-7 Unit of Time The observation value is the length of time recorded for the duration of the screen. It is a numeric value.

UCUM units

May be populated


Newborn hearing screen reason not performed - right

CWE 73742-9 Screening Result not Performed Value Set

The observation value is the reason the screen was not done. This is a Required OBX segment when the screen is not performed. The Screening Result not Performed Value Set Shall be used. Please see Chapter 6 for the SNOMED-CT codes.


May be populated





OBX 2 - Value Type





Newborn hearing screen reason not performed left

CWE 73739-5 Screening Result not Performed Value Set

The observation value is the reason the screen was not done. This is a Required OBX segment when the screen is not performed. The Screening Result not Performed Value Set Shall be used. Please see Chapter 6 for the SNOMED-CT codes.


May be populated


5.6.7 MSA Segment This segment contains information sent while acknowledging another message.

Table 5-10 MSA Segment

Seq Len

DT

Cardinality Optionality

Value Set

HL7 Element Name


1 2 ID [1..1] R HL70008

Acknowledgment Code

This field contains an acknowledgement code. (Refer to HL7 Table 0008 - Acknowledgment Code for valid values.)

2 199 ST [1..1] R Message Control ID

Identifier that enables the sending system to associate this response with the message for which it is intended. This value will be the MSH.10 message control ID from the message being acknowledged.

5.7 Error Segment—ERR The ERR segment is used to add error comments to acknowledgment messages.

Table 5-11 Error Segment (ERR)


Value Set HL7 Element Name


2 ERL [0..*] RE Error Location Identifies the location of the error in the message.

3 CWE

[1..1] R HL70357 HL7 Error Code Identifies the HL7 (communications) error code.

4 1 ID [1..*] R HL70516 Severity Identifies the severity of an application error. Knowing if something is Error, Warning, or Information is intrinsic to how an application handles the content.



Value Set HL7 Element Name


7 2048 TX [0..1] RE Diagnostic Information

Information that may be used by help desk or other support personnel to diagnose a problem.

8 250 TX [0..1] RE User Message

12 XTN [0..*] RE Help Desk Contact Point

Code Tables


6 Code Tables The section shows the various Values Set/Codes used in this implementation guide. And provides values for those HL7 tables that are constrained by this IG. HL7 tables in this guide are as specified in the HL7 Version 2.6.1 Standard.

6.1 MSH Table

Table 6—1 HL7 Table 0155 - Accept/Application Acknowledgment Conditions Value – MSH 15 and MSH 16

Value Description

AL Always

NE Never

6.2 PID Tables

Table 6—2 HL7 Table 0200 - Name Type – PID 5

Value Description

A Alias Name

B Name at Birth

C Adopted Name

L Legal Name

U Unspecified

Table 6—3 User-defined Table 0001 - Administrative Sex - PID 8

Value Description

F Female

M Male

O Other

U Unknown

A Ambiguous

N Not applicable

Table 6—4 User-defined Table 0005 – Race PID 10

Value Description

1002-5 American Indian or Alaska Native


Value Description

2028-9 Asian

2054-5 Black or African American

2076-8 Native Hawaiian or Other Pacific Islander

2106-3 White

2131-1 Other Race

Table 6—5 User-defined Table 0189 - Ethnic Group PID 22

Value Description

H Hispanic or Latino

N Not Hispanic or Latino

U Unknown

Table 6—6 Multiple Birth Indicator PID 24

Value Description

Y the patient was part of a multiple birth

N the patient was a single birth

6.3 NK1 Table

Table 6—7 User-defined Table 0063 – Relationship

Value Description WRD Ward of court PAR Parent MTH Mother FTH Father CGV Care giver GRD Guardian GRP Grandparent EXF Extended family SIB Sibling BRO Brother SIS Sister FND Friend OAD Other adult EMC Emergency contact NON None UNK Unknown OTH Other

Code Tables


6.4 PV1 Tables

Table 6—8 HL7 Table 0004 - Pat i ent Locat ion

Value Description

I Inpatient

O Outpatient

Table 6—9 HL7 Table 0302 - Assigned Patient Location PV1-3

Values Description Code System

427695007 Newborn Nursery Unit (synonym: Well baby unit) SNOMED-CT

405269005 Neonatal intensive care unit SNOMED-CT

309946005 Special care baby unit SNOMED-CT

309910001 Pediatric intensive care unit SNOMED-CT

309945009 Pediatric department SNOMED-CT

420223003 Pediatric medicine department SNOMED-CT

309991001 Pediatric surgical department SNOMED-CT

398145002 Unspecified location within hospital premises SNOMED-CT

91154008 Free-standing birthing center SNOMED-CT

52668009 Hospital-based birthing center SNOMED-CT

Table 6—10 HL7 Table 0203 – Identifier Type Code PV1-7 for the XCN data type

Values

Description

Comment

AMA American Medical Association Number

A physician identifier assigned by the AMA.

AN Account number

An identifier that is unique to an account.

ANON Anonymous identifier

An identifier for a living subject whose real identity is protected or suppressed

APRN Advanced Practice Registered Nurse number

An identifier that is unique to an advanced practice registered nurse within the jurisdiction of a certifying board

BCT Birth Certificate

A number associated with a document identifying the event of a person’s birth.

BR Birth registry number

An identifier unique within the Assigning Authority that is the official legal record of a person's birth.

DL Driver’s license number


Values

Description

Comment

DN Doctor number

DO Osteopathic License number

An identifier that is unique to an osteopath within the jurisdiction of a licensing board.

ESN Staff Enterprise Number

An identifier that is unique to a staff member within an enterprise (as identified by the Assigning Authority).

FI Facility ID

LN License number

LR Local Registry ID

MD Medical License Number

An identifier that is unique to a medical doctor within the jurisdication of a licensing board.

MR Medical record number

An identifier that is unique to a patient within a set of medical records, not necessarily unique within an application.

MRT Temporary Medical Record Number

Temporary version of a Medical Record Number

NE National employer identifier

In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions.

NP Nurse practitioner number

An identifier that is unique to a nurse practitioner within the jurisdiction of a certifying board.

NPI National provider identifier

In the US, the Assigning Authority for this value is typically CMS, but it may be used by all providers and insurance companies in HIPAA related transactions.

PA Physician Assistant number

An identifier that is unique to a physician assistant within the jurisdiction of a licensing board

PI Patient internal identifier

A number that is unique to a patient within an Assigning Authority.

PN Person number

A number that is unique to a living subject within an Assigning Authority.

PRN Provider number

A number that is unique to an individual provider, a provider group or an organization within an Assigning Authority. Use case: This allows PRN to represent either an individual (a nurse) or a group/organization (orthopedic surgery team).

SL State license

SR State registry ID

U Unspecified identifier

Code Tables


6.5 OBR Tables

Table 6—11 Hearing Screen Value Set OBR-4


54111-0 Newborn Hearing Loss Panel LOINC

73741-1 Newborn Hearing Screen Panel of Ear - Left LOINC

73744-5 Newborn Hearing Screen Panel of Ear – Right LOINC

Table 6—12 Hearing Screen Value Set SNOMED-CT Code OBR-4


417491009 Neonatal Hearing test (procedure) SNOMED-CT

Table 6—13 HL7 Table 0123 - Result Status OBR 25

Value Description

I No results available; specimen received, procedure incomplete

C Correction to results

F Final results; results stored and verified. Can only be changed with a corrected result.

6.6 OBX Tables

Table 6—14 FOR OBX 2 HL7 Table 0125 - Value type

Value Description

CWE Coded with Exceptions

CX Extended Composite ID with Check Digit

DTM Date/Time

EI Entity Identifier

ERL Error Location

FN Family Name

HD Hierarchic Designator

ID Coded Values for HL7 Tables

IS Coded value for User-Defined Tables

MSG Message Type

NM Numeric

PL Person Location

PT Processing Type


Value Description

SAD Street Address

SI Sequence ID

ST String

TX Text Data

Var Variable

VID Version Identifier

XAD Extended Address

XCN Extended Composite ID Number and Name

XON Extended Composite Name and ID Number for Organizations

XPN Extended Person Name

XTN Extended telecommunications number

Table 6—15 Hearing Loss newborn screening comment/discussion OBX-3


57700-7 Hearing Loss newborn screening comment/discussion LOINC

Table 6—16 Hearing Loss Risk Indicators OBX-3


58232-0 Hearing Loss Risk Indicator LOINC

Table 6—17 Newborn Hearing Screen of Ear – Right and Left OBX-3


54108-6 Newborn hearing screen of Ear – left LOINC

54109-4 Newborn hearing screen of Ear – right LOINC

Table 6—18 Duration of screening of Ear – Right and Left OBX-3


73740-3 Duration of screening of Ear – left LOINC

73743-7 Duration of screening of Ear – right LOINC

Code Tables


Table 6—19 Newborn hearing screen reason not performed of ear – right and left OBX-3


73739-5 Newborn hearing screen reason not performed of ear – left LOINC

73742-9 Newborn hearing screen reason not performed of ear – right LOINC

Table 6—20 Evidence of Hearing Loss Risk Indicators CODES OBX-5

LOINC Description – Value Set: 58232-0

LOINC Value SNOMED-CT Description Value Sets: 1.3.6.1.4.1.19376.1.7.3.1.1.15.2.12 and 1.3.6.1.4.1.19376.1.7.3.1.1.15.2.11

SNOMED-CT Value

None LA137-2

Caregiver concern about hearing LA12667-4

Family Hx of Hearing loss LA12668-2

Family history of hearing loss (situation) 439750006

ICU stay > 5 days LA12669-0

ECMO LA12670-8

Extracorporeal membrane oxygenation (procedure) 233573008

Assisted ventilation LA12671-6 Assisted breathing (procedure) 266700009

Ototoxic medication use LA12672-4 History of therapy with ototoxic medication (situation) 441899004

Exchange transfusion for Hyperbilirubinemia LA12673-2

Neonatal exchange transfusion 180202002

In utero infection(s) LA12674-0 Intra-amniotic infection of fetus 11618000

Craniofacial anomalies LA12675-7 Congenital abnormality of skull and face bones 268239009

Physical findings of syndromes that include hearing loss LA12681-5

Syndromes associated with hearing loss LA12676-5

Neurodegenerative disorders LA12677-3

Degenerative disease of the central nervous system (disorder) 80690008

Postnatal infections LA12678-1 Postnatal infection (disorder) 178280004

Head Trauma LA12679-9 Neonatal extracranial head trauma (disorder) 312972009

Chemotherapy LA6172-6 History of - chemotherapy (situation) 161653008

Infections specific to perinatal period (disorder) 206331005

Fetus or neonate affected by 206005002


LOINC Description – Value Set: 58232-0

LOINC Value SNOMED-CT Description Value Sets: 1.3.6.1.4.1.19376.1.7.3.1.1.15.2.12 and 1.3.6.1.4.1.19376.1.7.3.1.1.15.2.11

SNOMED-CT Value

maternal infection (disorder)

Conjugated hyperbilirubinemia in infancy (disorder) 276687002

Neonatal hyperbilirubinemia (disorder) 281610001

Neonatal conjugated hyperbilirubinemia (disorder) 281612009

Neonatal unconjugated hyperbilirubinemia (disorder) 281611002

Table 6-21 Evidence of Hearing Screening Performed Value Set OBX 5

Value Description Code System

164059009 Pass SNOMED-CT

183924009 Refer SNOMED-CT

262008008 Not Performed SNOMED-CT

Table 6—22 Screening Result not Performed Value Set SNOMED-CT OBX 5

Value Description Code System

103709008 Attempted, but unsuccessful - technical fail SNOMED-CT

410534003 Not performed, medical exclusion - not indicated SNOMED-CT

183949008 Assessment examination refused (situation) SNOMED-CT

183945002 Procedure refused - religion (situation) SNOMED-CT

183948000 Refused procedure - parent's wish (situation) SNOMED-CT

397709008 Patient died (finding) SNOMED-CT

Table 6—23 Newborn Hearing Screening Observation Method Value Set OBX 17

LOINC Value Set 54106-0

EHDI Newborn Hearing Screening Method

Code System

EHDI Newborn Hearing Screening method

LA10387-1 AABR LOINC Automated auditory brainstem response

LA10388-9 ABR LOINC Auditory brain stem response

LA10389-7 OAE LOINC Otoacoustic emissions

LA10390-5 DPOAE LOINC Distortion product otoacoustic emissions

LA10391-3 TOAE LOINC Transient otoacoustic emissions

LA12406-7 LOINC Methodology unknown

Code Tables


Table 6—24 Units of Time – OBX 6

Value Description

Year Yr

Month Mo

Week Wk

Day D

Hour Hr

minute Min

Second Sec

Table 6—25 Defined Table 0078 - Abnormal flags OBX 8

Value Description

N Normal (applies to non-numeric results)

A Abnormal (applies to non-numeric results)

Null No range defined, or normal ranges don't apply

Table 6—26 OBX 11 - HL7 Table 0085 - Observation result status codes interpretation OBX 11

Value Description

C Record coming over is a correction and thus replaces a final result

F Final results; Can only be changed with a corrected result.

P Preliminary results

Table 6—27 Observation Site for Hearing Screening: OBX 20

Value Description Code System 368570004 Right Ear SNOMED-CT

368592000 Left Ear SNOMED-CT

Table 6—28 HL7 Table 0008 - Acknowledgment Code MSA-1

Value Description

AA Original mode: Application Accept - Enhanced mode: Application acknowledgment: Accept

AE Original mode: Application Error - Enhanced mode: Application acknowledgment: Error

AR Original mode: Application Reject - Enhanced mode: Application acknowledgment: Reject

CA Enhanced mode: Accept acknowledgment: Commit Accept

CE Enhanced mode: Accept acknowledgment: Commit Error

CR Enhanced mode: Accept acknowledgment: Commit Reject


Table 6—29 HL7 Table 0357– Message Error Condition Codes ERR-3

Value Description Comment

0 Message accepted

Success. Optional, as the AA conveys success. Used for systems that must always return a status code.

100 Segment sequence error

Error: The message segments were not in the proper order, or required segments are missing.

101 Required field missing

Error: A required field is missing from a segment

102 Data type error Error: The field contained data of the wrong data type, e.g., an NM field contained "FOO".

103 Table value not found

Error: A field of data type ID or IS was compared against the corresponding table, and no match was found.

200 Unsupported message type

Rejection: The Message Type is not supported.

201 Unsupported event code

Rejection: The Event Code is not supported.

202 Unsupported processing id

Rejection: The Processing ID is not supported.

203 Unsupported version id

Rejection: The Version ID is not supported.

204 Unknown key identifier

Rejection: The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g., transfer of a non-existent patient.

205 Duplicate key identifier

Rejection: The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).

206 Application record locked

Rejection: The transaction could not be performed at the application storage level, e.g., database locked.

207 Application internal error

Rejection: A catchall for internal errors not explicitly covered by other codes.

Table 6—30 HL7 Table 0516 – Error Severity ERR-4

Value Description Comment

W Warning Transaction successful, but there may issues

I Information Transaction was successful but includes information e.g., inform patient

E Error Transaction was unsuccessful

F Fatal Error Message not processed due to application or network failure condition

Appendix A – Sample Messages


7 Appendix A – Sample Messages A sample message is included as reference. Please refer to HL7 V 2.6 ORU^R01 for details on the fields.

Examples should not be construed as authoritative and the details in this guide should be followed. If the examples do not conform to the guide, the guide should be considered authoritative.

Sample Message with Risk Factors


Device^2.16.840.1.113883.4.3.48ÔID|SendingFacility^2.16.840.1.113883.4.3.47ÔID|R

eceiving

Application^2.16.840.1.113883.19.3.22ÔID|PublicHealth^2.16.840.1.113883.19.3.21ÔI

D|20120701132554-



PID|1||MRN123||Jones^BabyGirl|James|201201300005-0600|F||2106-3^White^HL70005~1002-

5Âmerican Indian or Alaska Native^HL70005|201




PV1||I|427695007||||1001001^Smith^Theodore^^^Dr^^ÔPH^^^^NPI|

NK1|1|Jones^Mary^James|MTH^Mother^HL70063|201 Street^Ârlington^TX^99999ÛSA

|^PRN^PH^^011^555^555-5555|

OBR|1|123456^ HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7|54111


0600|||^ScreenerÂnnie^S||||||^Smith^John^S^^Dr.| ^PRN^PH^^011^555^555-

1234^333|||||201201311234-0600|||F|||^Parent^Mama|

OBX|1|TX|57700-7^Hearing loss newborn screening comment/discussion^LN|1|baby

sleeping||||||F|||201201311234-0600||||Maico~EroScan|201201311234-

0600||||Hospital|123 Street^Suite

A^Dallas^TX^71211|1001001^Smith^Theodore^^^Dr^^ÔPH^^^^NPI|

OBX|2|CWE|58232-0^Hearing loss risk indicators^LN|1|266700009^ Assisted breathing

procedure^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-




OBX|3|CWE|58232-0^Hearing loss risk indicators^LN|2|LA12669-0^ICU stay > 5

days^LN|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|4|CWE|58232-0^Hearing loss risk indicators^LN|3|LA12667-4^Caregiver concern about

hearing^LN|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|5|CWE|58232-0^Hearing loss risk indicators^LN|4|439750006^Family history of hearing Loss

(situation)^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|6|CWE|58232-0^Hearing loss risk indicators^LN|5|233573008^ Extracorporeal membrane

oxygenation (procedure)^SCT|||A|||F|||201201311234-0600||||



OBX|7|CWE|58232-0^Hearing loss risk indicators^LN|6|441899004^ History of therapy with

ototoxic medication (situation)^SCT|||A|||F|||201201311234-0600||||



OBX|8|CWE|58232-0^Hearing loss risk indicators^LN|7|276687002^ Conjugated

hyperbilirubinemia in infancy (disorder)^SCT|||A|||F|||201201311234-0600||||



OBX|9|CWE|58232-0^Hearing loss risk indicators^LN|8|11618000^ Intra-amniotic infection of

fetus^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|10|CWE|58232-0^Hearing loss risk indicators^LN|9|268239009^ Congenital abnormality of

skull and face bones ^SCT|||A|||F|||201201311234-0600||||





OBX|11|CWE|58232-0^Hearing loss risk indicators^LN|10|LA12681-5^Physical findings of

syndromes that include hearing loss^LN|||A|||F|||201201311234-0600||||



OBX|12|CWE|58232-0^Hearing loss risk indicators^LN|11|LA12676-5^Syndromes associated with

hearing loss^LN|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|13|CWE|58232-0^Hearing loss risk indicators^LN|12|80690008^ Degenerative disease of the

central nervous system (disorder)^SCT|||A|||F|||201201311234-0600||||



OBX|14|CWE|58232-0^Hearing loss risk indicators^LN|13|178280004^Postnatal infection

(disorder)^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|15|CWE|58232-0^Hearing loss risk indicators^LN|14|312972009^ Neonatal extracranial head

trauma (disorder)^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBX|16|CWE|58232-0^Hearing loss risk indicators^LN|15|161653008^ History of - chemotherapy

(situation)^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-



OBR|2|123456^ HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7|73744-

5^Newborn hearing screen panel of ear - right^LN|||201201311234-


1234^333|||||201201311234-0600|||F|||^Parent^Mama|

OBX|1|CWE|54109-4^Newborn hearing screen of ear –

right^LN|1|164059009^Pass^SCT|||N|||F|||201201311235-0600|||LA10389-





OBX|2|NM|73740-3^Duration of screening right

ear^LN|1|2|min^minuteÛCUM||N|||F|||201201311235-0600|||LA10389-





1^Newborn hearing screen panel of ear - left^LN|||201201311234-


1234^333|||||201201311234-0600|||F|||^Parent^Mama|

OBX|1|CWE|54108-6^Newborn hearing screen of ear -

left^LN|1|183924009^Refer^SCT|||A|||F|||201201311235-0600||| LA10389-




OBX|2|NM|73743-7^Duration of screening left ear

^LN|1|2|min^minuteÛCUM||N|||F|||201201311235-0600||| LA10389-




Sample Message with Reason Screen Not Done OBX


Device^2.16.840.1.113883.4.3.48ÔID|SendingFacility^2.16.840.1.113883.4.3.47ÔID|R

eceiving

Application^2.16.840.1.113883.19.3.22ÔID|PublicHealth^2.16.840.1.113883.19.3.21ÔI

D|20120701132554-



PID|1||MRN123||Jones^BabyGirl|James|201201300005-0600|F||2106-3^White^HL70005~1002-

5Âmerican Indian or Alaska Native^HL70005|201






PV1||I|427695007||||1001001^Smith^Theodore^^^Dr^^ÔPH^^^^NPI|

NK1|1|Jones^Mary^James|MTH^Mother^HL70063|201 Street^Ârlington^TX^99999ÛSA

|^PRN^PH^^011^555^555-5555|

OBR|1|123456^ HOSPITAL^9999999999^NPI|999555^PublicHealth^77D77712547^HL7|54111



1234^333|||||201201311234-0600|||F|||^Parent^Mama|

OBX|1|TX|57700-7^Hearing loss newborn screening comment/discussion^LN|1|baby

crying||||||F|||201201311234-0600||||Maico~EroScan|201201311234-0600||||Hospital|123

Street^Suite A^Dallas^TX^71211|1001001^Smith^Theodore^^^Dr^^ÔPH^^^^NPI|

OBX|2|CWE|58232-0^Hearing loss risk indicators^LN|1|439750006^ Family Hx of Hearing

Loss^SCT|||A|||F|||201201311234-0600|||| Maico~EroScan|201201311234-




5^Newborn hearing screen panel of ear - right^LN|||201201311234-


1234^333|||||201201311234-0600|||F|||^Parent^Mama|


right^LN|1|103709008Âttempted but unsuccessful – technical

fail^SCT|||N|||F|||201201311235-0600|||LA10389-





1^Newborn hearing screen panel of ear - left^LN|||201201311234-


1234^333|||||201201311234-0600|||F|||^Parent^Mama|


left^LN|1|103709008Âttempted but unsuccessful – technical fail

^SCT|||A|||F|||201201311235-0600||| LA10389-


hl7 version 2.6 implementation guide: early hearing ......loss. because newborn hearing loss is a...

Documents