Publisher API HL7 Messages - Revision history

AdminJo at 10:01, 21 May 2025

2025-05-21T10:01:47Z

← Older revision		Revision as of 10:01, 21 May 2025
Line 1,072:		Line 1,072:
	<u>Single textual report with multiple image attachments</u>		<u>Single textual report with multiple image attachments</u>

	If an OBX segments contains an image (OBX:2.1 = "ED" and OBX:5.2 = "image") then the image will be extracted and added as an attachment to the textual report. The ordering of the OBX segments containing images is not meaningful to ~~DDS~~.		If an OBX segments contains an image (OBX:2.1 = "ED" and OBX:5.2 = "image") then the image will be extracted and added as an attachment to the textual report. The ordering of the OBX segments containing images is not meaningful to the VHP.

	An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by the VHP and it will concatenate them to form a single textual report. Note that each segment will be delineated by a UNIX line feed character (escape sequence - \n Unicode character - U+000A).		An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by the VHP and it will concatenate them to form a single textual report. Note that each segment will be delineated by a UNIX line feed character (escape sequence - \n Unicode character - U+000A).

AdminJo at 10:00, 21 May 2025

2025-05-21T10:00:46Z

← Older revision		Revision as of 10:00, 21 May 2025
Line 943:		Line 943:

	==== Interpretation of observations ====		==== Interpretation of observations ====
	Depending upon the structure of the R01, ~~DDS~~ will interpret the message in one of three ways.		Depending upon the structure of the R01, the VHP will interpret the message in one of three ways.

	===== Single textual laboratory report =====		===== Single textual laboratory report =====
Line 957:		Line 957:

	===== Collection of individual test results =====		===== Collection of individual test results =====
	If an OBR group does not meet the criteria for a single textual laboratory report then ~~DDS~~ assumes it to contain a collection of individual test results. ~~DDS~~ considers the comments for a given test result (OBX) to be the combination of the comments (NTE segments) associated directly with the OBR plus the comments (NTE segments) associated directly with the test result.		If an OBR group does not meet the criteria for a single textual laboratory report then the VHP assumes it to contain a collection of individual test results. The VHP considers the comments for a given test result (OBX) to be the combination of the comments (NTE segments) associated directly with the OBR plus the comments (NTE segments) associated directly with the test result.

	'''Embedded PDF result'''		'''Embedded PDF result'''
Line 964:		Line 964:

	===== NTE - Notes and Comments =====		===== NTE - Notes and Comments =====
	~~DDS~~ will interpret comments differently depending on where in the R01 message an NTE segment is found -		The VHP will interpret comments differently depending on where in the R01 message an NTE segment is found -

	* NTE segments that immediately follow the OBR segment are considered by ~~DDS~~ to apply to all results in the R01 message		* NTE segments that immediately follow the OBR segment are considered by the VHP to apply to all results in the R01 message
	* NTE segments immediately following an OBX segment are considered by ~~DDS~~ to apply only to the immediately preceding result		* NTE segments immediately following an OBX segment are considered by the VHP to apply only to the immediately preceding result

	=== Definition ===		=== Definition ===
Line 974:		Line 974:
	OBX - Observation		OBX - Observation

	Refines the [[Publisher API HL7 Segments#OBX%20-%20Observation%20or%20result\|~~DDS~~ standard definition of OBX]] -		Refines the [[Publisher API HL7 Segments#OBX%20-%20Observation%20or%20result\|VHP standard definition of OBX]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 989:		Line 989:
	\|R		\|R
	\|N		\|N
	\|~~DDS~~ will only accept a measurement if this value is "SNOMED-CT"		\|The VHP will only accept a measurement if this value is "SNOMED-CT"
	\|<nowiki>26604007 \| Complete blood count (procedure)</nowiki>		\|<nowiki>26604007 \| Complete blood count (procedure)</nowiki>
	\|-		\|-
Line 1,038:		Line 1,038:
	<u>ORC - Common Order</u>		<u>ORC - Common Order</u>

	Refines the [[Publisher API HL7 Segments#ORC - Common Order\|~~DDS~~ standard definition of ORC]] -		Refines the [[Publisher API HL7 Segments#ORC - Common Order\|VHP standard definition of ORC]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 1,063:		Line 1,063:

	==== Interpretation of observations ====		==== Interpretation of observations ====
	~~DDS~~ can interpret a radiology observation in three different ways -		The VHP can interpret a radiology observation in three different ways -

	# as a single textual report with multiple image attachments		# as a single textual report with multiple image attachments
Line 1,074:		Line 1,074:
	If an OBX segments contains an image (OBX:2.1 = "ED" and OBX:5.2 = "image") then the image will be extracted and added as an attachment to the textual report. The ordering of the OBX segments containing images is not meaningful to DDS.		If an OBX segments contains an image (OBX:2.1 = "ED" and OBX:5.2 = "image") then the image will be extracted and added as an attachment to the textual report. The ordering of the OBX segments containing images is not meaningful to DDS.

	An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by ~~DDS~~ and it will concatenate them to form a single textual report. Note that each segment will be delineated by a UNIX line feed character (escape sequence - \n Unicode character - U+000A).		An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by the VHP and it will concatenate them to form a single textual report. Note that each segment will be delineated by a UNIX line feed character (escape sequence - \n Unicode character - U+000A).

	<u>Embedded PDF report</u>		<u>Embedded PDF report</u>

	~~DDS~~ interprets a radiology observation in this way if the following is true -		The VHP interprets a radiology observation in this way if the following is true -
	OBX:2.1 = "ED" and OBX:5.2 = "document" and OBX:5.3 = "pdf"		OBX:2.1 = "ED" and OBX:5.2 = "document" and OBX:5.3 = "pdf"
	An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by ~~DDS~~ and it will concatenate them to form a narrative block that will be associated with the PDF element of the observation.		An NTE segment or an OBX segment that does not hold an image is considered to contain a portion of the report. The ordering of these segments will be respected by the VHP and it will concatenate them to form a narrative block that will be associated with the PDF element of the observation.

	=== Definition ===		=== Definition ===
Line 1,087:		Line 1,087:
	<u>OBX - Observation</u>		<u>OBX - Observation</u>

	Refines the [[Publisher API HL7 Segments#OBX - Observation or result\|~~DDS~~ standard definition of OBX]] -		Refines the [[Publisher API HL7 Segments#OBX - Observation or result\|VHP standard definition of OBX]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field

AdminJo at 09:57, 21 May 2025

2025-05-21T09:57:28Z

← Older revision		Revision as of 09:57, 21 May 2025
Line 940:		Line 940:

	=== Overview ===		=== Overview ===
	This message is used to transmit unsolicited laboratory results into ~~DDS~~. [TODO - how to differentiate path from rad results?]		This message is used to transmit unsolicited laboratory results into the VHP. [TODO - how to differentiate path from rad results?]

	==== Interpretation of observations ====		==== Interpretation of observations ====

AdminJo at 09:55, 21 May 2025

2025-05-21T09:55:52Z

← Older revision		Revision as of 09:55, 21 May 2025
Line 621:		Line 621:
	* confirm behaviour if A08 is sent an no encounter exists		* confirm behaviour if A08 is sent an no encounter exists
	* confirm what happens to the previous version of the updated data (is it retained and retrievable?)		* confirm what happens to the previous version of the updated data (is it retained and retrievable?)
	* What are the rules around triggered an update, for example if a field is left blank in PV1 does that mean that the existing data in ~~DDS~~ will not be updated?		* What are the rules around triggered an update, for example if a field is left blank in PV1 does that mean that the existing data in the VHP will not be updated?
	* is it only the PV1 segment that is used as a source data to update i.e. the PID segment is ignored?		* is it only the PV1 segment that is used as a source data to update i.e. the PID segment is ignored?

Line 651:		Line 651:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 875:		Line 875:

	=== Overview ===		=== Overview ===
	~~DDS~~ supports two kinds of Observation -		The VHP supports two kinds of Observation -

	*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation .28Laboratory.29\|Laboratory observation]]		*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation .28Laboratory.29\|Laboratory observation]]
	*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation .28Radiology.29\|Radiology Observation]]		*[[Publisher API HL7 Messages#ORU R01: Unsolicited Observation .28Radiology.29\|Radiology Observation]]

	~~DDS~~ differentiates these by examining the value of MSH:3.1. For Radiology observations that value MUST be "RADIOLOGY". Any other value is interpreted as a Laboratory observation.		The VHP differentiates these by examining the value of MSH:3.1. For Radiology observations that value MUST be "RADIOLOGY". Any other value is interpreted as a Laboratory observation.

	==== Payload size constraints ====		==== Payload size constraints ====
	The specification does allow for binary payloads to be carried within the R01 message however it should be noted that publishers should verify that the inbound (to ~~DDS~~) interface that is being integrated with is capable of receiving that type of payload.		The specification does allow for binary payloads to be carried within the R01 message however it should be noted that publishers should verify that the inbound (to the VHP) interface that is being integrated with is capable of receiving that type of payload.

	At the time of writing (Oct 2021) the ~~DDS~~ has a limit on the size of message that can be processed. This limitation is as a result of the queuing technology ([https://www.rabbitmq.com/ RabbitMQ]) that underpins the inbound message processing pipeline. There is a limit to the size of an individual message that can be processed hence it might be that binary payloads are not supported by the implementation at the time of integration.		At the time of writing (Oct 2021) the VHP has a limit on the size of message that can be processed. This limitation is as a result of the queuing technology ([https://www.rabbitmq.com/ RabbitMQ]) that underpins the inbound message processing pipeline. There is a limit to the size of an individual message that can be processed hence it might be that binary payloads are not supported by the implementation at the time of integration.

	'''Formatting of textual results'''		'''Formatting of textual results'''

AdminJo at 09:53, 21 May 2025

2025-05-21T09:53:10Z

← Older revision		Revision as of 09:53, 21 May 2025
Line 192:		Line 192:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 274:		Line 274:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 352:		Line 352:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 424:		Line 424:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 496:		Line 496:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field
Line 572:		Line 572:
	<u>PV1 - Patient Visit</u>		<u>PV1 - Patient Visit</u>

	Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|~~DDS~~ standard definition of PV1]] -		Refines the [[Publisher API HL7 Segments#PV1 - Patient Visit\|VHP standard definition of PV1]] -
	{\| class="wikitable"		{\| class="wikitable"
	!Field		!Field

AdminJo at 09:49, 21 May 2025

2025-05-21T09:49:29Z

← Older revision		Revision as of 09:49, 21 May 2025
Line 51:		Line 51:

	== ACK: General acknowledgement ==		== ACK: General acknowledgement ==
	This message is used to indicate whether or not ~~DDS~~ has successfully received an inbound message or not.		This message is used to indicate whether or not the VHP has successfully received an inbound message or not.

	The value of MSH:9.2 (trigger event) is always the same as the trigger event in the inbound message that is being acknowledged.		The value of MSH:9.2 (trigger event) is always the same as the trigger event in the inbound message that is being acknowledged.
Line 70:		Line 70:

	=== Overview ===		=== Overview ===
	This message will create a new patient record within ~~DDS~~. [TODO - what happens if the record exists - will this act as A31?]		This message will create a new patient record within the VHP. [TODO - what happens if the record exists - will this act as A31?]

	=== Definition ===		=== Definition ===
Line 100:		Line 100:

	=== Overview ===		=== Overview ===
	This message will update an existing patient record within ~~DDS~~. [TODO - what happens if the record does not exist - will this act as A28?]		This message will update an existing patient record within the VHP. [TODO - what happens if the record does not exist - will this act as A28?]

	=== Definition ===		=== Definition ===

AdminJo at 09:47, 21 May 2025

2025-05-21T09:47:49Z

← Older revision		Revision as of 09:47, 21 May 2025
Line 1:		Line 1:
	This page summarises the messages that are currently supported by ~~DDS~~		This page summarises the messages that are currently supported by the Voror Health Platform (VHP).

	'''Acknowledgement'''		'''Acknowledgement'''
Line 30:		Line 30:

	== Standard segments ==		== Standard segments ==
	See [[Publisher API HL7 Segments]] for definitions of the segments that are used across the ~~DDS~~ message set. Note that in many cases individual messages refine the standard definitions. Where this is the case it is made clear in the definition of each message below.		See [[Publisher API HL7 Segments]] for definitions of the segments that are used across the VHP message set. Note that in many cases individual messages refine the standard definitions. Where this is the case it is made clear in the definition of each message below.

	== Coded field mapping ==		== Coded field mapping ==
	~~DDS~~ has a core set of codes for various concepts. A scheme must be defined that maps your local codes on to their ~~DDS~~ core equivalents		The VHP has a core set of codes for various concepts. A scheme must be defined that maps your local codes on to their VHP core equivalents.

	As a publisher you have two options open to you in terms of how coded values are mapped -		As a publisher you have two options open to you in terms of how coded values are mapped:

	# Map at source		# Map at source
	# Map in ~~DDS~~		# Map in the VHP

	'''Map at source'''		'''Map at source'''

	Here the data that is published already contains the core ~~DDS~~ codes i.e. the mapping scheme is applied in ''your'' system. The onus is on you to maintain the mapping schemes within your local estate.		Here the data that is published already contains the core VHP codes i.e. the mapping scheme is applied in ''your'' system. The onus is on you to maintain the mapping schemes within your local estate.

	'''Map in ~~DDS~~'''		'''Map in the VHP'''

	Here the mapping scheme is applied when your data reaches the ~~DDS~~ i.e. local codes leave your system and are pushed in to ~~DDS~~. The mapping scheme is maintained within ~~DDS~~ and ~~DDS~~ applies that scheme to the messages it receives.		Here the mapping scheme is applied when your data reaches the VHP i.e. local codes leave your system and are pushed in to VHP. The mapping scheme is maintained within the VHP and the VHP applies that scheme to the messages it receives.

	Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core ~~DDS~~ codes. The distinction is around when and where the mapping is applied.		Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core VHP codes. The distinction is around when and where the mapping is applied.

	== ACK: General acknowledgement ==		== ACK: General acknowledgement ==

JoC: Undo revision 6501 by JoC (talk)

2023-07-27T15:03:52Z

Undo revision 6501 by JoC (talk)

← Older revision		Revision as of 15:03, 27 July 2023
Line 49:		Line 49:

	Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core DDS codes. The distinction is around when and where the mapping is applied.		Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core DDS codes. The distinction is around when and where the mapping is applied.

	~~Acknowledgement~~

	== ACK: General acknowledgement ==		== ACK: General acknowledgement ==

JoC at 15:01, 27 July 2023

2023-07-27T15:01:18Z

← Older revision		Revision as of 15:01, 27 July 2023
Line 49:		Line 49:

	Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core DDS codes. The distinction is around when and where the mapping is applied.		Note that in both cases there is still an onus on the publisher to create the mapping scheme from local to core DDS codes. The distinction is around when and where the mapping is applied.

			Acknowledgement

	== ACK: General acknowledgement ==		== ACK: General acknowledgement ==

JoC at 14:58, 27 July 2023

2023-07-27T14:58:56Z

← Older revision		Revision as of 14:58, 27 July 2023
Line 1:		Line 1:

	This page summarises the messages that are currently supported by DDS		This page summarises the messages that are currently supported by DDS