A way to connect different hospitals to one server.

[girish8050517990]

It would be really nice if there would be a way of storing all information from different hospitals on one server so that the service can be used by many small clinics.

[mqchau]

@jkleinsc , I plan to make this line in app/services/database.js and similar others to use different database, not just main. It would take the database from the config file when it starts the server in server/config.js

let url = `${document.location.protocol}//${document.location.host}/db/main`;

This way @9611838416m can set up multiple ember servers with different config file/command line arguments all pointing to same couchdb instance. So we can server multiple clinic with different data using same couchdb instance.

This set up would be much easier than if we force one couchdb instance with one ember server.

[mqchau]

It seems that the users' login and session's information are stored in /db/_user and /db/_session. So if we want to truly support multiple hospitals same couchdb instance then we have 2 options:

1. prepend _user and _session with name of hospital and use that as our database
2. move the user and session information into the hospital-specific database

If I were to tackle this issue, I would pick the first approach. @jkleinsc What do you think?

[jkleinsc]

@mqchau I think all of this could be handled server side in the couchdb proxy:
https://github.com/HospitalRun/hospitalrun-server-routes/blob/master/routes/10-couchproxy.js

Basically you could setup something here (or create another alternate route) that handles multitenancy (eg based on user login "main" proxies to a different db). As far as _users and _session are concerned, the _users database is a special authentication database: http://docs.couchdb.org/en/2.0.0/intro/security.html#authentication-database, so we can't really change that without alot of work. You could possibly have some scheme where you store all the users in _users with prefixes and in your proxy you hit another db to lookup a users "real" user name, but that gets complicated fast.

I think multitenancy could be achieved but it would require much work. HospitalRun wasn't designed with this particular goal in mind.

[mqchau]

I see. I didn't know it would be this complicated. If we don't support multi tenancy per coucjdb instance then how would we address the concern to host multiple hospitals per server?

[emadehsan]

@jkleinsc @mqchau @9611838416m The problem can be tackled easily with following approach:

Append username with name of hospital and use that as our database

Solution:

• From config file, check isMultipleHospitalEnabled
• If NOT: set dbName = main (read it from config file, instead of hardcoding it)
• If YES then:
• After authentication, extract dbName from username
• Save dbName in session
• Each time a request is made from frontend to main db, replace main with the dbName for authenticated user in hospitalrun-server-routes/10-couchproxy.js

But for this to work these hardcoded appearances of main db must be replaced by passing a variable dbName; in following (server-side) files:

• https://github.com/HospitalRun/hospitalrun-dblisteners/blob/master/index.js#L26
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/conflict-res.js#L4
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/inv-import.js#L4
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/orphandelete.js#L3
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/patient-admission-fix.js#L3
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/patient-notes-mig.js#L3
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/patient-notes-mig.js#L3
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/xledger-export.js#L7
• https://github.com/HospitalRun/hospitalrun-server/blob/master/utils/scrub-db.js#L3

Please provide your invaluable suggestions.

[ATLCTO]

I would like to work on this issue, I was hoping to be able to setup multi-tenancy using a wildcard DNS (similar to other apps like slack or zendesk). So if the server is hosted at *.example.com; hospital1.example.com could map to the hospital1 database and hospital2.example.com could map to the hospital2 database.

I propose not prepending the database name on the username (or at-least make this a config), as it would be nice to be able to have one set of users across multiple EMR installations and either move roles to the hospital database or maybe add 'roles.hospital1' and 'roles.hospital2' properties to the existing user records.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.