Patients are matched automatically, and where it is not clear that there is no match or exactly one match, manual intervention is requested.
When results are retrieved by the Electronic Reports page, there is a tabular list at the top of the page of any errors or patients where manual intervention is needed for matching. Helpful messages are included to make it clear what to do.
Incoming HL7 is now processed in two passes to avoid partially processed files.
When an incoming results file cannot be processed, you have the option to delete it.
Orders are created automatically as needed. There is logic to also match on ordering provider and encounter.
A new protocol was created for submitting orders and/or fetching results to/from the local filesystem.
Uploading results from the browser is no longer supported. Use the local filesystem option instead.
Results processing errors are logged to the event log.
Look forward to the demo. Wish you reconsider upload option which is useful in case someone walks in with a hl7 file from unknown supplier or a MU2 compliant facility adds it in patient records.
Based on operational considerations we chose to require an order header. It takes 3-4 clicks and is a proof that the tests were ordered. It also provided us a user to notify when system processed those results. In this case we link that message with procedure order using your gprelations so users have a ready hyperlink to pull up the specific order.
Re. manual intervention we found it easier to provide a menu of possible orders for attaching the unmatched results.
Re. e-sign :
If the lab send a correction, it is your obligation to incorporate it. Not sure what it means for e-signature. Although not frequent, it happens often enough to become an issue.
For an upload alternative you could set up a shared directory on the server and copy the file to that. The point is that proper handling of incoming HL7 requires the information from the procedure providers page.
I think e-sign for corrections is OK. Corrected results will be linked to the original order, and when the order’s results are viewed the e-sign button appears again.
Memu of orders seems useful. You might consider donating the code so it will be in future releases.
The point is that proper handling of incoming HL7 requires the information from the procedure providers page.
In MU2 world, provider may not be always setup or practice may not want it. We still use the same load routine except from a hard-coded ‘other’ folder. Just a suggestion.
You might consider donating the code so it will be in future releases.
Our code has diverged significantly in this area with logic based on our operating considerations. So adapting complete files will need lot of work for which there is no budget. But we can attach fragments specific to messaging (may be changes to 2 files) if anyone is willing to incorporate in standard and test. Even in that area there seem to be practices that do not want messages. In our case we cannot operate without messages / action items.
I appreciate that keeping in sync with the community takes extra work, but in my experience it saves work over the long term. A good conversation to have with your users… just a thought.
