Test 10.13.03 fails due to le date comparison boundary condition issue

[daniel-alistar]

Summary

The test case 10.13.03 (Encounter search by date + patient) is currently failing because of a strict string comparison or parsing mismatch between the expected timezone offset format and the actual response received from the server.

Details

During the execution of the test, inferno performs a search using a timestamp formatted with a numerical offset (+00:00), but the server returns a period object where the start date uses the Z (Zulu) suffix.

• Expected format (sent/expected): 2025-12-10T14:00:00+00:00
• Actual format (received): 2025-12-10T14:00:00Z

While both are valid ISO 8601 representations of UTC, the test fails to recognize them as equivalent, leading to an assertion error.

Potential impact

This issue may not be isolated to the Encounter resource. Any resource utilizing date-based searches might encounter the same failure if the server defaults to Z notation while the test expects +00:00.

Proposed fix

The validation logic should be updated to treat Z and +00:00 as identical UTC indicators by parsing both strings into date objects before comparison, rather than performing a direct string match. (This can be extend as well as when searching for other timezones and the server defaults all dates to UTC).

[karlnaden]

I've tried and haven't yet been able to reproduce this issue. Initial attempts suggest that the two formats are already being normalized internally and that this should be handled. Please include a read-only link to your test session using the "share session" button in the top right of the Inferno UI so that we can see if session details help us reproduce the error you are seeing.

[daniel-alistar]

Unfortunately, this is on a private instance and can't share you more details.

[daniel-alistar]

Said encounter from picture has (when searching/reading):

"period": {
  "start": "2025-12-10T14:00:00Z"
}

Then, inferno requests:

patient=REDACTED&date=le2025-12-10T14:00:00+00:00

And then, it fails with the said message.

[karlnaden]

Thanks for the additional info, but I'm still not able to reproduce the issue. Here's what I've tried:

1. locally created a patient with the exact encounter period you provided. I ran the tests and saw Inferno make this request http://localhost:8080/reference-server/r4/Encounter?date=le2025-12-11T14:00:00%2B00:00&patient=utcbug for test 10.13.03 which passed.
2. I found a patient on the inferno reference server that has an encounter with UTC dates using Z in the period ("period": { "start": "2025-01-17T16:00:00Z", "end": "2025-01-17T16:30:00Z" } in the singled encounter on Patient/999 - https://inferno.healthit.gov/reference-server/r4/Patient/999/$everything). I ran the tests in this session and 10.13.03 makes request https://inferno.healthit.gov/reference-server/r4/Encounter?date=le2025-01-18T16:00:00%2B00:00&patient=999 and passes.

Possible things to check on your side:

• What version(s) of the test kits, Ruby, etc. are you running in your private instance? I can check if there is any skew that might explain the difference.
• If you think my patient isn't representative, please provide a non-PHI FHIR transaction Bundle with a example Patient and Encounter that is failing for you and I can load that up locally to see if that reproduces the issue.

[daniel-alistar]

I think I found where the issue is at.
The inferno expects: le2025-12-10T14:00:00+00:00, but the period.start is 2025-12-10T14:00:00Z.
I think inferno expects for the whole period to be lower or equal than that actual date?

Technically in FHIR, searching by date for Period types is based on the non-empty intersection of the search range and the resource range.
Ex:

• le2025-12-10T14:00:00+00:00 gets translated to (-inf, 2025-12-10T14:00:00+00:00]
• period.start = 2025-12-10T14:00:00Z and no period.end gets translated to [2025-12-10T14:00:00Z, +inf)

When intersecting these two ranges, using there's a non-empty intersection, the actual date is the intersection and the resource should be included in the response bundle. (2025-12-10T14:00:00Z)

[karlnaden]

Hmm. I think I agree that there is a bug in the date comparison logic. However, I don't think that the (g)(10) tests ever hit it because of the way that searches are chosen which will never choose this kind of boundary condition. Are you seeing this issue as a part of an actual (g)(10) certification test kit run, or are you using this comparison logic in another place?

[daniel-alistar]

Yes, this is part of an actual (g)(10) test kit and managed to replicate it in a public session.
Searches are chosen based on the first resource it finds and takes +/- 1 day. But, it can be replicated in case there are 2 resources within a span of 1 day. (Ex. 1 on 2025-12-10 and another on 2025-12-11 or 2025-12-09)
See here replication.

I have created two Encounters with a period.start difference of 1 day and I was able to replicate the same behaviour.

[karlnaden]

Good point - thanks for getting that session together. We'll look into getting this fixed. Is this blocking your certification? That will help us prioritize this issue.

[daniel-alistar]

I don't think this is a blocker for us because it's only happening for a strict scenario. (which we can avoid)
CC: @gmodrogan