Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handle timezones in bulk uploader and Fhir converter #5985

Merged
merged 49 commits into from
Jul 11, 2023

Conversation

mpbrown
Copy link
Collaborator

@mpbrown mpbrown commented Jun 14, 2023

BACKEND PULL REQUEST

Related Issue

Changes Proposed

  • Convert datetime strings from CSV to ZonedDateTimes so that datetimes in FHIR bundles refer to the correct instant of time
    • For datetimes that are not associated with any timezone, use UTC time with Z suffix.
      • Example: a timestamp of when an entry was updated
      • Format: 2021-12-20T19:00:00Z
    • For datetimes that are associated with a timezone, use the UTC offset.
      • Example: datetime of specimen collection
      • Format: 2021-12-20T14:00:00-05:00
  • Updates DateTime regex to allow optional timezone code
    • Some US codes like ET, EST, EDT, CT, MST, PDT, AKST, HST, etc are allowed
    • Any TZ identifier string defined by ICANN tz database
  • If timezone is not specified in the datetime, use the relevant address to retrieve timezone metadata from Smarty.
  • If address validation fails, use fallback timezone of US/Eastern
  • Updates unit tests and removes now obsolete code in FhirConverter and BulkUploadResultsToFhir

Additional Information

Before we can convert it to a UTC timestamp, we need to convert the local test_result_date to the correct Date instant of time which requires knowing the data's time offset from UTC and whether it obeys daylight savings.

This PR attempts to validate the address of the testing lab and use the time zone metadata returned from Smarty for the correct UTC offset.

Testing

  • Check updated unit tests
  • Test on dev7 to make sure both the bulk uploader and single entry FHIR conversions work as expected

@mpbrown mpbrown force-pushed the Mike/5844-handle-fhir-timezones branch from e9e126b to e1d4e6a Compare June 14, 2023 20:56
@mpbrown mpbrown force-pushed the Mike/5844-handle-fhir-timezones branch from 72cec4e to 4fa2b6d Compare June 20, 2023 13:13
@mpbrown mpbrown temporarily deployed to dev7 June 20, 2023 13:39 — with GitHub Actions Inactive
@mpbrown mpbrown marked this pull request as ready for review June 20, 2023 14:56
@mpbrown
Copy link
Collaborator Author

mpbrown commented Jun 22, 2023

Created a new issue to track the time zone work specifically of referring to the bulk uploader test coverage issue. #6025

Will push some additional changes based on this soon

@mpbrown mpbrown linked an issue Jul 5, 2023 that may be closed by this pull request
@mpbrown mpbrown temporarily deployed to dev7 July 5, 2023 15:46 — with GitHub Actions Inactive
@mpbrown mpbrown temporarily deployed to dev7 July 6, 2023 19:23 — with GitHub Actions Inactive
@nathancrtr
Copy link
Contributor

@mpbrown are the datetime format requirements from the ticket up-to-date?

Screen Shot 2023-07-06 at 4 35 41 PM

If so, I'm encountering a problem with (at least) the M/D/YYYY HH:mm TZ format. When using 12/20/2021 14:00 PDT as the value, the upload fails with the following errors:

Screen Shot 2023-07-06 at 4 39 56 PM

@mpbrown
Copy link
Collaborator Author

mpbrown commented Jul 6, 2023

@mpbrown are the datetime format requirements from the ticket up-to-date?

Screen Shot 2023-07-06 at 4 35 41 PM If so, I'm encountering a problem with (at least) the `M/D/YYYY HH:mm TZ` format. When using `12/20/2021 14:00 PDT` as the value, the upload fails with the following errors: Screen Shot 2023-07-06 at 4 39 56 PM

Nathan and I messaged about this in Slack and we may have to check with ReportStream to see what datetime formats they consider valid.

Test data csv includes:

  • Specimen_collection_date - 12/21/2021 14:00 PDT
  • Testing_lab_specimen_received_date - 12/22/2021 14:00 PDT

FHIR bundle gets created successfully with the following Specimen entry, correctly parsing the datetime strings as Pacific Time with UTC offset during December as -8

{
    "fullUrl": "Specimen/326117e3-f4f5-44cc-9387-407cd3601e44",
    "resource": {
        "resourceType": "Specimen",
        "id": "326117e3-f4f5-44cc-9387-407cd3601e44",
        "identifier": [
            {
                "value": "367f31bf-3bf2-43cd-8be4-dcab1daeb256"
            }
        ],
        "subject": {
            "reference": "Patient/1234"
        },
        "receivedTime": "2021-12-22T14:00:00-08:00",
        "collection": {
            "collectedDateTime": "2021-12-21T14:00:00-08:00"
        }
    }
},

@mpbrown mpbrown temporarily deployed to dev7 July 10, 2023 18:24 — with GitHub Actions Inactive
@mpbrown mpbrown temporarily deployed to dev7 July 10, 2023 21:43 — with GitHub Actions Inactive
@mpbrown mpbrown dismissed zdeveloper’s stale review July 10, 2023 22:45

Added requested caching feature

@mpbrown
Copy link
Collaborator Author

mpbrown commented Jul 10, 2023

Added a data transformation step for the covid csv pipeline that converts the user's uploaded datetime strings to an offset format that is accepted by ReportStream

Re-deployed on dev7 with a successful ReportStream response

@mpbrown mpbrown linked an issue Jul 10, 2023 that may be closed by this pull request
Copy link
Contributor

@zdeveloper zdeveloper left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! thank you for all this work

import java.io.Serial;

public class InvalidAddressException extends RuntimeException {
@Serial private static final long serialVersionUID = 1L;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not familiar with @serial, what does it do?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That particular @Serial annotation was recommended by Intellij to allow compile-time checking of serialization-related declarations, similar to the checking enabled by the @Override annotation type to validate method overriding

@@ -56,12 +55,11 @@
public class BulkUploadResultsToFhir {

private static final String ALPHABET_REGEX = "^[a-zA-Z\\s]+$";
private static final String SNOMED_REGEX = "(^[0-9]{9}$)|(^[0-9]{15}$)";
private final ResultsUploaderDeviceValidationService resultsUploaderDeviceValidationService;
private static final String SNOMED_REGEX = "(^\\d{9}$)|(^\\d{15}$)";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

whats the reason for this change?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SonarLint complaining that the digits could be replaced by \d, I could revert this if we prefer it to explicitly still use [0-9]

@@ -75,7 +77,8 @@ public static void assertJsonNodesEqual(
fieldPath + "[" + i + "]");
}
} else { // Otherwise assert values are equal
assertThat(actualFieldValue.toString()).isEqualTo(expectedFieldValue.toString());
log.debug("Comparing " + fieldPath);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do we need this?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Useful when debugging the expected and actual JSON output for the FHIR bundler, but not necessary to keep in so I could comment out or remove

Copy link
Contributor

@nathancrtr nathancrtr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I re-tried my test file in dev7 and the upload succeeded as expected. Thanks for investigating that issue! This LGTM 🚀

@sonarcloud
Copy link

sonarcloud bot commented Jul 11, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

94.4% 94.4% Coverage
0.0% 0.0% Duplication

@mpbrown mpbrown merged commit f09b3ff into main Jul 11, 2023
31 checks passed
@mpbrown mpbrown deleted the Mike/5844-handle-fhir-timezones branch July 11, 2023 20:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Handle time zones in CSV uploader Fill blank fields (specimen collection date) in CSV uploader
4 participants