# EHRs with different system_id in the same server? **Category:** [RM](https://discourse.openehr.org/c/rm/42) **Created:** 2023-02-06 16:43 UTC **Views:** 1086 **Replies:** 39 **URL:** https://discourse.openehr.org/t/ehrs-with-different-system-id-in-the-same-server/3535 --- ## Post #1 by @erik.sundvall Hi! Just checking a thing The EHR root object has a system_id attribute defined in https://specifications.openehr.org/releases/RM/latest/ehr.html#_ehr_class saying “The identifier of the **logical** EHR management system **in which this EHR was created**.” This raises the question: Can an instance of an EHR server contain a mix of system_id strings (for different EHR objects of course) if EHRs for example have been imported from different systems (e.g. the patient moved their entire EHR content to this system from another hospital that was merged with this hospital)? Yes /No /Maybe? (I assume that we want a default system_id to be set on new EHRs created by this system, but the question above especilaly refers to importing existing EHRs from other systems.) P.S. This is not a purely theoretical question but rather important in order to currently not design a too limited implementation in one of our systems and associated lookup services in a landscape where caregiver organisations split and merge several times during a patient's lifetime. --- ## Post #2 by @thomas.beale [quote="erik.sundvall, post:1, topic:3535"] Can an instance of an EHR server contain a mix of system_id strings (for different EHR objects of cours) if EHRs for example have been imported from different systems (e.g. the patient moved their entire EHR content to this system from another hospital that was merged with this hospital)? [/quote] My current answer to this is no - all EHRs in systemX have 'systemX' as their system_id, since: * EHRs are created new locally - automatically system_id = 'systemX' * EHRs created locally with imported content merged (versions of existing stuff, whole new Versioned objects) are the same; the imported content carries its original system in VERSION_ID.uid.creating_system_id() ([see here](https://specifications.openehr.org/releases/RM/Release-1.1.0/common.html#_version_identification)). * EHRs fully imported from elsewhere also have system_id = 'systemX' The last case is the interesting one - move of full EHR. One could imagine just dropping in the EHR 'as is' from its source location, including its EHR object, which has system_id = 'systemY'. However, I don't think a full move should be done like this, instead an EHR has to be created locally for that patient - which will quite likely create some initial content, and certainly will create EHR_STATUS and EHR_ACCESS to reflect local needs. The import will have the effect of merging all of the contents of the incoming EHR (but not its root object) into this locally created 'empty' EHR. The EHR_STATUS and EHR_ACCESS objects will need to be analysed and merged in an intelligent way. Other content may have to be reprocessed into local form, e.g Medications list etc, if the templates are not identical. All of the content of the resulting EHR will carry OBJECT_VERSION_IDs that indicate the original system in which it was created, but the top level object(s) will all be local. I think this is the only sensible way to do it. The question of 'when was the original EHR really created for patient 123' can still easily be answered by analysing the imported content. If we allow importing to cause the literal dropping in of the whole incoming record, there is no guarantee that it technically conforms to local rules. It could also end up with EHRs with system_id being some system that no longer exists, or has itself moved or been renamed. --- ## Post #3 by @ian.mcnicoll At least in theory, the REST API supports import of an EHRId but I think this was to support an external service that associates subjectID and ehrId, not to support bulk import. @chunlan.ma @Seref or @heath.frankel may have more information. --- ## Post #4 by @pablo We had this discussion some time ago. It depends on the definition of "system" and the system boundaries. In a cloud multi-tenancy context, each client of the server might have it's own system ID, even if the same physical server stores data for each client, but the clients are logically separated by the multi-tenancy layer. That is a border case, just to show the complexity a platform could have. On the other hand, AFAIK, there is no clear definition of `system` or `system boundaries` in the spec, so in the context of openEHR it's difficult to tell what is right or wrong. --- ## Post #5 by @thomas.beale [quote="pablo, post:4, topic:3535"] We had this discussion some time ago. It depends on the definition of “system” and the system boundaries. In a cloud multi-tenancy context, each client of the server might have it’s own system ID, even if the same physical server stores data for each client, but the clients are logically separated by the multi-tenancy layer. That is a border case, just to show the complexity a platform could have [/quote] Yes, and this will be more common as time goes on. A distinction has to be made between a 'logical EHR repository' and a 'physical system'. The latter might be a cloud-sited multi-tenancy system with 50 separate clinic / hospital EHR repositories. I believe what we should use as the 'system id' in openEHR is the logical repository id, not the physical system (if it is different. This is because it is at the logical repository level at which various rules will be defined and enforced, e.g. to do with access control, consent, logging, whether patient demographic data is allowed and much more, not to mention ownership. --- ## Post #6 by @pablo For me either option is OK as long as we have a clear definition of what a system is and system boundaries are in the context of the openEHR specs. Considering specs are a logic component, I think it's consistent that system ID is also a logic component identifier. --- ## Post #7 by @thomas.beale At this point, 'system' probably is no longer the best term (maybe it never was;) --- ## Post #8 by @sebastian.iancu We did implemented in the same way as described by Thomas above (i.e. imported data always gets the local ‘systemX’). Also, when a normal 'client' connects to the 'local' system it can normally search within that system only. This is might be relevant for querying VERSIONED_PARTY (Demographics/Registry) as there is now 'parent' structure like the EHR for COMPOSITION. --- ## Post #9 by @pablo [quote="thomas.beale, post:7, topic:3535, full:true"] At this point, ‘system’ probably is no longer the best term (maybe it never was;) [/quote] Totally agreed, but the term itself is not important, it's the definition we give to the term in the context of the spec what should be important. We are really defining our own domain with it's own terms and definitions. --- ## Post #10 by @erik.sundvall Thanks for great replies and clarifications everybody! A followup double question. When importing data, for example compositions, from an external sytem I assume the recieving system must first have (or create) an EHR for the patient (as described above Tom above). In the replies above it was clarified that the EHR.system_id should be the system_id of the local recieving system. Now, what about **the EHR.ehr_id** (usually a UUID) **of the particular EHR in the recieving system** (if a new EHR needs to be created) - **should/could that (UUID) be the same as the EHR.ehr_id that was used for this patient's EHR in the sending system or not?** --- ## Post #11 by @thomas.beale [quote="erik.sundvall, post:10, topic:3535"] Now, what about **the EHR.ehr_id** (usually a UUID) **of the particular EHR in the recieving system** (if a new EHR needs to be created) - **should/could that (UUID) be the same as the EHR.ehr_id that was used for this patient’s EHR in the sending system or not?** [/quote] Yes it should (in my view!). Have a read of [this section in the EHR IM](https://specifications.openehr.org/releases/RM/latest/ehr.html#_ehr_creation). --- ## Post #12 by @ian.mcnicoll In that case, is there not a risk of collision - would the ehr_id allocation need then be global across the different EHRs and essentially external to an individual CDR? --- ## Post #13 by @sebastian.iancu If the local system_id is exposed/published for outside scope, and if you see that as a namespace for ehr_id, ... then not. --- ## Post #14 by @ian.mcnicoll Yep I agree but it would probably require a 'namespaced' ehr_id to become the format used e.g. in the APIs. or possibly the idea of a default 'systemId' namespace. Starts to get messy, unless we start using systemId namespaced references routinely. --- ## Post #15 by @ian.mcnicoll Clearly it makes import of an EHR simpler but is the real complexity of CDR data transfer not in refactoring and resolving all the various Contribution and Composition references? --- ## Post #16 by @erik.sundvall I believe the EHR.ehr_id value is globally unique already by identifier design (UUID), even without system_id "namespacing". (And I think that is good.) --- ## Post #17 by @ian.mcnicoll So does that mean (in theory) that a CDR to CDR transfer might be able to retain all existing EHR references within other structures? Contributions, compositions etc? --- ## Post #18 by @thomas.beale [quote="ian.mcnicoll, post:12, topic:3535, full:true"] In that case, is there not a risk of collision - would the ehr_id allocation need then be global across the different EHRs and essentially external to an individual CDR? [/quote] The advice I gave (which is not from a recent analysis) is based on Guids for EHR ids, so no collision or central allocation needed. If system B receives an EHR from system A, and system C gets a copy (not good practice, but realistic) from system A of the same EHR, and then system A gets that EHR from system C - retaining the EHR ids potentially enables traceability - system A can work out that the two EHR (copies) are really the same original EHR (maybe content might not be identical). For the same reasons, the EHR id / Subject id (MPI id/s) relationship is more slid A counter-argument might be to say that EHR id should be allocated new (Guid) for every new EHR instance created, no matter for what patient or where. So in a non- or badly-federated environment, patient 123 ends up with say 3 EHRs, each with a different EHR id. There might be arguments in favour of this - it depends on how such environments are set up and what they are trying to detect and avoid. I suggest it is worth doing a new analysis on this based on cloud / co-tenanted / SaaS environments as well as on-site. We would need input from real contexts to help with this - e.g. from implementers and deployment environments. --- ## Post #19 by @pablo Having the same UUID assigned might simplify some things, without generating too much trouble, though it might be a privacy issue having the same ID in two different systems/platforms. Having different UUIDs neither generates any issues, if both source and destination will be separated for some reason and don't need to be connected, then the patient will have two EHRs, one on each organization (thinking about integrating data from different organizations). Though if for some reason you need to link those EHRs and have different UUIDs, then a cross-reference component is needed, something like IHE PIX but for EHRs. --- ## Post #20 by @thomas.beale What re-using the same EHR id (a Guid) means is: any time you see this EHR id, the EHR is part of the same *virtual distributed EHR*, due to copy, merge, move actions in the past. Where there are EHRs with different EHR ids for the same patient, it means: independent EHRs were created for this patient, which are (until they are discovered) being added to independently and one day probably need *EHR merging*. There may still be more benefits using new EHR id every time an EHR instance is created for a given patient - I have not done the analysis in recent years, but for now it looks to me like EHR id re-use on copy/move is more useful. --- ## Post #21 by @erik.sundvall [quote="pablo, post:19, topic:3535"] Having the same UUID assigned might simplify some things, without generating too much trouble, though it might be a privacy issue having the same ID in two different systems/platforms. [/quote] Yes, this is a good note and, as you imply, is use case dependent. Real examples being explored: 1. When designing Region Stockholm's future EHR data platform we'll want to enable what @thomas.beale describes a *"virtual distributed EHR"* - to maximize patient safety over the lifetime of the patient a shared UUID could be used us as EHR.ehr_id for this patient when possible. Most things for this patient will be handled on behalf of the same healthcare region (public payer) but may be done by contractors/organisations with different EHR-systems/CDRs. Fairly often parts of EHR content will need to be copied/acessed between organisations. (Today this is handled by allowing several organisations to use the same EHR-system, but in the future it would be good to allow for more diversity regarding vendors/systems.) 2. When adding an openEHR CDR to the national Cancer research platform [INCA](https://cancercentrum.se/samverkan/vara-uppdrag/kunskapsstyrning/kvalitetsregister/om-inca/) they chose to start new EHR for each patient and generate a new EHR.ehr_id. Identification based on the Swedish national ID called "personnummer" (not EHR.ehr_id) is used when transfering and mapping recieved data to their CDR, but the "personnummer" is then not accessible for ordinary researchers. And if the researchers would see the EHR.ehr_id it would be independent of the EHR.ehr_id of the original system. Also data for the same patient (same "personnummer") may come from several healthcare regions that may not be synced regarding EHR.ehr_id assignment or may not use openEHR internally at all, just for e.g. transfer of pathlogy reports/extracts. In this case pivacy triumphs patient safety and no syncing of new data is expected back to regional EHRs. It would be intersting to hear how other organisations with multiple CDRs have done or are planning to do regarding this (e.g. HiGHmed, One London, Catalonia, Sloveinan national services etc) --- ## Post #22 by @pablo [quote="erik.sundvall, post:21, topic:3535"] this is a good note and, as you imply, is use case dependent [/quote] I think is more than "use case dependent" it depends organizational structures, agreements and local/international legislation. I would call this "environment dependent". Thanks for the examples! --- ## Post #23 by @thomas.beale Interesting. One rule that we might try to formally state is something like this: If system B requests/ is offered EHR 11aa22bb from system A, and it is known which patient it is for (lets say pt1234), then proceed as follows: * if system B has an EHR for pt1234 (let's say this is verifiable in some way) then merge the EHR 11aa22bb contents into that record. No changes to System B's EHR id for pt1234 * if system B has no EHR for pt1234, create a new EHR (always have to do this, in order to conform to local rules), but give it EHR 11aa22bb's EHR id, and then import the contents. * in very specific cases, if it can be determined that the CDR product, and local / regional EHR creation rules etc are shared, then a 'native import' might be OK This kind of thing could of course be modified by there being a central (say to the health system, region, etc) registry that provided some management of EHR ids, as well as verification methods for patient ids. NB for newcomers: in openEHR, the EHR id doesn't identify the patient, just the EHR. --- ## Post #24 by @ian.mcnicoll Two different English use-cases. 1. One London Universal Care plan - single CDR instance - subjectID is the 'universal' (almost!) NHS Number, unique ehr_id for that CDR 2. North London Genomics - ? 14 federated CDRs each in a London hospital. Each with unique ehr_id but a 'master' CDR which coordinated registration and querying. My gut feeling is that for England, at least, it is safer ground (culturally, politically) to run with unique ehr_ids for each CDR, or at least a small quite localised group of CDRs. Probably somewhat different in smaller countries like Scotland or Wales, where even if we did end up with several CDRs, it might well be possible for hem to work like Erik's Region Stockholm example. What about CDR to CDR bulk transfer of an EHR and associated compositions? I assume retaining the same ehr_id makes this process easier, particularly if we can retain composition Uids, so as not to disturb EHR_URI references? --- ## Post #25 by @thomas.beale [quote="ian.mcnicoll, post:24, topic:3535"] My gut feeling is that for England, at least, it is safer ground (culturally, politically) to run with unique ehr_ids for each CDR, or at least a small quite localised group of CDRs. Probably somewhat different in smaller countries like Scotland or Wales, where even if we did end up with several CDRs, it might well be possible for hem to work like Erik’s Region Stockholm example. [/quote] I think re-use of EHR ids is indeed likely to always resolve to a 'region' concept where there is some common jursidiction, however that may be implemented in IT (cloud + co-tenanting or federation of local CDRs etc). [quote="ian.mcnicoll, post:24, topic:3535"] What about CDR to CDR bulk transfer of an EHR and associated compositions? I assume retaining the same ehr_id makes this process easier, particularly if we can retain composition Uids, so as not to disturb EHR_URI references? [/quote] Yep - this is a dump/load semantic - it's not a clinical or provider level act. So everything has to be preserved, which should always be doable by having a CDR-independent safe serialisation format (the 'dump' format) and all systems being able to import that correctly. --- ## Post #26 by @chunlan.ma [quote="thomas.beale, post:2, topic:3535"] My current answer to this is no - all EHRs in systemX have ‘systemX’ as their system_id [/quote] I agree. EHR system id logically means the boundary of an organisation. The original question "Can an instance of an EHR server contain a mix of system_id strings": my answer is it depends. These factors need to be taken into account: who are the user groups, do you require different EHR access control on the EHR data from different EHR systems, and is there a master patient identifier index available The logical meaning of importing EHR is absolutely different from the EHRs in "cloud / co-tenanted / SaaS" environments. In general, one organisation would have its' own base policies on EHR access control. The logical meaning of importing EHR is relocating an external EHR, so it would not require a different EHR system id. While cloud/co-tenanted/SaaS may require different EHR system ids. It depends on the requirements and the system design. Having multiple system ids might be easier for access control. In the co-tenanted/SaaS environment, users might be different from organisation to organisation. You may not want the users (clinicians) of one organisation/hospital be able to access the patient EHR data belonged to another organisation/hospital. The access control might be easily done using EHR system ids. In the use case of adding an openEHR CDR to the national Cancer research platform, the users of the research platform might be the same, so it makes sense to use the same EHR system id for all EHRs. EHR system ids are important to the orgranisations, while EHR/EHR_STATUS are important in linking the patient's demographic information. When changes are done to EHR ids, need to make sure not break the linkage between the EHR and the patient's demographic information. --- ## Post #27 by @sebastian.iancu Good points @chunlan.ma - it looks like the short conclusion is that "it depends on the needs and implementation", isn't it? This whole thread reminds me on an earlier discussion/topic I opened few years ago in SEC, about AQL not having any obvious "support" for `system_id`: - If you would have EHRs with different `system_id` on same server, how can you query data on a subset of EHR "under" a `system_id`? - Should a query not "mentioning" the `system_id` executed on all EHRs on that server, despite their owner system? --- ## Post #28 by @chunlan.ma Hi @sebastian.iancu , I won't specify system_id in AQL query. AQL query should be used for EHR data, but system_id is not part of EHR data. system_id would be specified as part of the APIs. --- ## Post #29 by @rx2 If one or more objects are imported into an existing EHR, they are entered as a new version. The version class contains information about which UID the previous system has of the object. The UID contains information about which system created the uid. See OBJECT_VERSION_ID Class. Since the version class contains preceding_version_uid, we can derive from which system the object was imported from. https://specifications.openehr.org/releases/RM/latest/common.html#_version_class So the answer should be no, as the ehr id and its system id is always unique within each EHR system. But in the version class, we can see where the object comes from (system id). What I find difficult to keep apart are all the different classes and how they connect together. This makes it difficult to get an overview, especially in theory. At the company eWeave, we have worked for a long time with the various models and today have a fully operable system that we named eWeave Core where we can really evaluate EHR and demographic models. Enter different archetypes, archetype templates and forms both from the demographic and EHR-based openEHR world and see how these work in practical terms. --- ## Post #30 by @thomas.beale [quote="rx2, post:29, topic:3535"] What I find difficult to keep apart are all the different classes and how they connect together. This makes it difficult to get an overview, especially in theory [/quote] The [Architecture Overview](https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html) ad [Archetype Overview](https://specifications.openehr.org/releases/AM/latest/Overview.html) docs should help there. EDIT: reading your website, you must already know about these documents... would be helpful to know what we should do better in terms of explaining things better. --- ## Post #31 by @sebastian.iancu [quote="chunlan.ma, post:28, topic:3535"] AQL query should be used for EHR data, but system_id is not part of EHR data. system_id would be specified as part of the APIs. [/quote] I agree partially. Indeed in some use-cases a physical system may contain several system_id inside, and it may be seen as a single logical system (i.e. the organisation). But what if a physical system (a 'server') is used as multi-tenant, where each tenant has his own system_id, and you would like to either query in specific system, or only query across systems? In this case a 'system' would act as parent container for EHRs. I'm curios @chunlan.ma why should then not be considered in AQL. Also, what would be the 'parent' container if you would use AQL to query in Demographic RM side for PARTY - as it is certainly not the EHR (you cannot `SELECT ... FROM EHR ... CONTAINS PERSON ...`) ? It may seem unrelated to original question on this topic, but I think we miss in openEHR the concept of a higher SYSTEM class, and we only use here and there an obscure 'system_id' attribute, which we have can hardly regulate. --- ## Post #32 by @thomas.beale [quote="sebastian.iancu, post:31, topic:3535"] each tenant has his own system_id, and you would like to either query in specific system, or only query across systems? In this case a ‘system’ would act as parent container for EHRs [/quote] I would argue that this is always what a 'system' is for the purposes of openEHR. The actual system, i.e. servers in the data centre that act as a logical substrate (DB, security etc) for all contained tenants is not a 'system' from the EHR point of view, it's infrastructure. Hence my suggestion that we equate 'system' in the openEHR sense to EHR repository of an organisation. [quote="sebastian.iancu, post:31, topic:3535"] It may seem unrelated to original question on this topic, but I think we miss in openEHR the concept of a higher SYSTEM class, and we only use here and there an obscure ‘system_id’ attribute, which we have can hardly regulate [/quote] Agree. --- ## Post #33 by @chunlan.ma [quote="rx2, post:29, topic:3535"] What I find difficult to keep apart are all the different classes and how they connect together. This makes it difficult to get an overview, especially in theory. [/quote] Would be very interesting to know some of the difficulties you had on the journey. --- ## Post #34 by @chunlan.ma [quote="sebastian.iancu, post:31, topic:3535"] But what if a physical system (a ‘server’) is used as multi-tenant, where each tenant has his own system_id, and you would like to either query in specific system, or only query across systems? In this case a ‘system’ would act as parent container for EHRs. I’m curios @chunlan.ma why should then not be considered in AQL. Also, what would be the ‘parent’ container if you would use AQL to query in Demographic RM side for PARTY - as it is certainly not the EHR (you cannot `SELECT ... FROM EHR ... CONTAINS PERSON ...`) ? [/quote] This is a very interesting question, especially thinking of including demographic data as part of the system. In theory, I agree that patient's demographic information and EHR data should be part of the system (regardless of the individual design). AQL is a language driven by archetypes. My initial thought is that AQL is used for querying EHR data, that's why the root class is EHR. OpenEHR doesn't have a System class anyway. If you do want to specify the system id in AQL, it can be easily done by: FROM EHR e[system_id='xxx'], or FROM EHR e WHERE e/system_id='xxx' I can see the benefits of including system_id criteria as part of the AQL in some situations, such as the scenario you mentioned. --- ## Post #35 by @sebastian.iancu [quote="chunlan.ma, post:34, topic:3535"] AQL is a language driven by archetypes. [/quote] Indeed, and the openEHR Demographic side is also driven by archetypes, some old v0 still present on CKM. I don't see any issue with AQL side on this aspect. [quote="chunlan.ma, post:34, topic:3535"] My initial thought is that AQL is used for querying EHR data, that’s why the root class is EHR. OpenEHR doesn’t have a System class anyway. [/quote] This is what I am debating about. I don't think EHR should be the root-class, but a SYSTEM class, which we don't have right now. [quote="chunlan.ma, post:34, topic:3535"] FROM EHR e[system_id=‘xxx’], or FROM EHR e WHERE e/system_id=‘xxx’ [/quote] Yes indeed, that should work. But I was up for the other one with a system, also because I would like to query for PARTY objects. A while ago I tried to write a sketch on how should it be - see https://openehr.atlassian.net/wiki/spaces/spec/pages/1916796933/Demographic+RM+usage. --- ## Post #36 by @thomas.beale [quote="sebastian.iancu, post:35, topic:3535"] This is what I am debating about. I don’t think EHR should be the root-class, but a SYSTEM class, which we don’t have right now. [/quote] I.e. a 'virtual EHR system' concept not just a 'virtual EHR' concept. We should definitely talk about it. --- ## Post #37 by @erik.sundvall Perhaps we should use/start a separate thread for the discussion about a top 'SYSTEM' hierarchy level that includes both EHR and Demographic/Registry parts? That thread could also discuss the suitability/problems of using AQL for querying meshes/graphs rather than trees. Perhaps some Archetype-based sytactic sugar on top of [GQL](https://en.wikipedia.org/wiki/Graph_Query_Language) (AGQL?) and sugar-resolving query preprocessing would do the trick... Is there a suitable thread to continue in or does somebody want to create one? [Update: In april 2024 GQL was approved as an ISO standard, some info that is not paywalled by ISO can be found in Olof Morra's Publication [A Semantics of GQL; a New Query Language forProperty Graphs Formalized.pdf](https://github.com/OlofMorra/GQL-parser/blob/main/src/main/resources/report/A%20Semantics%20of%20GQL;%20a%20New%20Query%20Language%20forProperty%20Graphs%20Formalized.pdf) that is part of the site [https://github.com/OlofMorra/GQL-parser](https://github.com/OlofMorra/GQL-parser)] --- ## Post #38 by @pablo IMHO the syntax doesn't matter too much. The most important thing is to define the process of querying on top of your data structure, which is basically defining the requirement first and then design how it should work, and just then do the syntax thing. This is a historical problem of the AQL spec: authors focus too much on the syntax and not on the definition of the querying process. --- ## Post #39 by @erik.sundvall @pablo, the thought behind basing querying on e.g. GQL would be exactly to "define the process of querying on top of your data structure" in a non-ambiguous manner made for property graphs (like openEHR's object instance graphs). (The syntactic sugar suggestion is just to make it at least as convenient as AQL for querying archetyped data.) GQL also has the benefits of not being invented or maintained by openEHR. --- ## Post #40 by @pablo Thanks for the clarification @erik.sundvall my comment was because we often discuss syntax and not process/operation/flow execution, and then everyone implements the same thing in different ways. I don't know much about GQL, if you are working with it, what do you think about providing a small workshop for the SEC? I do think openEHR needs a hierarchical query "model" (not a "language") spec, then we could have a syntax on top of that model for exchange purposes that makes sense with a hierarchical underlying information model, unlike the SQL-likeness of AQL. I we have a query model, we can even use archetypes to represent specific queries (we can archetype the query model). --- **Canonical:** https://discourse.openehr.org/t/ehrs-with-different-system-id-in-the-same-server/3535 **Original content:** https://discourse.openehr.org/t/ehrs-with-different-system-id-in-the-same-server/3535