...
The following screencast demonstrates the forced re-review process with a simple example.
...
Updated Results via Manual Changes
...
The need for a qualified user to make a modification to reported results from the lab is very rare. This typically is only necessary if/when a lab is unable to provide updated result files by way of interface, or, when it’s desired to make a change to a specific test result without the need for new/updated results to be sent by the lab (which would force a re-review of the panel).
Scenarios Where Labs Re-Submit Previously Reviewed Results
On rare occasion labs may re-submit results against previously reviewed tests long after reviews have taken place. We sometimes hear from our customers that labs will submit results in this manner without prior warning or explanation. This could happen at any time, and depending on when it occurs, it can create significant operational, data management, and reporting challenges.
This impact is already mitigated in locked studies, as locked studies will only accept results but not update the review status of tests. More about that is explained in this article: https://foundryhealth.atlassian.net/wiki/spaces/DOCS/pages/3699998768/Database+Locking#Lab-Results-in-Locked-Studies
If this situation were to occur, we strongly encourage our customers to reach out to their lab provider and discuss the topic to understand why results are re-submitted in this manner. Submission of results could be proactively avoided if communicated with the lab, and discussing that those results would have an undesirable impact in ClinSpark.
Our support team also has the ability to apply specific result transform logic a given lab interface to mitigate against this challenge. The logic will review inbound results and not reset the review status if the following attributes are left unchanged in the result file:
| Code Block |
|---|
'labTestName',
'testId',
'testNameId',
'loincCode',
'loincCodeListId',
'additionalTestDescription',
'testLevelComments',
'reportedTextResult',
'reportedTextResultCodeListId',
'reportedNumericResult',
'reportedNumericResultPrecision',
'reportedReferenceRangeLow',
'reportedReferenceRangeHigh',
'reportedUnits',
'reportResultType',
'alertFlag',
'limits', |
Given that the result transform logic can be altered without a core-code change, the above requirements on acceptable changes against result file attributes can also be discussed and implemented based on customer needs.
If customers are interested in having the result transform logic updated, they should raise a service desk ticket and explain the circumstances of undesirable lab result submissions, and have our team investigate controlled changes against the result transform logic.
...