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

HL7 Version 2 to FHIR
1.0.0-ballot - ballot 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-ballot 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/datatype-tq-to-servicerequest				Version: 1.0.0-ballot
Active as of 2024-12-20				Computable Name: DatatypeTQToServiceRequest
Copyright/Legal: Copyright (c) 2020, 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		ServiceRequest.Quantity	0	1	CQ[Quantity]
2	TQ.2	Interval	RI	0	1				ServiceRequest.occurrenceTiming		ServiceRequest.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		ServiceRequest.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		ServiceRequest.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	ServiceRequest.string	0	1
4	TQ.4	Start Date/Time	TS	0	1				ServiceRequest.occurrenceTiming.repeat.boundsPeriod.start		ServiceRequest.dateTime	0	1	TS[DateTime]
5	TQ.5	End Date/Time	TS	0	1				ServiceRequest.occurrenceTiming.repeat.boundsPeriod.end		ServiceRequest.dateTime	0	1	TS[DateTime]
6	TQ.6	Priority	ST	0	1				ServiceRequest.priority		ServiceRequest.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	ServiceRequest.string	0	1
8	TQ.8	Text	TX	0	1				ServiceRequest.note(ServiceRequest.Annotation.text)		Reference(ServiceRequest.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		ServiceRequest.positiveInt	0	1