Datatype TQ to ServiceRequest Map - HL7 Version 2 to FHIR v1.0.0

HL7 Version 2 to FHIR
1.0.0 - STU 1 International flag

HL7 Version 2 to FHIR, published by HL7 International / Orders and Observations. This guide is not an authorized publication; it is the continuous build for version 1.0.0 built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/HL7/v2-to-fhir/ and changes regularly. See the Directory of published versions

ConceptMap: Datatype TQ to ServiceRequest Map (Experimental)

Official URL: http://hl7.org/fhir/uv/v2mappings/ConceptMap/datatype-tq-to-servicerequest				Version: 1.0.0
Standards status: Informative				Computable Name: DatatypeTQToServiceRequest
Copyright/Legal: Copyright (c) 2025, HL7 International, Inc., All Rights Reserved.

This ConceptMap represents a mapping from the HL7 V2 Datatype TQ to the FHIR ServiceRequest Resource.

This ConceptMap represents the mapping from the HL7 V2 TQ Data Type to the FHIR ServiceRequest Resource. See also the FHIR Shorthand or the CSV Source.

HL7 v2						Condition (IF True, args)			HL7 FHIR								Comments
Sort Order	Identifier	Name	Data Type	Cardinality - Min	Cardinality - Max	Computable ANTLR	Computable FHIRPath	Narrative	FHIR Attribute	Proposed Extension	Data Type	Cardinality - Min	Cardinality - Max	Data Type Mapping	Vocabulary Mapping (IS, ID, CE, CEN, CWE)	Assignment	Comments
1	TQ.1	Quantity	CQ	0	1				ServiceRequest.quantityQuantity		Quantity	0	1	CQ[Quantity]
2	TQ.2	Interval	RI	0	1				ServiceRequest.occurrenceTiming		Timing	0	1	RI[Timing]
3	TQ.3	Duration	ST	0	1			If the value and unit in TQ.3 can be unambiguously parsed where the unit is translatable into UCUM and the field contains nothing else.	ServiceRequest.occurenceTiming.repeat.boundsDuration.value		decimal	0	1				See notes on TQ.3 in v2.5.1 for likely formats that will be used in the v2 message.
3	TQ.3	Duration	ST	0	1			If the value and unit in TQ.3 can be unambiguously parsed where the unit is translatable into UCUM and the field contains nothing else.	ServiceRequest.occurenceTiming.repeat.boundsDuration.unit		string	0	1				See notes on TQ.3 in v2.5.1 for likely formats that will be used in the v2 message.
3	TQ.3	Duration	ST	0	1			If the value and unit in TQ.3 can be unambiguously parsed where the unit is translatable into UCUM and the field contains nothing else.	ServiceRequest.occurenceTiming.repeat.boundsDuration.system			0	1			"UCUM"
3	TQ.3	Duration	ST	0	1			If TQ.3 cannot be parsed/translated into the duration datatype		occurrenceTiming.repeat.extension??-duration	string	0	1
4	TQ.4	Start Date/Time	TS	0	1				ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start		dateTime	0	1	TS[DateTime]
5	TQ.5	End Date/Time	TS	0	1				ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end		dateTime	0	1	TS[DateTime]
6	TQ.6	Priority	ST	0	1				ServiceRequest.priority		code	0	1		ExtendedPriorityCodes		A translation from the text priority in the v2 message to a coded value in the request-priority value set will be required.
7	TQ.7	Condition	ST	0	1					extension??-condition	string	0	1
8	TQ.8	Text	TX	0	1				ServiceRequest.note(ServiceRequest.Annotation.text)		Reference(Annotation)	0	-1
9	TQ.9	Conjunction	ID	0	1
10	TQ.10	Order Sequencing	OSD	0	1
11	TQ.11	Occurrence Duration	CE	0	1												Note that the v2 base standard data type of CE is incorrect, but since it always has been CE it is not clear how implementers actually put a time and unit in this field. It is up to the implementer how best to parse this and use the occurrenceTiming.repeat.duration and durationUnits.
12	TQ.12	Total Occurrences	NM	0	1				ServiceRequest.occurrenceTiming.repeat.count		positiveInt	0	1