We are on the very cuspes of releasing this module into the community. We are waiting for the green light from the Quest engineering team. This video will show you how to configure the module once it is enabled on the system. If you have any comments, please post them below. We want to know what you think. This module only connects to the Quest lab system.
DISCLAIMER:
No real patient data was used in this video.
This looks nice @juggernautsei. Doe the lab results come back automatically and populate the procedure_results tables?
The HL7 results can be automatically pulled in. The results will be parsed in using the Electronic Report.
There has been a feature added to the module. Some clinics will be downloading PDFs manually. Some will be getting HL7 results. When installing the module, it will install the background services feature to automatically download the HL7 results if the clinic is authorized to do so. This feature is disabled by default. The feature will have to be manually turned on. It can be toggled on and off.
@juggernautsei, This will be very useful for many practices.
Does Quest allow results only operation - specimen goes with a paper order and results come back as HL7?
Only other comment - Was there any reason to keep config in global? Shouldn’t it live in that module’s config?
I will ask about the results only. I don’t know for sure. The choice of putting the settings in the config was following the pattern set by others. Jerry puts his setting in the module. It is a developer’s preference as to where to place the settings. I have one setting that is not in the config. That setting is to enable and disable the background service.
(I made a correction to this post following @sjpadgett post).
@mdsupport what is your opinion on whether to use the config or place all setting in the model and don’t use the config at all?
I use the globals table but not the config for any configurations.
@juggernautsei, From the original developer perspective globals mechanism offers a convenient dumping ground for anything that requires site input. But true “module” behavior would be such that if Quest is not active, there are no Quest entries displayed in globals screen. We don’t use zend based modules but find it easier to keep config maintenance as part of that module codebase - zero (almost) footprint.
From an admin or savvy user’s perspective, it is easier (think less training) if gear appears on the screen that is impacted by the settings. I fully realize it is harder to code if config support is not provided as part of the core/kernel.
