ACTIVITY.timing spec needs more definition and XSD should allow complex timing.value


ACTIVITY.timing : DV_PARSABLE is a mandatory attribute.

The definition is "Timing of the activity, in the form of a parsable string, such as an HL7 GTS or ISO8601 string."

1. Should it be mandatory even if the system generating the data doesn't have/can't generate a structured/parsable timing?

2. When frequencies and durations need to be specified in a GTS expression, that is not a parsable string, is a complex XML structure. Trying to put that on the XML gives an XSD validation error since the ACTIVITY.timing.value is string (simple type) and the content is complex.

3. The issue on 2. also happens with DV_TIME_SPECIFICATION.value : DV_PARSABLE "The specification, in the HL7v3 syntax for PIVL or EIVL types.". The syntax is XML and that content is not allowed on a string (DV_PARSABLE.value).

4. Points 2 and 3 are related to ITS, but the issue comes from the IM.

5. The spec definition for DV_PARSABLE.value is insufficient to understand how to use it, and examples are needed.

Some ideas:

For 1. make the timing attribute optional.

For 2. while at the IM level, DV_PARSABLE.value can store the XML for GTS, PIVL, EIVL, etc., at the XSD level if the type of DV_PARSABLE is string, the XML can't be stored in a XML composition instance.

An idea is to change the type of DV_PARSABLE.value from:

<xs:element name="value" type="xs:string"/>


<xs:element name="value" type="AllowAny"/>

<xs:complexType name="AllowAny" mixed="true">
<xs:any minOccurs="0"/>

That allows content like (I tested this and work OK):



"effectiveTime": {
"_xsi:type": "PIVL_TS",
"period": {
"_value": 12,
"_unit": "h"


<effectiveTime xsi:type="PIVL_TS">
<period value="12" unit="h"/>

That last one, is using the "any" from the XSD and require that the PIVL_TS is declared in a referenced XSD. The HL7 v3 XSD can be used to resolve the type.

That solution doesn't change the IM, allows extensions at the XSD level to use any formalism based on XML to represent the parsable expression, but makes the XSD to look different than the IM (not really an issue since those represent different things).




Pablo Pazos



Affects versions