Behavior Change - Mandatory registration of first user in Mirth Connect 4.1.0+

[ab-20-m]

Mirth Connect 4.1.0 changed the behavior of the first login dialog to require registration for the first user. See Commit d3b240cab15a056729431d44c1a2e1d734601c6f. The change in behavior makes setting up a clean instance for quick experimenting/development tedious and annoying. The new requirement also means NextGen is likely to get an ever increasing number of false/fake registrations for dummy users.

I am not familiar with any other software released under an open source license that "requires" user registration. In my opinion, the new behavior is invasive, user(where user is defined as a developer) hostile and should be reverted.

I did not open this "finding" as an issue because the change was an intentional design/behavior change. So not a bug and it doesn't feel correct to create an "Enhancement" that is basically revert to previous behavior.

[jonbartels]

Thank you for starting this discussion. I saw this issue on Friday while trying to spin up a new instance to try out Mirth Connect in Java 18. Slack thread for reference. I had a similar experience, I couldn't figure out how to get past that screen.

@twest-mirthconnect and @lmillergithub, I would like to draw your attention to this discussion.

[twest-mirthconnect]

@ab-20-m, @jonbartels - This is a change in the product, yes. Would you mind sharing what, how, and why a real user account isn't a reasonable expectation for use?

[swobspace]

@twest-mirthconnect While I understand the wish for a mandantory registration from a company view, without some information in the release notes and some explanations I would call this sensible change a poor policy. Especially from a GDPR standpoint in Europe. Generally you can do with your software what you like, but I would appreciate it if I would have known this before installation.
And: I would accept the change, if the phone number was optional. Unless you can explain the phone number is essential for you (a valid email address should be enough) you may not get much acceptance in Western Europe.

What about this:

1. Explain the change in the release notes
2. declare, what you will do with the registered data (i.e. reason for processing and protection according to GDPR rules)
3. make the phone number optional

Since we can always use a valid non personal email account from the company (clinic and so on) I find a request for a valid email address acceptable if the email address will be used for more than marketing, i.e. security infos, new releases and so on.

It's just my personal opinion.

[twest-mirthconnect]

@swobspace - Thank you for taking the time to share your opinion on the registration page for the primary account now in Mirth Connect. The release notes are inadequate and I will work with the team to improve them today. Thank you for bringing that to my attention.

[tonygermano]

@twest-mirthconnect the updated "What's New" page says:

Welcome to Mirth Connect

The Welcome to Mirth Connect screen includes required additional fields for better communication with users who register and consent to receive email updates and marketing messages from NextGen Healthcare. For more information about data usage and privacy policy, see: https://www.nextgen.com/privacy-policy

It then shows a screenshot where the Register checkbox is not disabled and is able to be unchecked. If we are allowed to opt out of update and marketing emails, what is the remaining purpose for collecting the information in the first place?

[twest-mirthconnect]

We collect the information, not just for marketing. From a product point of view, there are many benefits to knowing who your customer is. What roles they play, how they use the product in that role, and more. Marketing and informational communications are helpful to those who have a vested interest in the product's continued improvements, programs, new services, etc.

This information is also extremely important to build consensus internally and externally for what we are building towards: a Mirth Interop Engineering Eco-system. Without information about the people using it... I can't get there. It just won't happen. At the end of the day, this is a very small ask and seems reasonable to expect when using an application as powerful and robust as Mirth Connect truly is from my point of view.

I am open to improvements and automation to make it easier but not having a primary account with limited information hurts everyone and everything we have in store for Mirth Interop.

[stewoe]

I use Mirth as a Developer. Our Setup is that every deployment sets up all containers (including the DB) from scratch. I often want to just test if the deployment works correctly and sets up all channels, libraries and other functionality as intended. This happens 1-n times per week at the moment. Being forced to register a new every time would be not only annoying, it would also lead to a lot of garbage data on your end I guess

[jonbartels]

Possibly related - #5329

[ab-20-m]

@twest-mirthconnect hopefully I answered all of your questions/points.

Preamble:
Most of the users of Mirth Connect are likely users bound by HIPPA. Part of that is knowledge of the minimum necessary standard; meaning if you don't need to know to accomplish the "mission" you don't get to know. Why does NextGen need all of the data elements defined as non-optional to support what sounds like "internal market research"? semi-AKA "I missed the part where the need for disclosure of (my) PII is my problem and not NextGen's?"

Why:
(This change is a bad idea at best, terrible idea at worst)

Consider an individual employed but a hyper-security conscious/OPSEC cultured organization.
The disclosure of organization member roles to external entities; whom have no (potential) contractual obligation to secure said data; ignoring the other identifiable information
(which feed into GDPR discussion and 'You need X,Y,Z to do what if not for marketing because the user opted out?);
into an external data repository is a source of PII data for a threat actor to target and attempt to breach. Does the parent organization trust that external organization?

NextGen took approximately some 4~ months to setup a "security email/disclosure address" for security problems. All AFTER a user publicly named and shamed NextGen.

The disclosure of the organization member PII to NextGen provides no immediate benefit to the disclosing organization. AKA "So I get nothing and you get my PII short-term(at-best)."

The disclosure of First Name, Last Name, Telephone Number, E-mail Address, Organization Role, Organization Location (Possibly down to territory/state) is excessive for the purposes of not market research but kinda?

So what's the "benefit" to the disclosing party that de-selects "Give me Marketing Stuff" but is FORCED into "Here's some PII"?
There isn't. One of the key points of open-source licensed software that made it successful for businesses, as both a producer and consumer was "You can use this and do WHATEVER you want, but you can't sue me."

How:
(bogus info floods the collection endpoint because Open Source means "Here's the code good luck may the force be with you")

Organization users will be instructed to enter garbage data that satisfies the UI requirements but not disclose externally organizational Mirth Connect Operator/Admin/Developer/Whomever PII. Organizations that have existing support contracts with NextGen will question "So why do you need more than you have currently and how does the disclosure of that data benefit me(the organization)?" Hint-hint; it doesn't.

What:
NextGen pointed a loaded gun, at best; worst a nuclear device: at their own foot and doesn't realize it?

"Everyone has a game plan until they get punched in the face." - Mike Tyson, Probably.

End of the Day
NextGen can proceed down whatever path they so choose. Irritating the people that have to use the software day-to-day is probably not a wise decision but that's between NextGen and the users that hang around after.

Much of my frustration is the perception of non-transparency with how the change was introduced. The current workflow for development is done via private Github repos, and then during release the commits are pushed to the public repository. That workflow often means outside of a Mirth Developer Q&A there's not really any insight into what is coming the the next release. As far as I can tell, no one outside of NextGen had any idea this change was coming. If the change had been a public commit, it might have been noticed sooner and discussed sooner, even if that ultimately meant NextGen keeping the current implementation. Post-release is almost never a good time to discuss a new change.

On a positive note about the current Github workflow, NextGen does push the individual commits and not simply squash all the commits and then push. There are other vendors that do use that workflow and it makes analyzing 6K files changes with ~200k additions and ~190k deletions. So kudos for that.

[twest-mirthconnect]

Thank you @ab-20-m for taking the time to share your perspective. Each data point we are asking for in the product registration has a significant impact on product development, service offerings, and new development resources we would like to design, build, and publish. You have a number of assumptions that this data is used only in connection to marketing which is only partially true as this information is used to also improve the products and services.

I am grateful for the feedback and adjustments I need to make during the monthly calls. I will begin this month (August) to share and provide a way for those on the call to provide feedback on the work we intend to implement in the future versions of Mirth Connect.

[kpalang]

I'd like to chip in here as well.

I too absolutely oppose the change in discussion. It offers no benefit to the user (not customer), while, as mentioned above, giving NextGen more data, but not necessarily better data.

Many have already and many more will mention the use case of spinning up a quick Mirth container to test something out and then wipe it never to be seen again. How would NextGen benefit from PII from such case?

Now, as for the noble goal of better getting to know your customers, you already have all the information you require. Unless I've misunderstood something, the project contained in this repository is not NextGen's product.

Open Source means "Here's the code good luck may the force be with you")
- @ab-20-m, Aug 7th, 2022

NextGen's product is, among other things, the support and premium extensions. As such, NextGen's customers are organizations who pay money for the support and premium extensions. Now, I would be less opposed to the change, if it was forced, for example, only when Mirth detects premium extensions. In this case, maybe require the credentials that people use to log in to the Success Community? This does not of course mean I would completely forgive it.

Another idea that popped into mind (me being a "break everything to see what's inside" type of person):
Mirth is an open source project (duh), this means people are allowed and at times encouraged to fork the projects to add their own twist. Think of what VSCodium is to VSCode. There are some nuances, but it's a project that removes telemetry from VSCode, I believe something similar would not be hard to implement for Mirth, while otherwise being inline with the GA releases for Mirth.

[pacmano1]

So, is there a middle ground here perhaps?

As the main and maybe only (in the sense they commit real dollars to develop the product) sponsor of the product, I and I hope others understand NG has a desire to drive revenue to the product and collecting user information for potential marketing purposes is understandable, it's just in a really poor place at the moment.

Capturing user demographics at point of login to a software product and phoning home is uncommon, in fact I don't think I have ever seen that before, in an open source product or if there it is optional. While it won't make everyone happy, capturing marketing data at the point of download rather than at the point of product start seems to be a more common practice - Tibco does this regularly, although you can get to the downloads irrespective of that, albeit it's a bit painful. Oracle does that also (e.g. MySQL Workbench is behind a login to download). I think Zoho CRM is similar. Not suggesting adding a login per se of course.

I understand of course there are tens of thousands of software products commercial and non-commercial that allow downloads with no "login" collected even at the point of download. The marketing team, rather than drive revenue by collecting email addresses and contacting people (which has an atrocious response rate in general anyway open source or not), instead builds a customer base by thought leadership, a superior product, and growing their reputation as the place to get top notch expertise for support and implementations.

[ab-20-m]

Here's a proposed middle ground. Change the required data elements for the 'Register user with Mirth Connect' to only: Country, State/Territory, Role and Business. The full demographics for consenting to receive email updates and marketing materials always has been reasonable and the option is still opt-out.

[twest-mirthconnect]

Any thoughts about this consideration?

[tonygermano]

This is bad from a usability point of view and intrusive for people that want to run an open source server on their own hardware. I think "registration" should be removed completely from first login that should only be for resetting the admin password and optionally entering user details for the benefit of the person running the software. This is not even useful information for NextGen as there is no authentication taking place. I can enter whatever I want into that form and use different false information every time. Forcing every member of a development team to fill out the form several times per week is not useful either, but is instead preventing people from upgrading.

Use of the upcoming Community Center is the most obvious place to require a user to register an account with NextGen which they will actually use for logging into the portal. This means that they only register an account one time, and use it to sign in from multiple mirth instances. It also means that if someone has no interest in using the Community Center, then they are not obligated to provide their personal information in order to use the open source product. Nor will it slow down development as there would be no need for data collection on first login. All of your usage data becomes tied to api requests sent to the service backing the Community Center. If people don't want to use the Community Center and have not already purchased something from you, then they aren't your customers.

This is no different than using an Android phone and not setting it up with a Google account. The phone still works and I can side-load my apps without sending any data to Google. But if I want access to the Google Play app store, then I need to log in with my Google account that I create once and use everywhere, and everything becomes nicely integrated.

[twest-mirthconnect]

See slack msg

[twest-mirthconnect]

Any thoughts about how to go about doing this?

This is what I need to be able to do to improve the roadmap of products and services for Mirth Interop. Open to suggestions as to how to get there (in hindsight, maybe should have asked as @ab-20-m suggests... :)

• Real authenticated accounts using the product and services
• Associated Usage Data

[pacmano1]

I'm not sure either of those two things improve the roadmap of products without some qualification.

Feedback from users that have meaninful usage rather than usage (i.e. I installed the product) should likely drive feature sets (as of course does your opportunity for revenue), and a login on start of product isn't that meaningful. Also I can't connect the users of Mirth that do not pay for it to those that buy something from NG (or another vendor) as neccesarily valuable data. That may give you data like "34.6 percent of users the installed Mirth do not license a component", which is a useful data point, but not that useful to drive product planning - you need real feedback to best do that. I'll concede that asking for user registration at some point might provide an answer to "why did they not buy a product?" but collecting and requiring that (user data) at the point of product start is the wrong place to do it.

For product planning and feedback, I'd encourage the NG team to use concepts the salesforce.com and microsoft use to get their user community to both contribute to and vote on roadmap additions and feature sets. Github does not do that well yet. SFDC has their idea exchange, and uservoice.com is a player in the market to solicit feedback. Those tools require login and thereby you have the opportunity to collect marketing and potenitally valuable product feature feedback from your users. You already use salesforce.com, and in fact have an existing community function to collect feedback, albeit perhaps not ready to go for this function.

What is sort of fascinating about this discussion is the community, rather than just say "I will always put fake data in that form" is instead giving constructive feedback instead. And that's the same community that provides mounds of support for your users at no charge, in fact sometimes supporting your support people.

I'd encourage the NG team to continue with their re-invigorated spirit of engagment with that community and just pull the change and consider more mainstream ways to acheve your objectives.

[jonbartels]

Perhaps I'm thinking about this like an engineer, what usage data do you already have? What questions does that usage data answer and what data would answer other questions?

For user outreach - Is the user registration data correlated to server IDs and thus to server installations and then to paid server licenses?

For roadmaps - Does the current usage data contain information about the connectors used and extensions installed?

Thinking in the spirit of open source - Something that Mirth Connect can do that no other engine can is that when you make changes to the data collection you can literally show users the code that collects that data. This fosters trust.

[twest-mirthconnect]

Thanks to everyone for the feedback on the registration page. It seems everyone is leaning one way. I would like to work through it a bit more on the 15 for those attending the MC roundtable next week.

[twest-mirthconnect]

If the client permits, we collect a fair amount of usage data on a channel, templates, extensions use, admin functions, data types, connectors, etc. This also includes whatever account/organizational data is added to a profile when installing Mirth.

We do have open source and commercial usage split out.

Where we miss data (and the reason why I am asking for a couple of additional data points) is in actionable workflows, heat maps, etc. based on the developer (are they new, do they work indie or part of a team), their role to help me understand how they use it and why, and other details that can correlate usage data to country, person, and role.

It would enable strong roadmap decisions, small group discussions based on need, collectively work on features and functionality based on country, role, or experience in the product... the list goes on and on.

Yes, I have a responsibility to grow this business and I feel strongly it can be done together. And yes, I want 1000s of open source users to see the advances in new features and functionality that are deliberate for developer-centric designs in the commercial solution. And, bring 10s of 1000s to the open-source community. It's awesome.

By proving the strength of the product commercially AND the community publically, we can change the game in interop with the Mirth platform and begin to help build consensus in the myriad of ways to do what I believe is the heart of Mirth Connect. Help providers help people.

I want to bring a billion people into the Mirth Platform around the world and with it, the healthcare data providers need to help those who need it the most in the poorest 100 countries around the world.

THAT is my goal... so... I hope you will join me, see the vision, and help us all get there together!!

[pacmano1]

I get the point here, but a sentence like the below really needs some clarificaiton.

If the client permits, we collect a fair amount of usage data on a channel, templates, extensions use, admin functions, data types, connectors, etc. This also includes whatever account/organizational data is added to a profile when installing Mirth.

Another legal problem here is the developer installing the product may not be authorized (i.e. they are not a corporate officer) to bind their company to terms such that this collection of data is permitted.

Also, such data may be subject to NDAs, non-competes and other legal instruments for which Nextgen has no knowledge of nor is entitled to.

[tonygermano]

I released a plugin that bypasses registration on first login for 4.1.0 since there is no other means to opt-out.

https://github.com/tonygermano/mirth-user-privacy-plugin