As a ReportStream sender,
I'd like to know how large a batch of messages I can send,
so I can set my send size and frequency appropriately
Description/Use Case
In talks with new RS sender CVS Health they let us know they plan on sending upwards of 5000 messages/day and wanted to know if they should send them all at once or in set smaller intervals. If they did send all 5k at once we know that at that batch size our system would time out before processings the whole queue. The question then becomes what is our batch limit we can safely recommend a large sender that wouldn't cause a time out? And how does that limit change depending on the format (HL7, FHIR, CSV) or data type (ELR, ETOR, ADT)? The aim of this ticket is to run the tests to find those limits, record the results, and use it to inform conversations with future senders as more and bigger senders come online.
Risks/Impacts/Considerations
Consider if batch size limit is inconsistent even within a certain file format or data type. If so be sure to log all the different batch sizes so we can understand the general range within batch sizes start to get iffy for timing out
Consider checking if speed of processing messages changes significantly across different batch sizes
Risk: Can't test in prod. Testing in staging won't be entirely representative of production. Any limit we find in staging will likely needed to be rounded down substantially to be safe to tell a sender what that limit is.
Dev Notes
From past experience, the slowest part of the convert step seems to be HL7v2->FHIR conversions (which would only apply to HL7v2 messages, of course)
Will likely need to determine a "reasonable and representative" HL7v2/FHIR ELR message to use for testing.
Acceptance Criteria
[ ] Batch size limit for HL7 & FHIR data identified for staging environment
[ ] Batch size for ELR & ETOR data identified for staging environment
User Story
As a ReportStream sender, I'd like to know how large a batch of messages I can send, so I can set my send size and frequency appropriately
Description/Use Case
In talks with new RS sender CVS Health they let us know they plan on sending upwards of 5000 messages/day and wanted to know if they should send them all at once or in set smaller intervals. If they did send all 5k at once we know that at that batch size our system would time out before processings the whole queue. The question then becomes what is our batch limit we can safely recommend a large sender that wouldn't cause a time out? And how does that limit change depending on the format (HL7, FHIR, CSV) or data type (ELR, ETOR, ADT)? The aim of this ticket is to run the tests to find those limits, record the results, and use it to inform conversations with future senders as more and bigger senders come online.
Risks/Impacts/Considerations
Consider if batch size limit is inconsistent even within a certain file format or data type. If so be sure to log all the different batch sizes so we can understand the general range within batch sizes start to get iffy for timing out Consider checking if speed of processing messages changes significantly across different batch sizes Risk: Can't test in prod. Testing in staging won't be entirely representative of production. Any limit we find in staging will likely needed to be rounded down substantially to be safe to tell a sender what that limit is.
Dev Notes
Acceptance Criteria