Open chris-kuryak opened 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.
information looks. for the AC just to make sure I understand, do you want us to add a search query for the items listed?
@MichaelEsuruoso Good question and feedback.
I have added specific ACs around documentation regarding this update. Let me know if that provides enough guidance.
this look good thank you @chris-kuryak not sure if @arnejduranovic or @brandonnava have anything to add. Also what is the priority for this?
@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.
@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.
@arnejduranovic Yes, the above proposal looks good. @victor-chaparro gave me his blessing.
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, specificallyITEM_ROUTED
:As you can see,
BUNDLE_DIGEST
is passed to theparams
section of the event data, and the object returned bygenerateDigest
looks like so:Therefore, this work probably revolves around expanding this data class and the factory that creates it:
FhirPathBundleDigestLabResultExtractorStrategy
Acceptance Criteria
Item
events includes the Facility Name, Testing Lab Name, and Testing Lab CLIA and those fields that can also be used in the query to target specific items.