Ported from github, originally posted by @toolbox
As discussions have ramped up for cTAKES, telemedicine, inpatient, and analytics, it has become clear that for many of these, tools already exist that can do much of what these features require. Including these tools in openEMR presents implementation challenges, the largest of which is that several of them require non-PHP environments. Adding these to the openEMR core would add a great deal of complexity, technical debt, and attack surface. It seems reasonable to assume that integrations of this nature will be common moving forward, as it allows powerful feature additions for a low developer cost.
This issue will seek to answer two questions:
Whether modularizing some of these features, making them installable additions (which may or may not be included in by default) is a good plan
If so, what should this module framework look like?
Proposal (plenty of missing pieces to fill)
Containerization technologies seem to be a good fit for solving this set of problems, and @MatthewVita has already spent some time working on the viability of their use with cTAKES. I think a solution based on docker-compose and git submodules would allow great flexibility while keeping the core clean and secure.
In this proposal, each module would be managed as its own repository under the openemr group. Each would be added as a git submodule within the modules/ folder of OpenEMR core. This has the benefit of requiring no additional package management and allowing explicit inclusion of any and all modules.
The modules themselves would each require a DockerFile, which would automatically be built during installation. Docker-compose would be a good candidate to manage the interconnects between these modules.
The final piece of the puzzle would be how these modules connect to the interface. It seems straightforward to allow passthrough from virtual directories via apache configuration or similar. This allows for pluggable patient interfaces, fhir REST, and websocket servers. The harder problem to solve is integration with existing interfaces. This may not be deemed necessary, but would allow, for example, a module to insert links into specific existing pages. This is not yet a soled issue, but I think discussion surrounding the whole topic would be useful and simplify a couple of different projects that are going on.
Thanks so much to @robert.down or broaching many of these ideas.