CDCgov / prime-reportstream

ReportStream is a public intermediary tool for delivery of data between different parts of the healthcare ecosystem.
https://reportstream.cdc.gov
Creative Commons Zero v1.0 Universal
72 stars 40 forks source link

Add Facility Name, Testing Lab Name, and Testing Lab CLIA to Azure Logging observability #16400

Open chris-kuryak opened 3 weeks ago

chris-kuryak commented 3 weeks ago

User Story

As a ReportStream Engineer, I want to be able to query for more information (Facility Name, Testing Lab Name, Testing Lab CLIA) at the item level in Azure logs, so that I can troubleshoot issues easier.

Description/Use Case

Sometimes we receive reports that include multiple testing facilities (such as Carbon Health) and having the information of Facility Name, Testing Lab Name, and Testing Lab CLIA will allow us to identify specific messages easier and troubleshoot issues faster.

Risks/Impacts/Considerations

Dev Notes

Currently, we track items at the Report level and Item level. The added observability with these fields we would like to be added at the item level.

Here is an example in FHIRDestinationFilter.kt where we are sending an Item event, specifically ITEM_ROUTED:

    reportEventService.sendItemEvent(
        eventName = ReportStreamEventName.ITEM_ROUTED,
        childReport = report,
        pipelineStepName = TaskAction.destination_filter
    ) {
        parentReportId(queueMessage.reportId)
        params(
            mapOf(
            ReportStreamEventProperties.RECEIVER_NAME to receiver.fullName,
            ReportStreamEventProperties.BUNDLE_DIGEST
                to bundleDigestExtractor.generateDigest(bundle)
        )
        )
        trackingId(bundle)
    }

As you can see, BUNDLE_DIGEST is passed to the params section of the event data, and the object returned by generateDigest looks like so:

data class BundleDigestLabResult(
    val observationSummaries: List<ObservationSummary>,
    val patientState: List<String>,
    val performerState: List<String>,
    val orderingFacilityState: List<String>,
    override val eventType: String,
) : BundleDigest

Therefore, this work probably revolves around expanding this data class and the factory that creates it: FhirPathBundleDigestLabResultExtractorStrategy

Acceptance Criteria

chris-kuryak commented 3 weeks ago

@MichaelEsuruoso @brandonnava @arnejduranovic

Made this ticket for adding some additional fields to be tracked in Azure Logging.

Does this meet y'alls needs for enough information? Does it have the right labels, column, etc? Let me know if there is anything missing or if there is a better avenue for these requests so I can make sure I get it right next time.

MichaelEsuruoso commented 3 weeks ago

information looks. for the AC just to make sure I understand, do you want us to add a search query for the items listed?

chris-kuryak commented 3 weeks ago

@MichaelEsuruoso Good question and feedback.

I have added specific ACs around documentation regarding this update. Let me know if that provides enough guidance.

MichaelEsuruoso commented 3 weeks ago

this look good thank you @chris-kuryak not sure if @arnejduranovic or @brandonnava have anything to add. Also what is the priority for this?

arnejduranovic commented 2 weeks ago

@chris-kuryak presently we should be capturing the following in the item events:

    val performerState: List<String>,
    val orderingFacilityState: List<String>,

Do you want this data somehow associated with the new items you are requesting:

For example,

[
{
    facilityName: "something"
    facilityState: "NA"
},
{
    facilityName: "something2"
    facilityState: "NA"
}
]

and

[
{
    performerName: "something"
    performerState: "NA"
    performerCLIA: "Dfds1234"
},
{
    performerName: "something2"
    performerState: "NA"
    performerCLIA: "a234o23"
}
]

or does this kind of association not matter for your use case(s)? Keep in mind we do have a char limit of like 8000 for each param of the event and I think we would need to dig in and make sure we wouldn't run up against that limit if we did it this way.

chris-kuryak commented 1 week ago

@MichaelEsuruoso The priority is low right now. But as we ramp up more of Carbon Health's production data, this would become a medium priority. So if it's not implemented by the end of December it may become Medium priority if Carbon Health's volume is high.

@victor-chaparro Do you have any insight that could help guide @arnejduranovic per his comment above? I'm not sure what the advantages/disadvantages of the different methods as it affects our ability to query.

chris-kuryak commented 2 hours ago

@arnejduranovic Yes, the above proposal looks good. @victor-chaparro gave me his blessing.