Publisher API HL7 Segments: Difference between revisions

From Discovery Data Service
Jump to navigation Jump to search
No edit summary
(Changes to PID:18 from NWL to ensure NWL use with Millennium sources is documented and the actual relationship with PV1:19 is shown)
 
(78 intermediate revisions by 3 users 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 [[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 ==
 
=== 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 ===
{| class="wikitable"
!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 [[Publisher API Code Sets#DDS-HL7v2-AckCode|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 ==
== MSH - Message Header ==
Line 6: Line 65:
=== Overview ===
=== Overview ===
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message
The MSH segment defines the intent, source, destination, and some specifics of the syntax of a message
=== Code Meanings ===
{| class="wikitable"
|code
|meaning
|-
|O
|optional
|-
|R
|required
|-
|TS
|time stamp
|-
|ST
|string
|-
|CX
|extended  composite id with check digit
|-
|N
|no repeats
|-
|R
|multiple  repeats
|}


=== Definition ===
=== Definition ===
Line 16: Line 102:
!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
|O
|R
|N
|N
|Sending application name
|Sending application name
Line 28: Line 130:
|MSH:4.1
|MSH:4.1
|ST
|ST
|O
|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 52: Line 170:
|MSH:9.1
|MSH:9.1
|ID
|ID
|O
|R
|N
|N
|Message type. Allowed values are [TODO]
|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
|C
|R
|N
|N
|Trigger event. Allowed values are [TODO]
|Trigger event. Values SHOULD be from table [[Publisher API Code Sets#DDS-HL7v2-EventType|DDS-HL7v2-EventType]]
|
|
|-
|-
Line 70: Line 188:
|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 91: Line 225:
|EVN:1.1
|EVN:1.1
|ID
|ID
|X
|O
|N
|N
|Avoid populating this field. Instead use the second component (trigger event) of MSH-9-message type to transmit event type code information.
|The value should be the same as theMSH:9.2 (trigger event)  
|
|
|-
|-
Line 117: Line 251:
|O
|O
|N
|N
|The reason for this event. Allowed values are [TODO]. CWE data type - (http://www.hl7.eu/refactored/dtCWE.html)
|The reason for this event. Allowed values are from table [[Publisher API Code Sets#0062-EventReason|0062-EventReason]]
|
|
|-
|-
Line 159: Line 293:
|EVN:6.1
|EVN:6.1
|TS
|TS
|O
|R
|N
|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.
|This field contains the date/time that the event actually occurred. For example, on a transfer (A02 (transfer a patient)), this field must contain the date/time the patient was actually transferred. On a cancellation event, this field should contain the date/time that the event being cancelled occurred.
|
|
|}
|}
Line 188: Line 322:
|
|
|-
|-
| rowspan="4" |PID:3 - Patient Identifier List
| rowspan="3" |PID:3 - Patient Identifier List
| -
| -
| -
| -
|R
|R
|N
|Y
|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"
|Patient Identifier List to include
 
Always:
 
* the patient's main local (to the publisher) identifier
 
Optionally:
 
* alternative MRNs
* the patient's NHS number
|
|
|-
|-
Line 206: Line 349:
|ST
|ST
|R
|R
|N
|Y
|Assigning authority
|Assigning authority
|
 
|-
* "MRN" - for the patient's main local (to the publisher) identifier
|PID:3.5
* "ALT_MRN" - for alternative MRNs
|ST
* "NHS" - for NHS Number
|O
|<nowiki>PID|1| |01529577^^^MRN~4111111998^^^NHS~E02055831^^^ALT_MRN~M2600001^^^ALT_MRN</nowiki>
|N
|Type code
|
|-
|-
| rowspan="5" |PID:5 - Patient Name
| rowspan="5" |PID:5 - Patient Name
| -
| -
| -
| -
|O
|R
|N
|N
|Though optional it is useful to provide all specified components to reduce the chances of patient confusion
|
|
|
|-
|-
|PID:5.1
|PID:5.1
|ST
|ST
|O
|R
|N
|N
|Family name
|Family name
Line 246: Line 386:
|
|
|-
|-
|PID:5.4
|PID:5.5
|ST
|ST
|O
|O
Line 266: Line 406:
|R
|R
|N
|N
|Administrative sex. Allowed values are from table 0001-AdministrativeSex
|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]]
|
|-
|PID:10
|PID:10.1
|IS
|O
|N
|Race. Allowed values are [TODO]
|
|
|-
|-
| rowspan="7" |PID:11 - Patient Address
| rowspan="8" |PID:11 - Patient Address
| -
| -
| -
| -
Line 306: Line 438:
|
|
|-
|-
|PID:11.4
|PID:11.5
|ST
|ST
|O
|O
|N
|N
|State or Province
|Post code
|
|
|-
|-
|PID:11.5
|PID:11.6
|ST
|ID
|O
|O
|N
|N
|Post code
|Country. Values SHOULD be from table [[Publisher API Code Sets#0399-CountryCode|0399-CountryCode]]
|
|
|-
|-
|PID:11.6
|PID:11.7
|ID
|ID
|O
|O
|N
|N
|Country. Allowed values are [TODO]
|Address usage eg temporary address
|
|
|-
|-
| rowspan="4" |PID:13 - Home contact information
|PID:11.9
|IS
|O
|N
|County
|
|-
| rowspan="3" |PID:13 - Home contact information
| -
| -
| -
| -
Line 346: Line 485:
|O
|O
|N
|N
|Contact use code. Allowed values are [TODO]
|Contact use code. Allowed values are "home" or "mobile"
|
|
|-
|-
|PID:13.4
| rowspan="3" |PID:14 - Work contact information
|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.
|
|-
| rowspan="4" |PID:14 - Work contact information
| -
| -
|O
|O
|N
|N
Line 375: Line 507:
|O
|O
|N
|N
|Contact use code. Allowed values are [TODO]
|Contact use code. Allowed values is "work"
|
|
|-
|-
|PID:14.4
| rowspan="2" |PID:15 - Primary language
|ST
|  -
| -
|O
|O
|N
|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.
|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.
|
|
|-
|-
| rowspan="5" |PID:15 - Primary language
|PID:15.1
| -
|ST
| -
|O
|O
|N
|N
|Primary language. This should be the ISO 639-1 code.
|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:15.1
|PID:17 - Religion
|ST
|PID:17.1
|IS
|O
|O
|N
|N
|Primary language. Allowed values are [TODO]
|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:15.3
|PID:18 - Patient Account Number
|PID:18.1
|ST
|ST
|C
|C
|N
|N
|Name of coding system. Required if PID:15.4 is present. Must be http://terminology.hl7.org/CodeSystem/iso639-1
|This field is used by DDS as the identifier for the episode of care if the PV1.19 field is not populated. If the PV1.19 field is populated then PID:18 may be locally repurposed (eg. at NWL it is used to supply HIE with the FIN number for de-duplication of Millennium sourced visits) An episode of care encapsulates all of the encounters that a patient has with a healthcare organisation from the point of referral to the point of discharge. If no PV1 segment accompanies this PID segment then PID:18 should not be populated
|http://terminology.hl7.org/CodeSystem/iso639-1
|Example 1 (PV1 present and PID:18 populated with fin number):
 
MSH|^~\&|CERNER|RQM|DISCOVERY|COMMUNITY|20220706152033||ADT^A01|Q1128671561T1226605750X164711A1148|P|2.3
 
EVN|A01|20220706151800|||^^^^^^^^^|20220706151800
 
PID|||90092146^^^MRN^MRN~9438453504^^^NHS^NH{status:01}||YYYCWTEST^TESTIMUPDATE^INTERFACE^^^^CURRENT||19801020|M|||Address line 1^^LONDON^^^GBR^HOME^||^||5|M|JUDAISM|61920590^^^RQM Encounter Num^FINNBR||||G||||||DZA||
 
PD1|||^^|^^^^^^^^
 
PV1||I|CW DEV^Bay B^Bed 04^CWH^^BED^CW MAIN|22|...
 
 
 
Example 2 (PV1 absent, so PID:18 unpopulated)
 
MSH|^~\&|CERNER|RQM|DISCOVERY|COMMUNITY|20220706093029||ADT^A28|Q1128670316T1226604112X162958A1148|P|2.3
 
EVN|A28|20220706093029|||^^^^^^^^^|20220706093029
 
PID|||90092136^^^MRN^MRN||YYYCWTEST^TESTIM^TESTING^^^^CURRENT||19851015|M|||Address line 1^^^^^GBR^HOME^||^|||M|CHRISTIAN|||||P||||||||
 
PD1|||...
|-
|-
|PID:15.4
|PID:22 - Ethnic group
|ST
| -
| -
|O
|O
|N
|N
|Primary language. Allowed values are [TODO]
|
|
|
|-
|-
|PID:15.6
|
|PID:22.1
|ST
|ST
|C
|O
|N
|N
|Name of coding system. Required if PID:15.4 is present. Must be http://terminology.hl7.org/CodeSystem/iso639-1
|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]
|http://terminology.hl7.org/CodeSystem/iso639-1
|
|-
|-
|PID:29
|PID:29 - Patient Death Date and Time
|PID:29.1
|TS
|TS
|O
|C
|N
|N
|Death timestamp. If the death timestamp is set, then "Y" is inferred for death indicator in PID:30, regardless of its actual value.
|If PID.30:1 is not empty and PID:30.1 == "Y" then PID:29 is mandatory
|
|
|
|-
|-
|PID:30
|PID:30 - Patient Death Indicator
|
|PID:30.1
|TS
|ID
|O
|O
|N
|N
|Death indicator.  If this is "N" but a date of death is provided in PID:29 then [TODO - DDS error behaviour]
|"Y" or "N"
|
|
|}
|}


== MRG - Merge Patient Information ==
== PD1 - Patient Additional Demographic ==


=== Overview ===
=== Overview ===
The MRG segment is used by DDS to support merging of patient identifiers
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 453: Line 611:
!Example
!Example
|-
|-
| rowspan="4" |MRG:1 - Prior Patient Identifier List
| rowspan="3" |PD1:3 - Patient Primary Facility
| -
| -
| -
| -
Line 461: Line 619:
|
|
|-
|-
|MRG:1.1
|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
|Y
|N
|Patient ID
|GMC code
|
|-
|PD1:4.2
|FN
|R
|N
|Family name
|
|
|-
|-
|MRG:1.4
|PD1:4.3
|ST
|ST
|R
|R
|N
|N
|Assigning authority
|Given name
|
|
|-
|-
|MRG:1.5
|PD1:4.6
|ST
|ST
|O
|O
|N
|N
|Type code
|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
| -
|  -
| -
| -
|Patient Identifier List to include
 
Always
 
* the patient's main local (to the publisher) identifier
 
Optionally
 
* alternative MRNs
* the patient's NHS number
|
|-
|
|MRG:1.1
|CX
|R
|Y
|The patient's identifier
|
|-
|
|MRG:1.4
|CX
|R
|N
|Assigning authority
 
* “MRN” – for the patient's main local (to the publisher) identifier
* “ALT_MRN” – for alternative MRNs
* “NHS” for NHS number
|
|
|-
|-
Line 500: Line 739:
|MRG:4 - Prior Patient ID
|MRG:4 - Prior Patient ID
|
|
|CX
| -
|X
|X
|N
|N
Line 523: Line 762:
|-
|-
|MRG:7 - Prior Patient Name
|MRG:7 - Prior Patient Name
| -
| -
| XPN
| XPN
|X
|X
Line 549: Line 788:
|PV1:2.1
|PV1:2.1
|ID
|ID
|O
|R
|N
|N
|Allowed values are [TODO]
|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.9
|PV1:3.1
|ST
|IS
|O
|R
|N
|N
|Free text description of the location
|General patient location
|
|
|-
|-
Line 567: Line 806:
|O
|O
|N
|N
|Allowed values are [TODO]
|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:6 - Prior Patient Location
| rowspan="5" |PV1:8 - Referring Doctor
|PV1:6.9
| -
|ST
| -
|O
|O
|N
|N
|Free text description of the location
|Referring doctor. If provided, at least the family name must be given.
|
|-
| rowspan="5" |PV1:7 - Attending Doctor
| -
| -
|O
|N
|Attending doctor. If provided, at least the family name must be given.
|
|
|-
|-
|PV1:7.2
|PV1:8.1
|ST
|R
|N
|Family Name
|
|-
|PV1:7.3
|ST
|ST
|O
|O
|N
|N
|Given Name
|ID number
|
|
|-
|-
|PV1:7.4
|PV1:8.2
|ST
|ST
|O
|O
|N
|Middle Names
|
|-
|PV1:7.6
|ST
|O
|N
|Prefix
|
|-
| rowspan="5" |PV1:8 - Referring Doctor
| -
| -
|O
|N
|Referring doctor. If provided, at least the family name must be given.
|
|-
|PV1:8.2
|ST
|R
|N
|N
|Family Name
|Family Name
Line 634: Line 836:
|N
|N
|Given Name
|Given Name
|
|-
|PV1:8.4
|ST
|O
|N
|Middle Names
|
|
|-
|-
Line 653: Line 848:
| -
| -
| -
| -
|O
|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 670: Line 872:
|N
|N
|Given Name
|Given Name
|
|-
|PV1:9.4
|ST
|O
|N
|Middle Names
|
|
|-
|-
Line 689: Line 884:
|PV1:10.1
|PV1:10.1
|IS
|IS
|O
|R
|N
|N
|Allowed values are [TODO]
|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:13 - Re-admission Indicator
|PV1:14 - Admit source
|PV1:13.1
|PV1:14.1
|IS
|IS
|O
|O
|N
|N
|Allowed values are [TODO]
|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 705: Line 900:
|PV1:18.1
|PV1:18.1
|IS
|IS
|O
|R
|N
|N
|Allowed values are [TODO]
|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 723: Line 918:
|O
|O
|N
|N
|Allowed values are [TODO]
|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 731: Line 926:
|O
|O
|N
|N
|Allowed values are [TODO]
|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 737: Line 932:
|PV1:44.1
|PV1:44.1
|TS
|TS
|O
|C
|N
|N
|Admit timestamp
|Admit timestamp
Line 751: Line 946:
|}
|}


== PV2 - Patient Visit - Additional Information ==
== NTE - Notes and Comments ==


=== Overview ===
=== Overview ===
The PV2 segment is a continuation of the information presented in the PV1 segment
The NTE segment is used to hold comments [TODO - are there any constraints on the size of an individual comment]


=== Definition ===
=== Definition ===
Line 766: Line 961:
!Example
!Example
|-
|-
|PV2:3 - Admit reason
|NTE:3 - Comment
|PV2:3.2
|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 ===
{| class="wikitable"
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|ORC:3 - Filler Order number
|ORC:3.1
|ST
|ST
|O
|O
|N
|N
|Free text description of the reason for admission
|This string must uniquely identify an order from other orders in the filling system
|
|
|-
|-
|PV2:4 - Transfer reason
| rowspan="4" |ORC:21 - Ordering Facility name
|PV2:4.2
| -
| -
|R
|N
|Used to differentiate between different sources of result data (eg GP vs acute settings)
|
|-
|ORC:21.1
|ST
|ST
|O
|O
|N
|N
|Free text description of the reason for transfer
|Facility name
|
|
|-
|-
|PV2:8 - Expected Admit Date/Time
|ORC:21.3
|PV2:8.1
|ST
|TS
|R
|O
|N
|N
|Datetime of when admission is expected
|Facility ID. Note that this MUST be the ODS code of the ordering facility
|
|
|-
|-
|PV2:9 - Expected Discharge Date/Time
|ORC:21.7
|PV2:9.1
|ID
|TS
|R
|O
|N
|N
|Datetime of when discharge is expected
|Facility ID type. Values SHOULD be from table [[Publisher API Code Sets#0074-DiagnosticServiceSectionID|0074-DiagnosticServiceSectionID]]
|
|
|}
|}


== OBX - Observation or result ==
== OBR - Observation Request ==


=== Overview ===
=== Overview ===
The OBX segment can carry an observation about the patient or it can also be used to carry test results.
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 [[Publisher API HL7 Messages#ORU_R01:_Unsolicited_Observation_.28Laboratory.29|ORU R01]] - Unsolicited Observation definition.
 
=== Definition ===
{| class="wikitable"
{| class="wikitable"
!Field
!Field
Line 814: Line 1,036:
!Example
!Example
|-
|-
|OBX:2 - Value Type
|OBR:3 - Filler Order number
|OBX:2.1
|OBR:3.1
|ID
|ST
|O
|C
|N
|N
|Allowed values are [TODO]
|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
|
|
|-
|-
| rowspan="4" |OBX:3 - Observation Identifier
| rowspan="5" |OBR:4 - Universal Service Identifier
| -
| -
| -
| -
|R
|R
|Y
|N
|
|
|
|
|-
|-
|OBX:3.1
|OBR:4.1
|ST
|ST
|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.
|Service Identifier
|
|-
|OBX:3.2
|ST
|O
|N
|Test Name
|
|
|-
|-
|OBX:3.3
|OBR:4.2
|ST
|ST
|R
|R
|N
|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"
|Service name
|
|
|-
|-
| rowspan="3" |OBX:5 - Observation Value
|OBR:4.3
| -
|ID
| -
|R
|R
|N
|N
|Test result value. If providing an SN value: OBX-5.1 must be one of: >, <, >=, <=, =. OBX-5.2 must be a number
|Service coding system. Allowed values are [TODO]
|
|
|-
|-
|OBX:5.1
|OBR:4.5
|VARIES
|ST
|R
|O
|N
|N
|Value or comparator
|Alternative service name
|
|
|-
|-
|OBX:5.2
|OBR:7 - Observation date/time
|VARIES
|ORC:7.1
|TS
|C
|C
|N
|N
|Value. Required if providing SN
|Observation timestamp. If this is not present, OBX:14 is used instead. It is an error for neither to be provided.
|
|
|-
|-
| rowspan="4" |OBX:6 - Observation Units
| rowspan="5" |OBR:16 - Ordered by
| -
|
| -
|
|O
|O
|N
|N
|
|If provided, at least the family name must be given.
|
|
|-
|-
|OBX:6.1
|OBR:16.2
|ST
|ST
|R
|R
|N
|N
|Unit ID.
|Family Name
|
|
|-
|-
|OBX:6.2
|OBR:16.3
|ST
|ST
|O
|O
|N
|N
|Unit Name
|Given Name
|
|
|-
|-
|OBX:6.3
|OBR:16.4
|ST
|ST
|R
|O
|N
|N
|Unit coding system
|Middle Names
|
|
|-
|-
|OBX:7
|OBR:16.6
|ST
|ST
|O
|O
|N
|N
|Reference range
|Prefix
|
|
|
|-
|-
|OBX:11
|OBR:24 - Discipline
|ST
|OBR:24.1
|ID
|O
|O
|N
|N
|Result status
|This field is the section of the diagnostic service where the observation was performed.
|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.
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]]
|
|
|-
|-
|OBX:13
|OBR:25 - Result status
|ST
|OBR:25.1
|ID
|O
|O
|N
|N
|Custom access rules
|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]]
|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 ==
=== Definition ===
 
== OBX - Observation or result ==


=== Overview ===
=== Overview ===
Each AL1 segment describes a single patient allergy.
The OBX segment can carry an observation about the patient or it can also be used to carry test results.


=== Definition ===
=== Definition ===
Line 950: Line 1,160:
!Example
!Example
|-
|-
|AL1:2 - Allergy type
|OBX:1 - Set ID
|AL1:2.1
|OBX:1.1
|IS
|SI
|O
|R
|N
|Sequence number for OBX. Must be unique under its associated OBR segment
|
|-
|OBX:2 - Value Type
|OBX:2.1
|ID
|R
|N
|N
|Allowed values are [TODO]
|Values SHOULD be from table [[Publisher API Code Sets#0125-ValueType|0125-ValueType]]
|
|
|-
|-
| rowspan="4" |AL1:3 - Allergy code/description
| rowspan="4" |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
|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. 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
|
|
|-
|-
|AL1:3.1
|OBX:3.2
|ST
|ST
|O
|O
|N
|N
|Allergy ID.
|Test Name
|
|
|-
|-
|AL1:3.2
|OBX:3.3
|ST
|ST
|C
|C
|N
|N
|Allergy Name. If AL1:3.1 is not provided then Allergy name is required
|Test coding system. If this is a textual report, this value will be overridden by OBR:4.3.  
|
|
|-
|-
|AL1:3.3
|OBX:5 - Observation Value
|ST
| OBX:5.1
|C
| VARIES
|R
|N
|N
|Allergy coding system. If AL1:3.1 is provided then Allergy coding system is required
|Value. Type MUST match OBX:2.1
|
|
|-
|-
|AL1:4 - Allergy severity
| rowspan="4" |OBX:6 - Observation Units
|AL1:4.1
| -
|IS
| -
|O
|O
|N
|N
|Allowed values are [TODO]
|
|
|-
|OBX:6.1
|ST
|R
|N
|Unit ID
|
|
|-
|-
|AL1:5 - Allergy reaction
|OBX:6.2
|AL1:5.1
|ST
|ST
|O
|O
|N
|N
|Unit Name
|
|
|-
|OBX:6.3
|ST
|R
|N
|Unit coding system
|
|
|-
|-
|AL1:6 - Allergy identification date
|OBX:7
|AL1:6.1
|OBX:7.1
|DT
|ST
|O
|O
|N
|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<br />
|
|}


== DG1 - Diagnosis ==
* [low value]"-"[high value]
 
* "<"[Number] (i.e. "less than number")
=== Overview ===
* ">"[Number] (i.e. "greater than number")
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)
* "<="[Number] (i.e. "less than or equal to number")
 
* ">="[Number] (i.e. "greater than or equal to number")
=== Definition ===
* [Alphabetic value indicating normal value]
{| class="wikitable"
|See table below for examples
!Field
!Component
!Data Type
!Optionality
!Repeating
!Description
!Example
|-
|-
| rowspan="4" |DG1:3 - Diagnosis code
| rowspan="4" |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 <nowiki>http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation</nowiki>
|
|-
|OBX:8.2
|
|O
|O
|N
|
|
|Flag name
|
|
|-
|-
|DG1:3.1
|OBX:8.3
|ST
|
|O
|O
|N
|N
|Diagnosis ID.  
|Flag coding system - If present then SHOULD be "<nowiki>http://terminology.hl7.org/ValueSet/v3-ObservationInterpretation</nowiki>"
|
|
|-
|-
|DG1:3.2
|OBX:11
|ST
|ST
|C
|O
|N
|N
|Diagnosis Name. If DG1:3.1 is not provided then Diagnosis name is required
|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 [[Publisher API Code Sets#DDS-ResultStatus|DDS-ResultStatus]]
|
|
|-
|-
|DG1:3.3
|OBX:13
|ST
|ST
|C
|O
|N
|N
|Diagnosis coding system. If DG1:3.1 is provided then Diagnosis coding system is required
|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}
|-
|-
|DG1:4 - Diagnosis description
|OBX:14
|DG1:4.1
|ST
|ST
|C
|C
|N
|N
|If DG1:3 is not provided then DG1.4 is required
|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.
|
|
|
|-
|-
|DG1:5 - Diagnosis data/time
| rowspan="5" |OBX:16 - Responsible Observer
|DG1:5.1
|
|TS
|O
|N
|Datetime of diagnosis
|
|
|-
| rowspan="5" |DG1:16 - Diagnosing Clinician
| -
| -
|O
|O
|N
|N
|Diagnosing Clinician. If provided, at least the family name must be given.
|If provided, at least the family name must be given.
|
|
|-
|-
|DG1:16.2
|OBX:16.2
|ST
|ST
|R
|R
Line 1,087: Line 1,326:
|
|
|-
|-
|DG1:16.3
|OBX:16.3
|ST
|ST
|O
|O
Line 1,094: Line 1,333:
|
|
|-
|-
|DG1:16.4
|OBX:16.4
|ST
|ST
|O
|O
Line 1,101: Line 1,340:
|
|
|-
|-
|DG1:16.6
|OBX:16.6
|ST
|ST
|O
|O
|N
|N
|Prefix
|Prefix
|
|-
|DG1:17 - Diagnosis classification
|DG1:17.1
|IS
|O
|N
|Allowed values are [TODO]
|
|}
|}


== PR1 - Procedures ==
=== Reference range ===
 
=== Overview ===
The PR1 segment contains information relative to various types of procedures that can be performed on a patient.
 
=== Definition ===
<br />
{| class="wikitable"
{| class="wikitable"
!Field
!OBX:7 value
!Component
!Low value
!Data Type
!High value
!Optionality
!Normal value
!Repeating
!Description
!Example
|-
|-
| rowspan="4" |PR1:3 - Procedure code
|"3-4"
|3
|4
| -
| -
|-
|"3--4"
|3
| -4
| -
| -
|O
|N
|
|
|-
|-
|PR1:3.1
|"-3-4"
|ST
| -3
|O
|4
|N
| -
|Procedure ID.
|
|-
|-
|PR1:3.2
|"3 - 4"
|ST
|3
|C
|4
|N
| -
|Procedure Name. If PR1:3.1 is not provided then Procedure name is required
|
|-
|-
|PR1:3.3
|" 5"
|ST
| -
|C
| -
|N
|5
|Procedure coding system. If PR1:3.1 is provided then Procedure coding system is required
|
|-
|-
|PR1:4 - Procedure description
|">5"
|PR1:4.1
| -
|ST
| -
|C
|">5"
|N
|If PR1:3 is not provided then PR1.4 is required
|
|-
|-
|PR1:5 - Procedure data/time
|"POS"
|PR1:5.1
| -
|TS
| -
|O
|"POS"
|N
|}<br />
|Datetime of procedure
|
|-
|PR1:6 - Procedure type
|PR1:6.1
|IS
|R
|N
|Allowed values are [TODO]
|
|}

Latest revision as of 09:04, 27 October 2022

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

Code Meanings

code meaning
O optional
R required
TS time stamp
ST string
CX extended composite id with check digit
N no repeats
R multiple repeats

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 R N This field contains the date/time that the event actually occurred. For example, on a transfer (A02 (transfer a patient)), this field must contain the date/time the patient was actually transferred. On a cancellation event, this field should contain the date/time that the event being cancelled 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 Y Patient Identifier List to include

Always:

  • the patient's main local (to the publisher) identifier

Optionally:

  • alternative MRNs
  • the patient's NHS number
PID:3.1 ST R Y Patient ID
PID:3.4 ST R Y Assigning authority
  • "MRN" - for the patient's main local (to the publisher) identifier
  • "ALT_MRN" - for alternative MRNs
  • "NHS" - for NHS Number
 PID|1| |01529577^^^MRN~4111111998^^^NHS~E02055831^^^ALT_MRN~M2600001^^^ALT_MRN
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 This field is used by DDS as the identifier for the episode of care if the PV1.19 field is not populated. If the PV1.19 field is populated then PID:18 may be locally repurposed (eg. at NWL it is used to supply HIE with the FIN number for de-duplication of Millennium sourced visits) An episode of care encapsulates all of the encounters that a patient has with a healthcare organisation from the point of referral to the point of discharge. If no PV1 segment accompanies this PID segment then PID:18 should not be populated Example 1 (PV1 present and PID:18 populated with fin number):

MSH|^~\&|CERNER|RQM|DISCOVERY|COMMUNITY|20220706152033||ADT^A01|Q1128671561T1226605750X164711A1148|P|2.3

EVN|A01|20220706151800|||^^^^^^^^^|20220706151800

PID|||90092146^^^MRN^MRN~9438453504^^^NHS^NH{status:01}||YYYCWTEST^TESTIMUPDATE^INTERFACE^^^^CURRENT||19801020|M|||Address line 1^^LONDON^^^GBR^HOME^||^||5|M|JUDAISM|61920590^^^RQM Encounter Num^FINNBR||||G||||||DZA||

PD1|||^^|^^^^^^^^

PV1||I|CW DEV^Bay B^Bed 04^CWH^^BED^CW MAIN|22|...


Example 2 (PV1 absent, so PID:18 unpopulated)

MSH|^~\&|CERNER|RQM|DISCOVERY|COMMUNITY|20220706093029||ADT^A28|Q1128670316T1226604112X162958A1148|P|2.3

EVN|A28|20220706093029|||^^^^^^^^^|20220706093029

PID|||90092136^^^MRN^MRN||YYYCWTEST^TESTIM^TESTING^^^^CURRENT||19851015|M|||Address line 1^^^^^GBR^HOME^||^|||M|CHRISTIAN|||||P||||||||

PD1|||...

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 - - - - Patient Identifier List to include

Always

  • the patient's main local (to the publisher) identifier

Optionally

  • alternative MRNs
  • the patient's NHS number
MRG:1.1 CX R Y The patient's identifier
MRG:1.4 CX R N Assigning authority
  • “MRN” – for the patient's main local (to the publisher) identifier
  • “ALT_MRN” – for alternative MRNs
  • “NHS” for NHS number
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
  • [low value]"-"[high value]
  • "<"[Number] (i.e. "less than number")
  • ">"[Number] (i.e. "greater than number")
  • "<="[Number] (i.e. "less than or equal to number")
  • ">="[Number] (i.e. "greater than or equal to number")
  • [Alphabetic value indicating normal value]
 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"


Retrieved from ‘https://wiki.discoverydataservice.org/index.php?title=Publisher_API_HL7_Segments&oldid=6053’