jwildfire
commented
5 years ago After thinking this through, this is a fairly major change. Unless it is very high priority for the clinical workflow, I'm pretty strongly inclined to leave this until after v1.0. It's certainly not impossible, but there are a few issues that would need to be addressed.
My biggest concern is that we'd have to refactor the data pipeline. Currently, we only calculate the standardized lab values used for the eDish and mDish plots when the chart is initialized. With this update, we'd need to be able to re-run those calculations for eDish whenever the user changes the a 'user-defined' cut point. I can imagine a few different ways of handling this, but none of them are super simple or self-contained.
The second issue has to do with the use case where multiple units are provided for a given measure. I think v0.13.0 minimizes the problems cause by multiple units (as discussed in #138), but the updates needed for this issue would raise some questions. I think we'd just want to disable these new controls when that is the case, but there's no way to know when this use case is in play unless we add a required unit_col parameter. Adding unit_col comes with it's own set of questions, so I think our best path is to avoid it for now.
JimBuchanan
The idea would be to add a new set of controls that would allow the user to override the data driven upper limits of normal for each key measure, and define a static ULN instead. That static ULN would the propagate to the eDish plot using the current reference lines for the plot.
The UI elements could be: 1) "Choose ULN Method" with options of "data-driven" or "user-defined" 2) When "user-defined" is selected above, the user can enter numeric ULN values for each measure. We may also want to provide the user with a distribution of the ULN for each given measure found in the data, perhaps with a custom title for each numeric input.