(47 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
== Introduction == | == 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 [[Publisher API HL7 Messages|HL7 API messages page]] | 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 [[Publisher API HL7 Messages|HL7 API messages page]] | ||
== Coded fields == | |||
Note that currently only a subset of the coded fields that are specified in the segments below are interpreted by DDS (see below). The remainder are left as-is once ingested in to DDS are are not processed further. In this latter case it is recommended that publishers take note of the suggested code sets as in the future it might be that these fields are interpreted by DDS and therefore a mapping exercise will need to be undertaken to map from publisher local codes to a core DDS code set. | |||
* Primary Language - PID:15 | |||
* Religion - PID:17 | |||
* Ethnic Group - PID:22 | |||
* Admission Type - PV1:4 | |||
* Hospital Service - PV1:10 | |||
* Admit Source - PV1:14 | |||
* Patient Type - PV1:18 | |||
* Discharge Disposition - PV1:36 | |||
* Discharged to Location - PV1:37 | |||
== MSA - Message acknowledgement == | == MSA - Message acknowledgement == | ||
Line 62: | Line 75: | ||
!Description | !Description | ||
!Example | !Example | ||
|- | |||
|MSH.1 - Field Separator | |||
|MSH:1.1 | |||
|ST | |||
|R | |||
|N | |||
|Defines the character to be used as the separator in the message | |||
| | |||
|- | |||
|MSH.2 - Encoding characters | |||
|MSH:2.1 | |||
|ST | |||
|R | |||
|N | |||
|Contains (in the following order) component separator, repetition separator, escape character, and subcomponent separator | |||
| | |||
|- | |- | ||
|MSH:3 - Sending application | |MSH:3 - Sending application | ||
|MSH:3.1 | |MSH:3.1 | ||
|ST | |ST | ||
| | |R | ||
|N | |N | ||
|Sending application name | |Sending application name | ||
Line 74: | Line 103: | ||
|MSH:4.1 | |MSH:4.1 | ||
|ST | |ST | ||
| | |R | ||
|N | |N | ||
|Sending facility name | |Sending facility name | ||
| | |||
|- | |||
|MSH:5 - Receiving application | |||
|MSH:5.1 | |||
|ST | |||
|R | |||
|N | |||
|Receiving application name | |||
| | |||
|- | |||
|MSH:6 - Receiving facility | |||
|MSH:6.1 | |||
|ST | |||
|R | |||
|N | |||
|Receiving facility name | |||
| | | | ||
|- | |- | ||
Line 98: | Line 143: | ||
|MSH:9.1 | |MSH:9.1 | ||
|ID | |ID | ||
| | |R | ||
|N | |N | ||
|Message type. | |Message type. Values SHOULD be from table [[Publisher API Code Sets#DDS-HL7v2-MessageType|DDS-HL7v2-MessageType]] | ||
| | | | ||
|- | |- | ||
|MSH:9.2 | |MSH:9.2 | ||
|ID | |ID | ||
| | |R | ||
|N | |N | ||
|Trigger event. | |Trigger event. Values SHOULD be from table [[Publisher API Code Sets#DDS-HL7v2-EventType|DDS-HL7v2-EventType]] | ||
| | | | ||
|- | |- | ||
Line 116: | Line 161: | ||
|N | |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. | |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. | ||
| | |||
|- | |||
|MSH:11 - Processing ID | |||
|MSH:11.1 | |||
|PT | |||
|O | |||
|N | |||
|In production MUST be "P" | |||
| | |||
|- | |||
|MSH:12 - Message version | |||
|MSH:12.1 | |||
|ID | |||
|R | |||
|N | |||
|The version of HL7 that this message conforms to. MUST be "2.3" | |||
| | | | ||
|} | |} | ||
Line 137: | Line 198: | ||
|EVN:1.1 | |EVN:1.1 | ||
|ID | |ID | ||
| | |O | ||
|N | |N | ||
| | |The value should be the same as theMSH:9.2 (trigger event) | ||
| | | | ||
|- | |- | ||
Line 234: | Line 295: | ||
| | | | ||
|- | |- | ||
| rowspan=" | | rowspan="3" |PID:3 - Patient Identifier List | ||
| - | | - | ||
| - | | - | ||
|R | |R | ||
|N | |N | ||
|Patient Identifier List. This list must include at least | |Patient Identifier List. This list must include at least both of the following (in order) - | ||
* the patient's local (to the publisher) identifier. In this instance the assigning authority (PID:3.4) must be "MRN" | * the patient's local (to the publisher) identifier. In this instance the assigning authority (PID:3.4) must be "MRN" | ||
*the patient's NHS number. In this instance the assigning authority (PID:3.4) must be "NHS" | |||
| | | | ||
|- | |- | ||
Line 257: | Line 318: | ||
|N | |N | ||
|Assigning authority | |Assigning authority | ||
| | | | ||
|- | |- | ||
Line 269: | Line 323: | ||
| - | | - | ||
| - | | - | ||
| | |R | ||
|N | |N | ||
| | | | ||
| | | | ||
|- | |- | ||
|PID:5.1 | |PID:5.1 | ||
|ST | |ST | ||
| | |R | ||
|N | |N | ||
|Family name | |Family name | ||
Line 295: | Line 349: | ||
| | | | ||
|- | |- | ||
|PID:5. | |PID:5.5 | ||
|ST | |ST | ||
|O | |O | ||
Line 315: | Line 369: | ||
|R | |R | ||
|N | |N | ||
|Administrative sex. | |Administrative sex. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from table [[Publisher API Code Sets#AdministrativeSex|AdministrativeSex]] | ||
| | | | ||
|- | |- | ||
| rowspan=" | | rowspan="8" |PID:11 - Patient Address | ||
| - | | - | ||
| - | | - | ||
Line 347: | Line 401: | ||
| | | | ||
|- | |- | ||
|PID:11. | |PID:11.5 | ||
|ST | |ST | ||
|O | |O | ||
|N | |N | ||
| | |Post code | ||
| | | | ||
|- | |- | ||
|PID:11. | |PID:11.6 | ||
| | |ID | ||
|O | |O | ||
|N | |N | ||
| | |Country. Values SHOULD be from table [[Publisher API Code Sets#0399-CountryCode|0399-CountryCode]] | ||
| | | | ||
|- | |- | ||
|PID:11. | |PID:11.7 | ||
|ID | |ID | ||
|O | |O | ||
|N | |N | ||
| | |Address usage eg temporary address | ||
| | |||
|- | |||
|PID:11.9 | |||
|IS | |||
|O | |||
|N | |||
|County | |||
| | | | ||
|- | |- | ||
| rowspan=" | | rowspan="3" |PID:13 - Home contact information | ||
| - | | - | ||
| - | | - | ||
Line 387: | Line 448: | ||
|O | |O | ||
|N | |N | ||
|Contact use code. Allowed values are | |Contact use code. Allowed values are "home" or "mobile" | ||
| | | | ||
|- | |- | ||
| rowspan=" | | rowspan="3" |PID:14 - Work contact information | ||
| - | | - | ||
| - | | - | ||
|O | |O | ||
|N | |N | ||
Line 416: | Line 470: | ||
|O | |O | ||
|N | |N | ||
|Contact use code. Allowed values | |Contact use code. Allowed values is "work" | ||
| | | | ||
|- | |- | ||
| rowspan=" | | rowspan="2" |PID:15 - Primary language | ||
| - | | - | ||
| - | | - | ||
|O | |O | ||
|N | |N | ||
|Primary language. This should be the ISO 639-1 code. | |Primary language. This should be the ISO 639-1 code or one of the five communication method extensions defined in the NHS Data Dictionary code set. | ||
| | | | ||
|- | |- | ||
Line 438: | Line 485: | ||
|O | |O | ||
|N | |N | ||
|Primary language. | |Primary language. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source]<nowiki> then allowed values are child concepts of the SNOMED CT World Languages concept - 297289008 | World languages (qualifier value) |</nowiki> | ||
| | | | ||
|- | |- | ||
|PID: | |PID:17 - Religion | ||
|PID:17.1 | |||
|IS | |IS | ||
|O | |O | ||
|N | |N | ||
| | |Religion. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/religious_or_other_belief_system_affiliation_code.html RELIGIOUS OR OTHER BELIEF SYSTEM AFFILIATION CODE] | ||
| | | | ||
|- | |- | ||
|PID: | |PID:18 - Patient Account Number | ||
| | |PID:18.1 | ||
|ST | |||
|C | |C | ||
|N | |N | ||
| | |Though officially this field is intended to capture account number it has been repurposed in DDS. It is used to carry the identifier for the episode of care. Simplistically an episode of care encapsulates all of the encounters that a patient may have with a healthcare organisation from the point of referral to the point of discharge. | ||
| | If the publisher does not have the concept of episode of care then instead this MUST be the same value as that found in PV1.19 - Visit number. | ||
If no PV1 segment accompanies this PID segment then PID:18 should not be populated | |||
| | |||
|- | |- | ||
|PID:22 | |PID:22 - Ethnic group | ||
| - | | - | ||
| - | | - | ||
Line 475: | Line 520: | ||
|O | |O | ||
|N | |N | ||
|Ethnicity identifier. | |Ethnicity identifier. If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/data_elements/ethnic_category.html?hl=ethnicity ETHNIC CATEGORY] | ||
| | | | ||
|- | |- | ||
| | |PID:29 - Patient Death Date and Time | ||
|PID: | |PID:29.1 | ||
| | |TS | ||
|C | |C | ||
|N | |N | ||
| | |If PID.30:1 is not empty and PID:30.1 == "Y" then PID:29 is mandatory | ||
| | | | ||
|- | |- | ||
|PID: | |PID:30 - Patient Death Indicator | ||
| | |PID:30.1 | ||
|ID | |||
|O | |O | ||
|N | |N | ||
| | |"Y" or "N" | ||
| | | | ||
|} | |} | ||
== | == PD1 - Patient Additional Demographic == | ||
=== Overview === | === Overview === | ||
The | The PD1 segment contains demographic information about a patient that is likely to change. In the case of DDS is it used to carry GP data. | ||
=== Definition === | === Definition === | ||
Line 518: | Line 555: | ||
!Example | !Example | ||
|- | |- | ||
| rowspan=" | | rowspan="3" |PD1:3 - Patient Primary Facility | ||
| - | | - | ||
| - | | - | ||
Line 526: | Line 563: | ||
| | | | ||
|- | |- | ||
| | |PD1:3.1 | ||
|ST | |||
|R | |||
|N | |||
|name | |||
| | |||
|- | |||
|PD1:3.3 | |||
|ST | |||
|R | |||
|N | |||
|ODS code | |||
| | |||
|- | |||
| rowspan="5" |PD1:4 - Patient Primary Care Provider Name and ID No | |||
| - | |||
| - | |||
|R | |||
|N | |||
| | |||
| | |||
|- | |||
|PD1:4.1 | |||
|ST | |ST | ||
|R | |R | ||
| | |N | ||
| | |GMC code | ||
| | |||
|- | |||
|PD1:4.2 | |||
|FN | |||
|R | |||
|N | |||
|Family name | |||
| | | | ||
|- | |- | ||
| | |PD1:4.3 | ||
|ST | |ST | ||
|R | |R | ||
|N | |N | ||
| | |Given name | ||
| | | | ||
|- | |- | ||
| | |PD1:4.6 | ||
|ST | |ST | ||
|O | |O | ||
|N | |N | ||
|Type | |Prefix | ||
| | |||
|} | |||
== MRG - Merge Patient Information == | |||
=== Overview === | |||
The MRG segment is used by DDS to support merging of patient identifiers | |||
=== Definition === | |||
{| class="wikitable" | |||
!Field | |||
!Component | |||
!Data Type | |||
!Optionality | |||
!Repeating | |||
!Description | |||
!Example | |||
|- | |||
|MRG:1 - Prior Patient Identifier List | |||
|MRG:1.1 | |||
| CX | |||
|R | |||
|N | |||
|MUST only contain one value - the patient's local (to the publisher) identifier. | |||
| | | | ||
|- | |- | ||
Line 565: | Line 654: | ||
|MRG:4 - Prior Patient ID | |MRG:4 - Prior Patient ID | ||
| | | | ||
| | | - | ||
|X | |X | ||
|N | |N | ||
Line 588: | Line 677: | ||
|- | |- | ||
|MRG:7 - Prior Patient Name | |MRG:7 - Prior Patient Name | ||
| - | | - | ||
| XPN | | XPN | ||
|X | |X | ||
Line 614: | Line 703: | ||
|PV1:2.1 | |PV1:2.1 | ||
|ID | |ID | ||
| | |R | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from table [[Publisher API Code Sets#PatientClass|PatientClass]] | ||
| | | | ||
|- | |- | ||
|PV1:3 - Assigned Patient Location | |PV1:3 - Assigned Patient Location | ||
|PV1:3. | |PV1:3.1 | ||
| | |IS | ||
| | |R | ||
|N | |N | ||
| | |General patient location | ||
| | | | ||
|- | |- | ||
Line 632: | Line 721: | ||
|O | |O | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/admission_method.html ADMISSION METHOD] | ||
| | | | ||
|- | |- | ||
|PV1: | | rowspan="5" |PV1:8 - Referring Doctor | ||
| | | - | ||
| | | - | ||
|O | |O | ||
|N | |N | ||
| | |Referring doctor. If provided, at least the family name must be given. | ||
| | | | ||
|- | |- | ||
|PV1: | |PV1:8.1 | ||
|ST | |ST | ||
|O | |O | ||
|N | |N | ||
| | |ID number | ||
| | | | ||
|- | |- | ||
|PV1: | |PV1:8.2 | ||
|ST | |ST | ||
|O | |O | ||
|N | |N | ||
|Family Name | |Family Name | ||
Line 699: | Line 751: | ||
|N | |N | ||
|Given Name | |Given Name | ||
| | | | ||
|- | |- | ||
Line 718: | Line 763: | ||
| - | | - | ||
| - | | - | ||
| | |R | ||
|N | |N | ||
|Consulting doctor. If provided, at least the family name must be given. | |Consulting doctor. If provided, at least the family name must be given. | ||
| | |||
|- | |||
|PV1:9.1 | |||
|ST | |||
|R | |||
|N | |||
|ID number | |||
| | | | ||
|- | |- | ||
Line 735: | Line 787: | ||
|N | |N | ||
|Given Name | |Given Name | ||
| | | | ||
|- | |- | ||
Line 754: | Line 799: | ||
|PV1:10.1 | |PV1:10.1 | ||
|IS | |IS | ||
| | |R | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/treatment_function_code.html TREATMENT FUNCTION CODE] | ||
| | | | ||
|- | |- | ||
|PV1: | |PV1:14 - Admit source | ||
|PV1: | |PV1:14.1 | ||
|IS | |IS | ||
|O | |O | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/source_of_admission.html SOURCE OF ADMISSION] | ||
| | | | ||
|- | |- | ||
Line 770: | Line 815: | ||
|PV1:18.1 | |PV1:18.1 | ||
|IS | |IS | ||
| | |R | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from table [[Publisher API Code Sets#HL7v3-EncounterType|HL7v3-EncounterType]] | ||
| | | | ||
|- | |- | ||
Line 788: | Line 833: | ||
|O | |O | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/discharge_method.html DISCHARGE METHOD] | ||
| | | | ||
|- | |- | ||
Line 796: | Line 841: | ||
|O | |O | ||
|N | |N | ||
| | |If [https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Messages#Coded_field_mapping mapping at source] then allowed values are from [https://datadictionary.nhs.uk/attributes/discharge_destination.html DISCHARGE DESTINATION] | ||
| | | | ||
|- | |- | ||
Line 802: | Line 847: | ||
|PV1:44.1 | |PV1:44.1 | ||
|TS | |TS | ||
| | |C | ||
|N | |N | ||
|Admit timestamp | |Admit timestamp | ||
Line 813: | Line 858: | ||
|N | |N | ||
|Discharge timestamp | |Discharge timestamp | ||
| | | | ||
|} | |} | ||
Line 937: | Line 934: | ||
|R | |R | ||
|N | |N | ||
|Facility ID type. | |Facility ID type. Values SHOULD be from table [[Publisher API Code Sets#0074-DiagnosticServiceSectionID|0074-DiagnosticServiceSectionID]] | ||
| | | | ||
|} | |} | ||
Line 1,049: | Line 1,046: | ||
|N | |N | ||
|This field is the section of the diagnostic service where the observation was performed. | |This field is the section of the diagnostic service where the observation was performed. | ||
If the study was performed by an outside service, the identification of that service should be recorded here. | If the study was performed by an outside service, the identification of that service should be recorded here. Values SHOULD be from table [[Publisher API Code Sets#0074-DiagnosticServiceSectionID|0074-DiagnosticServiceSectionID]] | ||
| | | | ||
|- | |- | ||
Line 1,057: | Line 1,054: | ||
|O | |O | ||
|N | |N | ||
|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. | |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. Values SHOULD be from table [[Publisher API Code Sets#DDS-ResultStatus|DDS-ResultStatus]] | ||
| | | | ||
|} | |} | ||
Line 1,077: | Line 1,074: | ||
!Description | !Description | ||
!Example | !Example | ||
|- | |||
|OBX:1 - Set ID | |||
|OBX:1.1 | |||
|SI | |||
|R | |||
|N | |||
|Sequence number for OBX. Must be unique under its associated OBR segment | |||
| | |||
|- | |- | ||
|OBX:2 - Value Type | |OBX:2 - Value Type | ||
|OBX:2.1 | |OBX:2.1 | ||
|ID | |ID | ||
| | |R | ||
|N | |N | ||
| | |Values SHOULD be from table [[Publisher API Code Sets#0125-ValueType|0125-ValueType]] | ||
| | | | ||
|- | |- | ||
| rowspan="4" |OBX:3 - Observation Identifier | | rowspan="4" |OBX:3 - Observation Identifier | ||
| - | | - | ||
| | | CWE | ||
|R | |R | ||
|Y | |Y | ||
| | |If this is a textual report, this value will be overridden by OBR:4. Otherwise this value must be provided. | ||
| | | | ||
|- | |- | ||
Line 1,098: | Line 1,103: | ||
|R | |R | ||
|N | |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. | |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. At the time of writing the acceptable code systems are still being defined though there is an aspiration to adopt the [https://digital.nhs.uk/about-nhs-digital/our-work/nhs-digital-data-and-technology-standards/clinical-information-standards#unified-test-list National Unified Test List] where appropriate. Note that this does not exclude the adoption of more appropriate code systems depending upon the nature of the observation | ||
| | | | ||
|- | |- | ||
Line 1,110: | Line 1,115: | ||
|OBX:3.3 | |OBX:3.3 | ||
|ST | |ST | ||
| | |C | ||
|N | |N | ||
|Test | |Test coding system. If this is a textual report, this value will be overridden by OBR:4.3. | ||
| | | | ||
|- | |- | ||
|OBX:5.1 | |OBX:5 - Observation Value | ||
|VARIES | | OBX:5.1 | ||
| VARIES | |||
|R | |R | ||
|N | |N | ||
|Value | |Value. Type MUST match OBX:2.1 | ||
| | | | ||
|- | |- | ||
Line 1,193: | Line 1,184: | ||
|R | |R | ||
|N | |N | ||
|Flag ID | |Flag ID - Values SHOULD be from table <nowiki>http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation</nowiki> | ||
| | | | ||
|- | |- | ||
Line 1,205: | Line 1,196: | ||
|OBX:8.3 | |OBX:8.3 | ||
| | | | ||
| | |O | ||
|N | |N | ||
|Flag coding system - | |Flag coding system - If present then SHOULD be "<nowiki>http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation</nowiki>" | ||
| | | | ||
|- | |- | ||
Line 1,215: | Line 1,206: | ||
|N | |N | ||
|Result status | |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. | |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. Values SHOULD be from table [[Publisher API Code Sets#DDS-ResultStatus|DDS-ResultStatus]] | ||
| | | | ||
|- | |- | ||
Line 1,233: | Line 1,224: | ||
|Observation timestamp. If this is not present, OBR:7 is used instead. It is an error for neither to be provided. | |Observation timestamp. If this is not present, OBR:7 is used instead. It is an error for neither to be provided. | ||
| | | | ||
| | |||
|- | |||
| rowspan="5" |OBX:16 - Responsible Observer | |||
| | |||
| | |||
|O | |||
|N | |||
|If provided, at least the family name must be given. | |||
| | |||
|- | |||
|OBX:16.2 | |||
|ST | |||
|R | |||
|N | |||
|Family Name | |||
| | |||
|- | |||
|OBX:16.3 | |||
|ST | |||
|O | |||
|N | |||
|Given Name | |||
| | |||
|- | |||
|OBX:16.4 | |||
|ST | |||
|O | |||
|N | |||
|Middle Names | |||
| | |||
|- | |||
|OBX:16.6 | |||
|ST | |||
|O | |||
|N | |||
|Prefix | |||
|} | |} | ||
Line 1,276: | Line 1,303: | ||
| - | | - | ||
|"POS" | |"POS" | ||
|} | |}<br /> | ||
Latest revision as of 12:54, 27 October 2021
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
Coded fields
Note that currently only a subset of the coded fields that are specified in the segments below are interpreted by DDS (see below). The remainder are left as-is once ingested in to DDS are are not processed further. In this latter case it is recommended that publishers take note of the suggested code sets as in the future it might be that these fields are interpreted by DDS and therefore a mapping exercise will need to be undertaken to map from publisher local codes to a core DDS code set.
- Primary Language - PID:15
- Religion - PID:17
- Ethnic Group - PID:22
- Admission Type - PV1:4
- Hospital Service - PV1:10
- Admit Source - PV1:14
- Patient Type - PV1:18
- Discharge Disposition - PV1:36
- Discharged to Location - PV1:37
MSA - Message acknowledgement
Overview
The MSA segment contains information sent whilst acknowledging an inbound message. The following rules govern the nature of the acknowledgement -
- If the message could not be saved to the DDS message store then an AR (failure occurred, retry) acknowledgement code is returned.
- If the message is malformed, or fails sender, recipient or message type checks, or is missing a message control ID, or fails for an unexpected reason, an AE (failure occurred, move to next message) acknowledgement code is returned.
- If the message passes the above checks and is saved to the message store, an AA (success) acknowledgement code is returned.
- If the message receiver fails to send an acknowledgement (e.g. network outage, hardware failure etc), it is expected the sender will automatically re attempt to send the message.
Definition
Field | Component | Data Type | Optionality | Repeating | Description | Example |
---|---|---|---|---|---|---|
MSA:1 - Acknowledgement code | MSH:1.1 | ID | R | N | Message type. Allowed values are from table DDS-HL7v2-AckCode | |
MSA:2 - Message control ID | MSH:1.1 | ST | R | N | Unique (to DDS) identifier assigned by DDS | |
MSA:3 - Text message | MSA:3.1 | ST | O | N | Further describes an error condition (may not always be provided by DDS) |
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.1 - Field Separator | MSH:1.1 | ST | R | N | Defines the character to be used as the separator in the message | |
MSH.2 - Encoding characters | MSH:2.1 | ST | R | N | Contains (in the following order) component separator, repetition separator, escape character, and subcomponent separator | |
MSH:3 - Sending application | MSH:3.1 | ST | R | N | Sending application name | |
MSH:4 - Sending facility | MSH:4.1 | ST | R | N | Sending facility name | |
MSH:5 - Receiving application | MSH:5.1 | ST | R | N | Receiving application name | |
MSH:6 - Receiving facility | MSH:6.1 | ST | R | N | Receiving 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 | R | N | Message type. Values SHOULD be from table DDS-HL7v2-MessageType | ||
MSH:9.2 | ID | R | N | Trigger event. Values SHOULD be from table DDS-HL7v2-EventType | ||
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. | |
MSH:11 - Processing ID | MSH:11.1 | PT | O | N | In production MUST be "P" | |
MSH:12 - Message version | MSH:12.1 | ID | R | N | The version of HL7 that this message conforms to. MUST be "2.3" |
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 | O | N | The value should be the same as theMSH:9.2 (trigger event) | |
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 from table 0062-EventReason | |
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. This list must include at least both of the following (in order) -
|
|
PID:3.1 | ST | R | Y | Patient ID | ||
PID:3.4 | ST | R | N | Assigning authority | ||
PID:5 - Patient Name | - | - | R | N | ||
PID:5.1 | ST | R | N | Family name | ||
PID:5.2 | ST | O | N | Given name | ||
PID:5.3 | ST | O | N | Middle names | ||
PID:5.5 | 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. If mapping at source then allowed values are from table AdministrativeSex | |
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.5 | ST | O | N | Post code | ||
PID:11.6 | ID | O | N | Country. Values SHOULD be from table 0399-CountryCode | ||
PID:11.7 | ID | O | N | Address usage eg temporary address | ||
PID:11.9 | IS | O | N | County | ||
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 "home" or "mobile" | ||
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 is "work" | ||
PID:15 - Primary language | - | - | O | N | Primary language. This should be the ISO 639-1 code or one of the five communication method extensions defined in the NHS Data Dictionary code set. | |
PID:15.1 | ST | O | N | Primary language. If mapping at source then allowed values are child concepts of the SNOMED CT World Languages concept - 297289008 | World languages (qualifier value) | | ||
PID:17 - Religion | PID:17.1 | IS | O | N | Religion. If mapping at source then allowed values are from RELIGIOUS OR OTHER BELIEF SYSTEM AFFILIATION CODE | |
PID:18 - Patient Account Number | PID:18.1 | ST | C | N | Though officially this field is intended to capture account number it has been repurposed in DDS. It is used to carry the identifier for the episode of care. Simplistically an episode of care encapsulates all of the encounters that a patient may have with a healthcare organisation from the point of referral to the point of discharge.
If the publisher does not have the concept of episode of care then instead this MUST be the same value as that found in PV1.19 - Visit number. If no PV1 segment accompanies this PID segment then PID:18 should not be populated |
|
PID:22 - Ethnic group | - | - | O | N | ||
PID:22.1 | ST | O | N | Ethnicity identifier. If mapping at source then allowed values are from ETHNIC CATEGORY | ||
PID:29 - Patient Death Date and Time | PID:29.1 | TS | C | N | If PID.30:1 is not empty and PID:30.1 == "Y" then PID:29 is mandatory | |
PID:30 - Patient Death Indicator | PID:30.1 | ID | O | N | "Y" or "N" |
PD1 - Patient Additional Demographic
Overview
The PD1 segment contains demographic information about a patient that is likely to change. In the case of DDS is it used to carry GP data.
Definition
Field | Component | Data Type | Optionality | Repeating | Description | Example |
---|---|---|---|---|---|---|
PD1:3 - Patient Primary Facility | - | - | R | N | ||
PD1:3.1 | ST | R | N | name | ||
PD1:3.3 | ST | R | N | ODS code | ||
PD1:4 - Patient Primary Care Provider Name and ID No | - | - | R | N | ||
PD1:4.1 | ST | R | N | GMC code | ||
PD1:4.2 | FN | R | N | Family name | ||
PD1:4.3 | ST | R | N | Given name | ||
PD1:4.6 | ST | O | N | Prefix |
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 | MRG:1.1 | CX | R | N | MUST only contain one value - the patient's local (to the publisher) identifier. | |
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 | - | 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 | R | N | If mapping at source then allowed values are from table PatientClass | |
PV1:3 - Assigned Patient Location | PV1:3.1 | IS | R | N | General patient location | |
PV1:4 - Admission Type | PV1:4.1 | ID | O | N | If mapping at source then allowed values are from ADMISSION METHOD | |
PV1:8 - Referring Doctor | - | - | O | N | Referring doctor. If provided, at least the family name must be given. | |
PV1:8.1 | ST | O | N | ID number | ||
PV1:8.2 | ST | O | N | Family Name | ||
PV1:8.3 | ST | O | N | Given Name | ||
PV1:8.6 | ST | O | N | Prefix | ||
PV1:9 - Consulting Doctor | - | - | R | N | Consulting doctor. If provided, at least the family name must be given. | |
PV1:9.1 | ST | R | N | ID number | ||
PV1:9.2 | ST | R | N | Family Name | ||
PV1:9.3 | ST | O | N | Given Name | ||
PV1:9.6 | ST | O | N | Prefix | ||
PV1:10 - Hospital Service | PV1:10.1 | IS | R | N | If mapping at source then allowed values are from TREATMENT FUNCTION CODE | |
PV1:14 - Admit source | PV1:14.1 | IS | O | N | If mapping at source then allowed values are from SOURCE OF ADMISSION | |
PV1:18 - Patient Type | PV1:18.1 | IS | R | N | If mapping at source then allowed values are from table HL7v3-EncounterType | |
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 | If mapping at source then allowed values are from DISCHARGE METHOD | |
PV1:37 - Discharged to Location | PV1:37.1 | ID | O | N | If mapping at source then allowed values are from DISCHARGE DESTINATION | |
PV1:44 - Admit Date/Time | PV1:44.1 | TS | C | N | Admit timestamp | |
PV1:45 - Discharge Date/Time | PV1:45.1 | TS | O | N | Discharge timestamp |
NTE - Notes and Comments
Overview
The NTE segment is used to hold comments [TODO - are there any constraints on the size of an individual comment]
Definition
Field | Component | Data Type | Optionality | Repeating | Description | Example |
---|---|---|---|---|---|---|
NTE:3 - Comment | NTE:3.1 | FT | R | Y | Comment |
ORC - Common Order
Overview
The ORC segment is used to carry information that is common across an order
Definition
Field | Component | Data Type | Optionality | Repeating | Description | Example |
---|---|---|---|---|---|---|
ORC:3 - Filler Order number | ORC:3.1 | ST | O | N | This string must uniquely identify an order from other orders in the filling system | |
ORC:21 - Ordering Facility name | - | - | R | N | Used to differentiate between different sources of result data (eg GP vs acute settings) | |
ORC:21.1 | ST | O | N | Facility name | ||
ORC:21.3 | ST | R | N | Facility ID. Note that this MUST be the ODS code of the ordering facility | ||
ORC:21.7 | ID | R | N | Facility ID type. Values SHOULD be from table 0074-DiagnosticServiceSectionID |
OBR - Observation Request
Overview
DDS interprets an OBR as either representing a single textual laboratory report or a collection of individual test results. More information can be found in the ORU R01 - Unsolicited Observation definition.
Field | Component | Data Type | Optionality | Repeating | Description | Example |
---|---|---|---|---|---|---|
OBR:3 - Filler Order number | OBR:3.1 | ST | C | N | OBR:3-filler order number is identical to ORC:3-filler order number.
If the filler order number is not present in the ORC, it must be present in the associated OBR |
|
OBR:4 - Universal Service Identifier | - | - | R | N | ||
OBR:4.1 | ST | R | N | Service Identifier | ||
OBR:4.2 | ST | R | N | Service name | ||
OBR:4.3 | ID | R | N | Service coding system. Allowed values are [TODO] | ||
OBR:4.5 | ST | O | N | Alternative service name | ||
OBR:7 - Observation date/time | ORC:7.1 | TS | C | N | Observation timestamp. If this is not present, OBX:14 is used instead. It is an error for neither to be provided. | |
OBR:16 - Ordered by | O | N | If provided, at least the family name must be given. | |||
OBR:16.2 | ST | R | N | Family Name | ||
OBR:16.3 | ST | O | N | Given Name | ||
OBR:16.4 | ST | O | N | Middle Names | ||
OBR:16.6 | ST | O | N | Prefix | ||
OBR:24 - Discipline | OBR:24.1 | ID | O | N | This field is the section of the diagnostic service where the observation was performed.
If the study was performed by an outside service, the identification of that service should be recorded here. Values SHOULD be from table 0074-DiagnosticServiceSectionID |
|
OBR:25 - Result status | OBR:25.1 | ID | O | N | 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. Values SHOULD be from table DDS-ResultStatus |
Definition
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:1 - Set ID | OBX:1.1 | SI | R | N | Sequence number for OBX. Must be unique under its associated OBR segment | ||
OBX:2 - Value Type | OBX:2.1 | ID | R | N | Values SHOULD be from table 0125-ValueType | ||
OBX:3 - Observation Identifier | - | CWE | R | Y | If this is a textual report, this value will be overridden by OBR:4. Otherwise this value must be provided. | ||
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. At the time of writing the acceptable code systems are still being defined though there is an aspiration to adopt the National Unified Test List where appropriate. Note that this does not exclude the adoption of more appropriate code systems depending upon the nature of the observation | |||
OBX:3.2 | ST | O | N | Test Name | |||
OBX:3.3 | ST | C | N | Test coding system. If this is a textual report, this value will be overridden by OBR:4.3. | |||
OBX:5 - Observation Value | OBX:5.1 | VARIES | R | N | Value. Type MUST match OBX:2.1 | ||
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 | OBX:7.1 | ST | O | N | Reference range. Can be used to convey low value, high value and normal value. DDS will parse the data into one or more of these categories depending upon how the reference range value is formatted
|
See table below for examples | |
OBX:8 - Abnormal flag | - | - | C | N | To flag the result as abnormal (e.g., High, Low) this flag MUST be sent in the message | ||
OBX:8.1 | R | N | Flag ID - Values SHOULD be from table http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation | ||||
OBX:8.2 | O | Flag name | |||||
OBX:8.3 | O | N | Flag coding system - If present then SHOULD be "http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation" | ||||
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. Values SHOULD be from table DDS-ResultStatus | ||
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. | ||
OBX:16 - Responsible Observer | O | N | If provided, at least the family name must be given. | ||||
OBX:16.2 | ST | R | N | Family Name | |||
OBX:16.3 | ST | O | N | Given Name | |||
OBX:16.4 | ST | O | N | Middle Names | |||
OBX:16.6 | ST | O | N | Prefix |
Reference range
OBX:7 value | Low value | High value | Normal value |
---|---|---|---|
"3-4" | 3 | 4 | - |
"3--4" | 3 | -4 | - |
"-3-4" | -3 | 4 | - |
"3 - 4" | 3 | 4 | - |
" 5" | - | - | 5 |
">5" | - | - | ">5" |
"POS" | - | - | "POS" |