This messaging specification provides notes for required (non-optional) fields for each of the non-optional segments. For each segment the segment table defines the applicable constraints on usage for its fields for this specification (see Section 3.2 Message Element Attributes for a description of the columns in the Segment Attribute Tables.) All the relevant conformance statements and general usage notes are located at the end of each table. MSH - The MSH Segment is used to define the intent, source, destination, and some specifics of the syntax of the message. This segment includes identification of message delimiters, sender, receiver, message type, timestamp, etc. Table 5.2.1: Message Header Segment (MSH) Field Name Seq DT Len Usage Cardinality Value Set Description/Comments Field Separator 1 ST 1 R [1..1] Conformance Statement: CN-004: MSH.1 (Field Separator) SHALL contain the constant value '|'. Encoding Characters 2 ST 4 R [1..1] Conformance Statement: CN-005: MSH.2 (Encoding Characters) SHALL contain the constant value '^~\&'. Sending Application 3 HD 227 R [1..1] This field uniquely identifies the sending application among all other applications within the network enterprise. The network enterprise consists of all those applications that participate in the exchange of HL7 messages within the enterprise. A public health agency (PHA) with the authority to send HL7 case notifications to CDC should use a unique Object Identifier (OID) in this field to indicate the specific PHA system from which the case notification data is being sent. Each PHA sending system should have its own unique OID. (Refer to TA and Training Resource Center at for further resources). 61
Multiple Birth Indicator 24 ID 1 O [0..1] Birth Order 25 NM 2 O [0..1] Citizenship 26 CE 841 O [0..*] Veterans Military Status 27 CE 841 O [0..1] Nationality 28 X Patient Death Date and Time 29 TS 26 RE [0..1] Patient Death Indicator 30 ID 1 O [0..1] Identity Unknown Indicator 31 ID 1 O [0..1] Identity Reliability Code 32 IS 20 O [0..*] Last Update Date/Time 33 TS 26 O [0..1] Last Update Facility 34 HD 241 O [0..1] Species Code 35 CE 841 RE [0..1] Population of this field supports animal rabies testing by public health laboratories. Breed Code 36 CE 841 O [0..1] Strain 37 ST 80 O [0..1] Production Class Code 38 CE 841 O [0..2] 36 45 46 47
Result Status 25 ID 1 R [1..1] Result Status (HL7) Required field in this segment. The remaining segments must be populated with a value from the value set, but the values are constrained in the Epidemiology segment to act as the “source of truth” for the status of the notification CONFORMANCE STATEMENT CN-019: OBR-25 Result Status SHALL be limited to the following values when OBR-4 is valued ‘68991-9^Epidemiologic Information^LN’: ‘F’ for Final, when the notification is first sent. ‘C’ for Correction, when an update/revision is sent. ‘X’ to indicate that the previously received notification has been deleted or rescinded. To update information on a previously submitted case, update the information in your surveillance system and re-send the case. Set the Notification Result Status (in OBR-25) to “C” to indicate a correction and, if needed, update the case classification status (e.g., confirmed, probable, suspected, not a case.) The updated record will supersede the previous notification. Be careful not to change data elements used to define a unique case (see or you will cause a new case to be added to the CDC data base instead of updating a previously reported case. If you determine that a previously sent case should not be counted as a case, send an updated case notification using one of the following methods: Preferred Method: Re-send the case with case classification status data element ‘77990-0’ =“Not a Case” and Notification Result Status (OBR-25) = “C” to indicate this is a correction. Alternate Method: Re-send the case with case classification status data element ‘77990-0’ = “Not a Case” and Notification Result Status (OBR-25) = “X” to indicate this case is “rescinded”. Alternate Method for jurisdictions unable to send case classification status of “Not a Case”: Regardless of the value transmitted in the case classification status, re-send the case with Notification Result Status (in OBR-25) = “X” to indicate this case is rescinded.
Number of Sample Containers 37 NM 4 O [0..1] Transport Logistics of Collected Sample 38 CE 841 O [0..*] Collector's Comment 39 CE 841 O [0..*] Transport Arrangement Responsibility 40 CE 841 O [0..1] Transport Arranged 41 ID 30 O [0..1] Escort Required 42 ID 1 O [0..1] Planned Patient Transport Comment 43 CE 841 O [0..*] Procedure Code 44 CE 841 O [0..1] Procedure Code Modifier CE 841 O [0..1] Placer Supplemental Service Information CE 841 O [0..1] Filler Supplemental Service Information CE 841 O [0..1] Medically Necessary Duplicate Procedure Reason 48 CE 841 O [0..1] Result Handling 49 IS 2 O [0..1]
Description Observations to be in the message. 7 Segment Profile Attributes Throughout The message was very constrained to set many fields to “not supported.” In theory, this will kick out a lot of messages if the receiver profile is not relaxed. Many fields in used segments have been set to “optional” with the comment that if the field is optional, it is not defined in this document and not expected to be processed by the receiver. Fields that remained constrained as “not supported” are those that are no longer used for this HL7 version or ones that potentially contain PII data that should not be sent for this use case. 8 Message Structure ORU^R01 Message Syntax ORU^R01^ORU_R01 Message definition was a very simplified structure that only showed the required fields and segment groups. ORU^R01^ORU_R01 Message Syntax has been updated to align with the ELR version of the message syntax. 9 1.4 Summary of Changes Formerly described the use of the 6 categories of data. Reworked to clarify and correct the HL7 content change descriptions 10 6 Appendix A Technical Considerations Only contained a discussion about repeating groups Added a section to discuss repeating variables (that is, the use of the tilde in the field for a multi-select answer). 11 7 Appendix Messaging Examples Messages were conformant to specifications. Revised the messages 12 5.2 Segment and Field All CE fields Maximum length CE fields were not consistence. Maximum length increased to 841. This increase affected other datatypes that contain a CE datatype as a component, such as VID and XPN. 13 5.2 Segment and Field All CWE fields Maximum length CE fields were not consistence. Maximum length increased to 1063. This increase affected other datatypes that contain a CWE datatype as a component, such as XCN. 14 5.2.4 OBR Segment Detail OBR-22 Status Chg/Update Date/time The cardinality of OBR-22 was [1..1]. Technical correction to the cardinality of OBR-22 from [1..1] to [0..1]. This is not an HL7 required field so it is only required per Condition Predicate: If OBR-4 is populated with Information^LN’ APPENDIX E – REVISION LIST Location Field Name Justifications / Comments Version 3.0
1 Pages 1-4 Release 3.0 Publication History Copyright text Version 3.0 Release 1 October 18, 2016 Updated with correct LOINC information 2 Throughout A number of conformance statements have been added and detailed in the appendix to clarify any ambiguities in the use of the message fields. APPENDIX C – CONFORMANCE STATEMENTS has been added. 3 Actors, Goals and Messaging Transactions The Case Notification Use Case was not included in the document, it was previously described in a separate document posted on the PHIN web site. The Use Case for National Notifiable Condition Reporting has been incorporated into the document. 4 HL7 Batch Protocol HL7 Batch Protocol was previously described in a separate document posted on the PHIN web site. HL7 Batch Protocol has been incorporated into this document under the Messaging Infrastructure section. 5 Reviewers Comments Throughout Incorporated feedback and comments. Incorporated many suggestions for edits and improvements to wording, typo corrections, etc. 6 Table 2.1. Information Interchange Requirements State case investigation identifier Throughout Message needs to be structurally correct as well as have a minimum set of required observations answered to be accepted and processed. Added requirement for the state case investigation identifier. Case Report to Case Notification National Notifiable Case Notification containing data elements related to a national notifiable disease. Required patient data for all National Notifiable Case Notification: Sending system’s Internal case investigation identifier Case Class Status MMWR Week MMWR Year Reporting State National OR Reporting Jurisdiction 7 4 Data Types Added datatype specifications for CQ EIP, NM, XCN and XON. Added a Added a new comment in the Data Types introduction: “There may be some Optional fields in the segments
required if sent. 15 5.2.4 OBR – Observation Request Segment OBR-16 / Ordering Provider Previously not supported Updated to be supported, changed usage from X to RE and removed the highlighting for OBR-16 in the OBR table to indicate it is available for use. 16 Contact Information Contact information added for assistance with the artifact. Added with the following text: This artifact is considered to be a technical document. Please contact edx@cdc.gov for assistance with this artifact. 17 Section 1.2 Removal of unused acronyms and addition of used acronyms. Removed CSTE, IIS, NETSS, PHLIP, STD, STLT. Added ELR, MMG, OID. 18 Table 2.1 Corrected the required patient data list for “Reporting State OR National Reporting Jurisdiction,” replaced “OR” with “AND”. Reporting State AND National Reporting Jurisdiction 19 Tables 2.1, 2.2, 3.1 / Sections 3.10, 3.11, 4 Updated table numbering and section numbering due to table changes or for newly added tables and sections. Some tables used the ‘-’ notation and used the ‘.’ Notation. Example Table 2-1 or Table 2.1, replaced with the ‘.’ Notation. Table 2.1, Table 2.2, Table 3.1 Updated Usage Conformance Testing Recommendations section to 3.10. Various tables under 3.11 HL7 Batch Protocol. Various tables under section 4 Data Types. 20 Section Added sections for information on the use of standard codes, literal values, unknown values and MMG constraints. Sections 3.6 – 3.9 21 Section 4.3 & 4.11 Addition of CQ and FT data types, mentioned or used but not listed in the data type list. CQ (Composite Quantity with Units) FT (Formatted Text Data) 22 Section 4.1, 4.2, 4.4 Update CWE, CE-PH, and CE data types to include reference to using standard Component 1: “Standard coding system identifier must be used.”
or rescinded. To update information on a previously submitted case, update the information in your surveillance system and re-send the case. Set the Notification Result Status (in OBR-25) to “C” to indicate a correction and, if needed, update the case classification status (e.g., confirmed, probable, suspected, not a case.) The updated record will supersede the previous notification. Be careful not to change data elements used to define a unique case (see or you will cause a new case to be added to the CDC data base instead of updating a previously reported case. If you determine that a previously sent case should not be counted as a case, send an updated case notification using one of the following methods: Preferred Method: Re-send the case with case classification status data element ‘77990-0’ =“Not a Case” and Notification Result Status = “C” to indicate this is a correction. Alternate Method: Re-send the case with case classification status data element ‘77990-0’ = “Not a Case” and Notification Result Status (OBR-25) = “X” to indicate this case is “rescinded”. Alternate Method for jurisdictions unable to send case classification status of “Not a Case”: Regardless of the value transmitted in the case classification status, re-send the case with Notification Result Status (in OBR-25) = “X” to indicate this case is rescinded. 44 Table 5.2.5 OBX-4 Updated the wording in the condition predicate to help clarify the usage when repeating segments. Condition Predicate: If the OBX segment is allowed to repeat more than once within the same OBR segment and contain the same values. 45 Table 5.2.5 OBX-4 Added conformance statement to indicate the requirement for OBX-4 to CONFORMANCE STATEMENT OBX-4 SHALL have the same unique numeric value in each
have the same unique numeric value in each repeating group. repeating group. 46 Section 5.2.6 SPM Removed the reference to the ’30954-2^Laboratory Information^LN’ section header and added “Supported to allow for the sending of laboratory data elements of interest under the Laboratory Information Section Header (Lab OBR).” Original wording was determined to be unclear and unnecessary. The intent of this segment is to describe the characteristics of a specimen. It differs from the intent of the OBR, in that the OBR addresses order-specific information. Supported to allow for the sending of laboratory data elements of interest under the Laboratory Information Section Header (Lab OBR), Optionally supported to allow mapping similar to ELR. 47 Section 5.2.7 NTE Removed the reference to the ’30954-2^Laboratory Information^LN’ section header and added “Supported to allow for the sending of laboratory data elements of interest under the Laboratory Information Section Header (Lab OBR).” Original wording was determined to be unclear and unnecessary. The NTE segment is defined here to allow for inclusion in the Case Notification message, for Notes and Comments following an OBX Observation segment. Supported to allow for the sending of optional laboratory data elements of interest under the Laboratory Information Section Header (Lab OBR.), Optionally supported to allow mapping similar to ELR. 48 Various Updated conformance statement numbering and alignment due to the addition of several conformance statements and corrections to miss numbered conformance numbers. Numbering from CN-001 through 49 Section 8 Appendix C Updated conformance statement list and alignment with conformance statements listed throughout the PHIN Messaging Specification. Various. 50 Section 9 Appendix D Appendix D was updated to contain the Modifications from the PHIN Messaging Specification V2.0 and V3.0. To clarify between the Updated Appendix D.