Module Skeleton Package

OpenEMR Development
#1

So I needed to explain to someone how to create a module and I figured I’d just create a skeleton project that people can build off of if they want. Similar to what we did with @sjpadgett’s fax/sms module.

So I put together this sample skeleton project with instructions on how to create a very loosely coupled custom module. Its rudimentary right now but I plan on adding to it over time.

You can install it in your OpenEMR project via packagist by using a
composer require adunsulag/oe-module-custom-skeleton

The link on packagist is here:
https://packagist.org/packages/adunsulag/oe-module-custom-skeleton

The github if you want to fork it and use it for your own custom modules is here: https://github.com/adunsulag/oe-module-custom-skeleton

6 Likes
Deploying forms
#2

This is a good tool to use for developers to know. I have used this to help make minimal changes to the codebase.

#3

Hi guys, that is really useful, thank you very much! I was able to install this module and play with it a little bit.

Could you please let me know if there are any descriptions/thoughts on architecture approach for loosely coupled modules and how they should be integrated?

I see there are few situations:

  1. Module don’t use any third-party components and extends functionality of the system using existing functionality and PHP.
  2. Module use third-party components (I assume Telehealth module does it) and need to send data to those components and get data from them. In this case is there an ability to store those third party components on the server there OpenEMR installed or it’s better to keep them outside on a separate server? Or let’s say this can be a decision of each installation?

I ask because work on AI/ML module for some illnesses prediction and it would be easy if I can keep using python (as I see dockerized developer version already has python installed)

#4

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.

1 Like
#5

Challenge for new developer is there are multiple approaches listed / found if they just type “openemr modules”. Top hits are :

  1. ZH version of Zend modules
  2. @sjpadgett’s Fax module
  3. @htuck’s Patient Privacy module page.
  4. @juggernautsei/LifeMesh’s Telehealth module page.
  5. Several references in various posts to any and every function as a module - e.g. Scheduling, Inpatient, Inventory, Rx, FHIR - refer to “Globals”…

Not sure if there is way to lead new users along a decision tree but at least some index page may help. And of course each of the pages above should let viewer know about that page.

1 Like
#6

Hi @mdsupport
Just to be clear, my contribution in your list was strictly to provide a page where devs can post summaries of their modules for potential users to read about and contact them if they want to use the modules. The Patient Privacy module is all @ken 's work; I only massaged his quick summary and wikified it.

Gotta say, one centralized repo of descriptions of the modules available for OpenEMR may be one of the better ideas, but nobody heard about it so it isn’t going anywhere.
Best- HT

1 Like
#7

I think your index page would be a great central location we can push people too. So far the modules I’ve created (outside of the skeleton module) have been for private companies which they have yet to release to the broader community, if they start pushing them to the community I’ll make sure to add them to that wiki page.

#8

Hi @adunsulag -
Thanks for the push, as it were :slight_smile: If you have any questions about getting your stuff on the wiki, feel free to ask.
But of course, maybe being listed all together here is as centralized as they’re going to get!

  • HT
#10

I thought that was what this page was for

https://www.open-emr.org/wiki/index.php/OpenEMR_Modules

#11

Yup, that’s what it’s for.
But my earlier remark came from my impression that hardly anybody seems to know the wiki exists so that wiki page goes unnoticed. Whereas this forum page has a lot better chance of appearing in searches, so maybe it’s where the list of modules will get seen.

  • HT
#12

I posted a repo to add alike in the module section to the modules page that hardly gets seen as @htuck pointed out. It is hardly seen because it is brand new relationship to the rest of the wiki.

#13

You can have a solution for world hunger. But if hungry people are not searching for it or it is not within their means/skill set to use that solution, they will continue to go hungry.

Perhaps put something in standard code that makes ‘What’s New’ page pop up periodically when an administrator logs in.

1 Like
#14

I’ve been considering modularizing some of my custom forms (after all, I can always use an extra project or two lying around) but my pet project depends on other additions to the OEMR codebase. For example, I’ve added a few special-purpose data types to the library/options.inc.php file. Is there a way to use the module installation process to add code to this file (or simply replace the file with a newer enhanced file)? Likewise, if I were to reduce some of my custom specialty visit forms to modules can I (or should I - and how?) have the module installation process place the code in the interface/forms directory or leave it in the interface/modules/custom_modules directory? Sorry about these rather amateurish questions but I can’t see how to accomplish the above and need a basic direction.

1 Like
#15

@Mouse55 So the way I would recommend going about doing this is to add new events in the options.inc page to allow module writers to extend the data types that are available. Same thing with the forms. That way you don’t have to muck with the file system and everything would live inside your module.

If you want to take a stab at adding the new events and the dispatching of the events in a PR for both the options and forms code that would make it possible to support your changes without having to replace files in core.

1 Like