Please submit any feature requests and vote on ideas that have already been submitted to indicate your interest in seeing them developed
Currently, when we are using ORR widget, the most in-demand widget from our customers is the sample error widget.
Sample error widgets are created using ORR widgets for monitoring low volume and clot errors.
On the nLO, we receiving flag number 3,72.
The corresponding flegs are Samp.C. and Samp.S.
However, the ORR widget is basically a test item unit widget.
Therefore, when a clot error appears in one sample, several items appear.
It is very important for the customer to see how many samples have sample errors rather than how many test items have sample errors.
I wish I could see the sample counting in the ORR widget, or I could change the ORR widget to add a sample error widget that I could see in units of samples
Almost all of our clients in Korea have that demand.
Guest
|
Idea detail description
Currently, when we are using ORR widget, the most in-demand widget from our customers is the sample error widget. Sample error widgets are created using ORR widgets for monitoring low volume and clot errors. On the nLO, we receiving flag number 3,72. The corresponding flegs are Samp.C. and Samp.S. However, the ORR widget is basically a test item unit widget. Therefore, when a clot error appears in one sample, several items appear. It is very important for the customer to see how many samples have sample errors rather than how many test items have sample errors. I wish I could see the sample counting in the ORR widget, or I could change the ORR widget to add a sample error widget that I could see in units of samples |
Hi @Jinhong Park ,
Wonderful! That's great to hear that the proposed solution meets your needs.
I'll proceed with involving the technical team and discussing the implementation internally.
In the meantime, please don't hesitate to reach out if you need anything else from our side.
Best regards,
Mary
Hello @Maria Doretto,
Thanks for checking in.
The new concepts look great and properly address the alarm issue. This will definitely solve the problem. It’s actually one of our top-priority requests right now, and we’d love to deploy the patch in Korea immediately once it's ready.
You have the green light to proceed with the implementation.
Best, Jinhong
Hi @Jinhong Park ,
Thank you very much for your feedback.
I would like to clarify whether the proposed concepts address your request, or if you still feel there are too many alarms per test unit, as mentioned in the first part of your message.
Understanding this is important for us to determine whether we can move forward with implementing the proposed solution or if further revisions are needed.
Thank you for your support and clarification.
Mary
Hello @Maria Doretto,
Thank you for sharing the proposal and the prototype.
Even now, there are too many alarms per test unit, so what customers actually use is insufficient.
I reviewed the concepts, and using the error examples based on the Sample ID is highly appropriate and fits the context well. It addresses the core problem effectively.
It looks like a great starting point for the discovery phase. Looking forward to the next steps!
Best regards,
Jinhong Park
Hi @Jinhong Park ,
We’ve been working on a proposal for your idea and would now love to get your feedback. I’ll attach the prototype for you to review.
Please let us know whether this proposal addresses your problem and if there’s anything missing or that could be improved.
Please note that this is still in the discovery phase, so the prototype is intended to explore concepts and gather feedback rather than represent a final committed solution.
Thank you!
Hi @Ruben Salvador Gareta and @Jinhong Park ,
Thank you for the quick response and feedback, Jinhong, and thanks Ruben for the clarification.
I’ll update the design accordingly and review this new widget internally with the rest of the tech team. We’ll then prioritize its development against our current backlog.
Thanks!
Mary
Good morning,
@Maria Doretto only one clarification. Both Priority and Demographics (Sender/Organisation) originate from test-level event data coming from the Infinity Gateway. In summary, Priority specifically prefers the test request explicit priority over the order priority. Demographics/Sender is a property of the event itself (which is a test event), not directly a sample or test attribute — it represents the ordering physician/department. So, in the extended version of the widget (first screenshot) both Priority and Demographics must be at Test level and not at Sample level.
Regards,
Dear @Maria Doretto,
It's exactly what you expressed!
I agree with the configuration concept too. (unit selection option)
Thank you!
Jinhong Park
Dear @Jinhong Park ,
Thank you for your detailed feedback on the ORR monitoring per sample unit.
To address the high demand for sample-level monitoring in Korea, I’ve put together a proposal for a Sample Unit mode for the ORR widget. I’d love to know if this matches your vision:
1. The widget
Instead of seeing every failed test as a separate row, the widget would consolidate data by the physical sample:
Primary Columns:
Column 1: Sample number, instrument name
Column 2: ORR Tests count
The Logic: If Sample A has 4 failed tests out of 10 due to a clot, it appears as one row with a count of '4/10' in the test column.
2. Enhanced Detail Popup
Clicking on a sample would open a detailed breakdown containing Test ID and its origins, demographics, status & timestamp.
3. Flexible Configuration
We want to give users the power to choose their perspective. In the widget settings, you would be able to toggle the Grouping/Counting Type:
Test Unit: (Current version)
Sample Unit: (New version)
Does this structure accurately capture the "Sample Error Widget" functionality your customers are looking for? If this looks correct, I will move forward with the next steps of the proposal.
Thank you!
Mary