Not a valid date-time - timezone offset must be specific

[agentgill]

Issue with downstream FHIR bundling process

If hours and minutes are specified, the timezone offset must be specified

<OperationOutcome xmlns="http://hl7.org/fhir"><issue><severity value="error" /><code value="invalid" /><diagnostics value="'2023-09-04T21:28:00' is not a valid date-time" /></issue></OperationOutcome>

[chaseastewart]

@agentgill I’ll take a look later today. Thanks.

[chaseastewart]

@agentgill Is this related to the CDA->FHIR templates?

I've found an example within one of the project samples that illustrates this issue.

CDA `

`

FHIR "onsetDateTime": "2010-05-28T10:00:00"

Unfortately FHIR and CDA have potential for variance.

Companion Guide to HL7 Consolidated CDA

5.1.10.1 Timestamp Data Representation
The value of a point in time is represented using the ISO 8601 compliant form traditionally in use with HL7. This is
the form that has no decorating dashes, colons and no "T" between the date and time. In short, the syntax is
"YYYYMMDDHHMMSS.UUUU[+|-ZZzz]" where digits can be omitted from the right side to express less precision111.
Common forms are "YYYYMMDD" and "YYYYMMDDHHMM", but the ability to truncate on the right side is not
limited to these two variants.

If no time zone offset is provided, you can make no assumption about time, unless you have made a local exchange
agreement. When timezone is NULL (unknown), "local time" is assumed. However, "local time" is always local to
some place, and without knowledge of that place, the time zone is unknown. Hence, a local time cannot be
converted into UTC. timezone should be specified for all TS values in order to avoid a significant loss of precision
when TSs are compared.

[CONF-072]
When populating any effectiveTime or time element in a document, C-CDA Content Creators:
1. SHOULD be precise to the day.
2. SHOULD be precise to the minute.
3. MAY be precise to the second.
4. If more precise than day, SHALL include time-zone offset. 

[CONF-073]
When populating a birthTime metadata element in the header or section of a document, C-CDA
Content Creators:
1. SHALL be precise to the day.
2. SHOULD be precise to the minute.
3. MAY be precise to the second.
4. SHALL NOT include time or time-zone offset

The options I see are:

1. Infer a timezone from either the author or custodian organization via a consumer provided configuration file
2. When a time is provided and an offset / timezone isn't simply throw away the time since the date is still clinically relevant
3. A consumer provides their own date filter, registering it with the environment, to implement their preferred logic

Option 1 is beyond what I can implement in short order. Option 2 is what I'd personally lean toward and could implement this week. Pull requests are also welcome. Let me know what your thoughts are. Thanks,

[agentgill]

@chaseastewart Yes this is CDA to FHIR. Option 2 sounds the best as it's self contained and not dependent on anything (config or consumer) - thanks

[chaseastewart]

@agentgill I've implemented option 2. See CHANGES for additional fixes. I plan to publish 0.1.0 later today. There is a non passive change around TemplateSystemLoader to align with python-liquid. The change shouldn't impact you unless you are using the loader directly to construct the rendering environment.

[chaseastewart]

@agentgill 0.1.0 is available for download.

[agentgill]

Confirmed this error is cleared now @chaseastewart thanks