As per your request, i’m just opening a new thread for this conversation…
Based on our understanding, the changes that need to be implemented in OpenEMR to count the number of successful openemr installations are given below:
Client side changes
During the OpenEMR installation, the following information can be obtained:
Name
Email
Phone
Notification about security fixes and new releases Yes/No
These user details can then be passed to a web service running at oemr.org (if this is the server which consolidates the user registration details)
Server side changes (@ oemr server)
A new table called ‘Installation/Users’ can be created in the server side with the following information
<Date>
<Name>
<Email>
<Phone>
<Notifications Yes/No>
‘Email’ can be considered as a unique key.
A new PHP web service can be created & registered which can obtain the information from the client and update the ‘Installation/Users’ table accordingly.
At the server side, we can query the database to check for the existing entry for the given ‘email-id’. If the ‘email-id’ already exists, then it means that the user had already registered with the oemr site. If the current notification information is different from the previous one then the latest one is updated.
The absence of the ‘email-id’ reflects that this is a new user and all the information provided can be stored in the database.
For the number of installations, the count of the entries in the table can be considered.
For notifying security fixes and new releases, the corresponding mail communication can be sent to the e-mails where the notification is ‘yes’
It’s clear we’re going to need to relay data back from the installer to oemr.org in order to get an accurate installation count. I think using a simple update notification service is a great way to accomplish this for users who are so inclined. However, there will be users who will opt out of this due to the nature of the information being requested. If we’re going to use a web service to handle communication of this data from those users who want to register, we would be able to leverage the same service to doll out unique installation ID numbers for openemr. My thought is that we could query the oemr webservice at the point of installation and retrieve a new, unique installation id for every install (even if performed from the same tarball or zip). At this point we have 3 options we can present our users.
1) Register with your personal information and gain access to our notification system.
2) Register anonymously with your installation ID containing absolutely no personal or system information whatsoever
3) Refuse registration.
I think this will get about as close as we can expect to the true number of installations while still giving the users the freedom to decide how much information gets transmitted. (Since this is opensource, freedom is what it’s all about, right? ;)
Up to this point, we’ll only have a picture of how many times the installer has been run – not necessarily how many actively used installations are in the field. This is where the importance of a unique id comes in. For those users who refused registration altogether, we would essentially count them out of our statistics. For the users who selected the other two options, we could employ a periodic dial-home feature where the unique ID gets reported and is considered active. The method for executing this feature would be a point of debate (based on login activity comes to mind initially), but the end result would be valuable in determining the number of recently active installations.
We currently know how many downloads we receive in a given time frame. With the approach you described originally and my amendments, we would certainly gain a more robust picture of successful installations as well as meaningful/current usage statistics for existing installations.
It’s clear we’re going to need to relay data back from the installer to oemr.org in order to get an accurate installation count. I think using a simple update notification service is a great way to accomplish this for users who are so inclined. However, there will be users who will opt out of this due to the nature of the information being requested. If we’re going to use a web service to handle communication of this data from those users who want to register, we would be able to leverage the same service to doll out unique installation ID numbers for openemr. My thought is that we could query the oemr webservice at the point of installation and retrieve a new, unique installation id for every install (even if performed from the same tarball or zip). At this point we have 3 options we can present our users.
1) Register with your personal information and gain access to our notification system.
2) Register anonymously with your installation ID containing absolutely no personal or system information whatsoever
3) Refuse registration.
I think this will get about as close as we can expect to the true number of installations while still giving the users the freedom to decide how much information gets transmitted. (Since this is opensource, freedom is what it’s all about, right? ;)
Up to this point, we’ll only have a picture of how many times the installer has been run – not necessarily how many actively used installations are in the field. This is where the importance of a unique id comes in. For those users who refused registration altogether, we would essentially count them out of our statistics. For the users who selected the other two options, we could employ a periodic dial-home feature where the unique ID gets reported and is considered active. The method for executing this feature would be a point of debate (based on login activity comes to mind initially), but the end result would be valuable in determining the number of recently active installations.
We currently know how many downloads we receive in a given time frame. With the approach you described originally and my amendments, we would certainly gain a more robust picture of successful installations as well as meaningful/current usage statistics for existing installations.
In my testing environment, I have installed openemr at least a hundred times.
I would argue that any sort of automated reporting that was not ‘opt-in’ would be a very bad idea, unless you feel like filtering out my ‘install, see what broke’ morning routine.
Yes, opt-in is mandatory before making any sort of "phone home" connection. This is what users of open source projects expect. And as ytiddo points out, registering an install is often not appropriate nor useful. When the user opts in, this should indicate a new installation that is "counted", even if the email address is already on file.
Other than that, keep it simple (for the user). I do suggest including the IP address in the logged information, which would make it easier to deal with abuse.
