Hi, I would like to know the best practices around implementing multitenancy in openEHR CDR. I understand that openEHR natively supports data federation. It would help if the community can point me to Do’s and Don’ts kind of practical guidelines. Thank you!
2 Likes
Hi @anupama
EHRServer (https://cloudehrserver.com/) is mullti-tenant, basically there is a higher level construct that is the organization, and each EHR belongs to an organization. Any user is also associated with an organization, when the user logs in via the web administrative console or via the REST API, the user will access only EHRs and data from those EHRs under the user’s organization.
In the openEHR specs there is no explicit multi-tenancy requirement or model.
2 Likes
BTW, what is not currently supported by EHRServer and might be a feature were federation is needed inside the same server instance, is to link organizations together to form a federation, then EHRs and contents inside any organization in the federation could accessed by the users of any of the organizations in the federation.
As you can see, this model could be extended, and on top of it you can add Role Based Authorization/Access Control, so certain users can access certain EHRs or types of records, and you can also restrict the type of operations (read, write, query, etc). But the multi-tenancy “model” is orthogonal to the RBAC model, so both are complementary.
In EHRServer, if you have access, you can read and write on any EHR from the organization you belong to, and the idea is the client app using the server API is where the user role and access grants are checked, so fine grained access control is delegated to client apps.
I hope this can give you some hints, since this could be implemented in many ways, and most could be right, depending on your requirements.
Thanks for the reply @pablo. We will be proceeding with the client app side,
Auth/Access control to govern the ehr data. It will be interesting to create a federation of organizations when we do cross-org data analysis. Will keep these hints in mind while we do so. Thanks!
Hi,
I think there are two separate issues which are being mixed up.
- Multi-tenancy. Where multiple different accounts reside in the same physical CDR. Either with a shared physical database or each with a separate database. Better support both of these scenarios , as I think do Ocean and Solit-clouds?
EhrBase does not support either, although @birger.haarbrandt did mention that it might be possible if there was demand (and ? funding!!) TBH whilst the single database is fine for demos and prototyping etc, you really need separate physical Dbs for production, otherwise backup/restore management becomes a real nightmare.
1 Like
@ian.mcnicoll for me the separation of requirements is clear. My comment about federation was only about supporting that inside the same CDR instance. Federation of CDRs do not require multi-tenancy inside the same CDR instance.
The key point is for supporting multi-tenancy, there is a clear need of the concept of organization (could have many names), having EHRs and users associated to those organizations. That is at a logic level. At a physical level, one or many databases could be used for implementation, each approach has pros and cons. In EHRServer we use a single database, and all top-level assets are scoped by an organization: EHRs, templates, users, queries, etc. There is no need to scope compositions inside organizations because compositions are always inside an EHR.
1 Like