Publisher API HL7 Segments

Introduction

Below are all of the segments that a DDS Publisher using the HL7 API can send. The definitions below are generic and hence are relatively permissive. In the context of a specific message the segment various segment definitions may be refined to take account of the data needed to complete the business function associated with the message. More detail can be found on the HL7 API messages page

MSH - Message Header

Overview

The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
MSH:3 - Sending application	MSH:3.1	ST	O	N	Sending application name
MSH:4 - Sending facility	MSH:4.1	ST	O	N	Sending facility name
MSH:7 - Message timestamp	MSH:7.1	DT	R	N	Datetime that the sending system created the message
MSH:9 - Message type	-	-	R	N
	MSH:9.1	ID	O	N	Message type. Allowed values are [TODO]
	MSH:9.2	ID	C	N	Trigger event. Allowed values are [TODO]
MSH:10 - Message control ID.	MSH:10.1	ST	R	N	This must be unique for all messages sent to DDS by each publisher. However, DDS does not currently detect or reject duplicate messages based on this value, so it is important that each publisher enforces this themselves.

EVN - Event Type

Overview

The EVN segment is used to communicate trigger event information to receiving applications

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
EVN:1 - Event Type Code	EVN:1.1	ID	X	N	Avoid populating this field. Instead use the second component (trigger event) of MSH-9-message type to transmit event type code information.
EVN:2 - Recorded Date/Time	EVN:2.1	TS	R	N	Timestamp of when the transaction was entered
EVN:3 - Date/Time planned event	EVN:3.1	TS	O	N	Avoid populating this field. Instead use PV2 expected admit date and PV2 expected discharge date whenever possible.
EVN:4 - Event reason code	EVN:4.1	CWE	O	N	The reason for this event. Allowed values are [TODO]. CWE data type - (http://www.hl7.eu/refactored/dtCWE.html)
EVN:5 - Operator ID	-	-	O	N	Operator ID. If provided, at least the family name must be given.
	EVN:5.2	ST	R	N	Family Name
	EVN:5.3	ST	O	N	Given Name
	EVN:5.4	ST	O	N	Middle Names
	EVN:5.6	ST	O	N	Prefix
EVN:6 - Event occured	EVN:6.1	TS	O	N	This field contains the date/time that the event actually occurred. For example, on a transfer (A02 (transfer a patient)), this field would contain the date/time the patient was actually transferred. On a cancellation event, this field should contain the date/time that the event being canceled occurred.

PID - Patient Identification

Overview

The PID segment is used as the main way of communicating patient identification information. The majority of patient identifying and demographic information held within the PID segment is not subject to frequent changes

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
PID:2 - Patient ID	-	-	X	N	Not used. Instead please populate PID.3 Patient Identifier List
PID:3 - Patient Identifier List	-	-	R	N	Patient Identifier List. At least the patient's NHS number must be present. In this instance the assigning authority (PID:3.4) must be "NHS"
	PID:3.1	ST	R	Y	Patient ID
	PID:3.4	ST	R	N	Assigning authority
	PID:3.5	ST	O	N	Type code
PID:5 - Patient Name	-	-	O	N	Though optional it is useful to provide all specified components to reduce the chances of patient confusion
	PID:5.1	ST	O	N	Family name
	PID:5.2	ST	O	N	Given name
	PID:5.3	ST	O	N	Middle names
	PID:5.4	ST	O	N	Title
PID:7	PID:7.1	TS	R	N	Date of birth
PID:8	PID:8.1	IS	R	N	Administrative sex. Allowed values are [TODO]
PID:10	PID:10.1	IS	O	N	Race. Allowed values are [TODO]
PID:11 - Patient Address	-	-	O	N
	PID:11.1	ST	O	N	Address line 1
	PID:11.2	ST	O	N	Address line 2
	PID:11.3	ST	O	N	City
	PID:11.4	ST	O	N	State or Province
	PID:11.5	ST	O	N	Post code
	PID:11.6	ID	O	N	Country. Allowed values are [TODO]
PID:13 - Home contact information	-	-	O	N
	PID:13.1	TN	O	N	Contact value
	PID:13.2	ID	O	N	Contact use code. Allowed values are [TODO]
	PID:13.4	ST	O	N	Email address. When receiving data where PID-14.2 is "NET", DDS will pull the email address from PID-14.4. If this field is not provided, then PID-14.1 will be used as the email address instead.
PID:14 - Work contact information	-	-	O	N
	PID:14.1	TN	O	N	Contact value
	PID:14.2	ID	O	N	Contact use code. Allowed values are [TODO]
	PID:14.4	ST	O	N	Email address. When receiving data where PID-14.2 is "NET", DDS will pull the email address from PID-14.4. If this field is not provided, then PID-14.1 will be used as the email address instead.
PID:15 - Primary language	-	-	O	N	Primary language. This should be the ISO 639-1 code.
	PID:15.1	ST	O	N	Primary language. Allowed values are [TODO]
	PID:15.3	ST	C	N	Name of coding system. Required if PID:15.4 is present. Must be http://terminology.hl7.org/CodeSystem/iso639-1	http://terminology.hl7.org/CodeSystem/iso639-1
	PID:15.4	ST	O	N	Primary language. Allowed values are [TODO]
	PID:15.6	ST	C	N	Name of coding system. Required if PID:15.4 is present. Must be http://terminology.hl7.org/CodeSystem/iso639-1	http://terminology.hl7.org/CodeSystem/iso639-1
PID:29	TS	O	N	Death timestamp. If the death timestamp is set, then "Y" is inferred for death indicator in PID:30, regardless of its actual value.
PID:30		TS	O	N	Death indicator. If this is "N" but a date of death is provided in PID:29 then [TODO - DDS error behaviour]

MRG - Merge Patient Information

Overview

The MRG segment is used by DDS to support merging of patient identifiers

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
MRG:1 - Prior Patient Identifier List	-	-	R	N
	MRG:1.1	ST	R	Y	Patient ID
	MRG:1.4	ST	R	N	Assigning authority
	MRG:1.5	ST	O	N	Type code
MRG:2 - Prior Alternate Patient ID		CX	X	N	Ignored if supplied
MRG:3 - Prior Alternate Account Number		CX	X	N	Ignored if supplied
MRG:4 - Prior Patient ID		CX	X	N	Ignored if supplied
MRG:5 - Prior Visit Number		CX	X	N	Ignored if supplied
MRG:6 - Prior Alternate Visit ID		CX	X	N	Ignored if supplied
MRG:7 - Prior Patient Name	-	XPN	X	N	Ignored if supplied

PV1 - Patient Visit

Overview

The PV1 segment is used by Registration/Patient Administration applications to communicate information on a visit-specific basis.

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
PV1:2 - Patient Class	PV1:2.1	ID	O	N	Allowed values are [TODO]
PV1:3 - Assigned Patient Location	PV1:3.9	ST	O	N	Free text description of the location
PV1:4 - Admission Type	PV1:4.1	ID	O	N	Allowed values are [TODO]
PV1:6 - Prior Patient Location	PV1:6.9	ST	O	N	Free text description of the location
PV1:7 - Attending Doctor	-	-	O	N	Attending doctor. If provided, at least the family name must be given.
	PV1:7.2	ST	R	N	Family Name
	PV1:7.3	ST	O	N	Given Name
	PV1:7.4	ST	O	N	Middle Names
	PV1:7.6	ST	O	N	Prefix
PV1:8 - Referring Doctor	-	-	O	N	Referring doctor. If provided, at least the family name must be given.
	PV1:8.2	ST	R	N	Family Name
	PV1:8.3	ST	O	N	Given Name
	PV1:8.4	ST	O	N	Middle Names
	PV1:8.6	ST	O	N	Prefix
PV1:9 - Consulting Doctor	-	-	O	N	Consulting doctor. If provided, at least the family name must be given.
	PV1:9.2	ST	R	N	Family Name
	PV1:9.3	ST	O	N	Given Name
	PV1:9.4	ST	O	N	Middle Names
	PV1:9.6	ST	O	N	Prefix
PV1:10 - Hospital Service	PV1:10.1	IS	O	N	Allowed values are [TODO]
PV1:13 - Re-admission Indicator	PV1:13.1	IS	O	N	Allowed values are [TODO]
PV1:18 - Patient Type	PV1:18.1	IS	O	N	Allowed values are [TODO]
PV1:19 - Visit Number	PV1:19.1	CX	R	N	Visit ID. Should uniquely identify an Encounter from the DDS publisher.
PV1:36 - Discharge Disposition	PV1:36.1	IS	O	N	Allowed values are [TODO]
PV1:37 - Discharged to Location	PV1:37.1	ID	O	N	Allowed values are [TODO]
PV1:44 - Admit Date/Time	PV1:44.1	TS	O	N	Admit timestamp
PV1:45 - Discharge Date/Time	PV1:45.1	TS	O	N	Discharge timestamp

PV2 - Patient Visit - Additional Information

Overview

The PV2 segment is a continuation of the information presented in the PV1 segment

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
PV2:3 - Admit reason	PV2:3.2	ST	O	N	Free text description of the reason for admission
PV2:4 - Transfer reason	PV2:4.2	ST	O	N	Free text description of the reason for transfer
PV2:8 - Expected Admit Date/Time	PV2:8.1	TS	O	N	Datetime of when admission is expected
PV2:9 - Expected Discharge Date/Time	PV2:9.1	TS	O	N	Datetime of when discharge is expected

OBX - Observation or result

Overview

The OBX segment can carry an observation about the patient or it can also be used to carry test results.

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
OBX:2 - Value Type	OBX:2.1	ID	O	N	Allowed values are [TODO]
OBX:3 - Observation Identifier	-	-	R	Y
	OBX:3.1	ST	R	N	Test ID. If this is a textual report, this value will be overridden by OBR:4.1. Otherwise this value must be provided. If a measurement is being provided, this ID must match one of the predefined values which DDS can accept.
	OBX:3.2	ST	O	N	Test Name
	OBX:3.3	ST	R	N	Test coding system. If this is a textual report, this value will be overridden by OBR:4.3. Note: DDS will only accept a measurement if this value is "SNOMED-CT"
OBX:5 - Observation Value	-	-	R	N	Test result value. If providing an SN value: OBX-5.1 must be one of: >, <, >=, <=, =. OBX-5.2 must be a number
	OBX:5.1	VARIES	R	N	Value or comparator
	OBX:5.2	VARIES	C	N	Value. Required if providing SN
OBX:6 - Observation Units	-	-	O	N
	OBX:6.1	ST	R	N	Unit ID.
	OBX:6.2	ST	O	N	Unit Name
	OBX:6.3	ST	R	N	Unit coding system
OBX:7	ST	O	N	Reference range
OBX:11	ST	O	N	Result status	Result status. Only values of F and C will be processed. Values of I, O, P or X (which indicate pending or no results) are silently ignored, whilst any other values will cause an error.
OBX:13	ST	O	N	Custom access rules	Custom access rules for lab results. Currently supported: "{patientDelay:NUMBERdays}" with any whole number in place of "NUMBER" (no spaces). The patient will see that a lab result has arrived, but the result value will not be revealed until the set number of days past the date/time of observation have passed. If this field is not specified the patient will be able to see their results immediately. Note: if this OBR group is a textual report spanning multiple OBX segments, the delay must be provided in the first.	{patientDelay:3days}
OBX:14	ST	C	N	Date/Time of the Observation	Observation timestamp. If this is not present, OBR-7 is used instead. It is an error for neither to be provided.

AL1 - Patient allergy information

Overview

Each AL1 segment describes a single patient allergy.

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
AL1:2 - Allergy type	AL1:2.1	IS	O	N	Allowed values are [TODO]
AL1:3 - Allergy code/description	-	-	R	N
	AL1:3.1	ST	O	N	Allergy ID.
	AL1:3.2	ST	C	N	Allergy Name. If AL1:3.1 is not provided then Allergy name is required
	AL1:3.3	ST	C	N	Allergy coding system. If AL1:3.1 is provided then Allergy coding system is required
AL1:4 - Allergy severity	AL1:4.1	IS	O	N	Allowed values are [TODO]
AL1:5 - Allergy reaction	AL1:5.1	ST	O	N
AL1:6 - Allergy identification date	AL1:6.1	DT	O	N

DG1 - Diagnosis

Overview

The DG1 segment contains patient diagnosis information of various types, for example, admitting, primary, etc. The DG1 segment is used to send multiple diagnoses (for example, for medical records encoding)

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
DG1:3 - Diagnosis code	-	-	O	N
	DG1:3.1	ST	O	N	Diagnosis ID.
	DG1:3.2	ST	C	N	Diagnosis Name. If DG1:3.1 is not provided then Diagnosis name is required
	DG1:3.3	ST	C	N	Diagnosis coding system. If DG1:3.1 is provided then Diagnosis coding system is required
DG1:4 - Diagnosis description	DG1:4.1	ST	C	N	If DG1:3 is not provided then DG1.4 is required
DG1:5 - Diagnosis data/time	DG1:5.1	TS	O	N	Datetime of diagnosis
DG1:16 - Diagnosing Clinician	-	-	O	N	Diagnosing Clinician. If provided, at least the family name must be given.
	DG1:16.2	ST	R	N	Family Name
	DG1:16.3	ST	O	N	Given Name
	DG1:16.4	ST	O	N	Middle Names
	DG1:16.6	ST	O	N	Prefix
DG1:17 - Diagnosis classification	DG1:17.1	IS	O	N	Allowed values are [TODO]

PR1 - Procedures

Overview

The PR1 segment contains information relative to various types of procedures that can be performed on a patient.

Definition

Field	Component	Data Type	Optionality	Repeating	Description	Example
PR1:3 - Procedure code	-	-	O	N
	PR1:3.1	ST	O	N	Procedure ID.
	PR1:3.2	ST	C	N	Procedure Name. If PR1:3.1 is not provided then Procedure name is required
	PR1:3.3	ST	C	N	Procedure coding system. If PR1:3.1 is provided then Procedure coding system is required
PR1:4 - Procedure description	PR1:4.1	ST	C	N	If PR1:3 is not provided then PR1.4 is required
PR1:5 - Procedure data/time	PR1:5.1	TS	O	N	Datetime of procedure
PR1:6 - Procedure type	PR1:6.1	IS	R	N	Allowed values are [TODO]