GMU is preparing to distribute the vaccine. We have enabled the inventory management system but we noticed that the recoding of vaccinations does not decrement the on-hand supply from the inventory manager. This message is to ask if there is anyone that has addressed this functionality?
Since there are more reporting requirements, we found local governments are offering separate apps designed for covid. Many state health departments have collaborated and created PrepMod which seems to be most cost effective way to go.
If you must create something in emr, standard process requires immunization + fee-sheet. It takes about 2-3 minutes of staff time just to repeatedly enter same data with the possibility that they forget the fee-sheet step. We created a LBF and addon code that required only 2 selections - lot (if multiple in inventory) and left or right arm. Since then we switched to background workflow. But you could use addon approach.
The immunization page should be decrementing the inventory also. This should be a background action that takes place when the user saves an immunization record. This is what I was thinking. No extra steps for the user to remember.
Conceptually these are two separate transactions. If immunization form checks if inventory module is implemented to reduce inventory, it is classic hard linkage. That makes the code non-modular. Our preference is to build a third transaction that processes two underlying transactions without modifying their existing logic.
If you do decide to modify the form, may be you can add flesh to couple of methods in @sjpadgett’s shiny immunization service and simplify the $_POST logic. Look forward to what others have done and what you come up with.
This sounds like the job for an event listener! So, if the immunization fired off an event and the event listener heard (received) the event then it could take action to decrement the inventory without changing how the inventory or how the immunizations work?
Would this be an adapter pattern? Or could it be observer pattern?
I am going to give this a stab again soon. I am looking @adunsulag work here openemr/ModuleMenuSubscriber.php at master · openemr/openemr · GitHub
I have tried it before and it work. I will mimic the work here. I will first start by adding an event to the immunizations form.
Your thoughts.
We used PubSubJS. For a scalable system you really want message queuing. But basic idea of observer+observed is same - either in php for server processes or in javascript for client level. We chose later - better user experience.
This is observer pattern (more specifically Pub/Sub pattern). Adding more events that people can act off of is always a good idea to decouple things. I’m not too familiar on the mechanics of what goes on in immunization, but OpenEMR I believe supports Redis which can be used for message queuing if you want to have a more scalable architecture.
Though, without understanding all the data and events involved, it seems like just firing off an event people can subscribe to would follow KISS.
If you’re doing a lot on the frontend then that PubSubJS library @mdsupport mentions might be a good idea, though I couldn’t see in perusing the library that it handles any kind of message storage (which in my view is pretty critical if you are actually going to implement a an actual scalable message queue).