Details
-
Change Request
-
Resolution: Persuasive with Modification
-
Highest
-
FHIR Core (FHIR)
-
R5
-
Modeling & Methodology
-
Datatypes
-
-
Grahame Grieve/Ron Shapiro: 3-0-0
-
Correction
-
Non-substantive
-
R5
Description
The Period data type has this invariant:
per-1 If present, start SHALL have a lower or equal value than endstart.hasValue().not() or end.hasValue().not() or (start <= end)
On the surface, this seems fine, however, the way FHIRPath <= works, the start and end timestamps have to have the same precision for the start<=end comparison to resolve. Detailed discussion of that occurred here in this chat.fhir topic
We have real-world data (in this case, Encounter data) that has these start/end timestamps:
"period":
,
This is legacy data, and we simply don't know the timestamp of the start date.
Right now, we are unable to represent these Encounters as valid FHIR resources.
I think there are a few options: # Update Encounter to use something other than the Period data type for representing the Encounter period. This seems weird - Period seems like the correct data type.
- Update FHIRPath to change how date comparison happens. I'm not familiar enough with the reasons behind why FHIRPath does what it does to know if this is a good option or not.
- Update the per-1 invariant to handle the comparison of timestamps with differing precisions differently.
- Provide narrative guidance on what systems should do when they have data that does not comply with the invariant. Should we truncate down to the lowest precision? This seems bad as we'd be losing possibly useful information. Should we add precision, for example by defaulting midnight in the case where we don't have a timestamp?
Attachments
Issue Links
- relates to
-
FHIR-19896 Allow two dates to be subtracted
- Resolved - change required
-
FHIR-27055 Behavior for comparing Date, Time, and DateTime primitives is unclear
- Resolved - change required
-
FHIR-29268 Clarification on Period invariant
- Published
- mentioned in
-
Page Loading...