We haven’t given much thought to installing any non-php service via modules as our module architecture now is all delivered via composer which will not allow you to tell the target OS to install other software. In my view the best approach is to communicate to 3rd parties that are not written in PHP is via a REST api. Its scalable, allows you to move things around, and follows the micro-services architecture pattern. Where you store this 3rd party service is up to you. You can store it on the same service and communicate via sockets, move it to some other service, or whatever.
If you will be installing a 3rd party service alongside OpenEMR on the same target OS, you can make calls out to the system via any kind of php exec call or via sockets, or some other kind of IPC mechanism in php. This is the most secure communication and also the fastest but you’ll have scaling issues.
Another option that will have better scaling characteristics would be to leverage the MySQL database or REDIS as your communication layer. It all comes down to your comfort level with the various technologies and your functional requirements for reliability, availability, and speed.
I want to mention that there’s nothing really stopping you as the module writer from making calls out to python but we currently have no mechanism for you to install python via a module if its not already available in the target OS. I believe most linux installs have python installed but I can’t attest to windows or mac environments if that will be the case.
Now that said if you are trying to deploy your module to the widest available audience there’s nothing preventing you from going off a static linking approach and bundling up whatever python runtimes and libraries you need to execute inside your module that will get downloaded from your git repository via composer.
One thing to bear in mind if you have to follow any privacy laws such as HIPAA or GPDR is the passing around of PHI data between services. Whatever you develop as a 3rd party will need to protect the PHI data as well as provide an audit log of who viewed/modified data as well as when it was viewed/modified. This is handled at the core SQL level inside of OpenEMR and if you operate outside that, you’ll need to make sure you are handling all the compliance aspects yourself.