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.
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.
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.
Yes, this is a good note and, as you imply, is use case dependent. Real examples being explored:
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.)
When adding an openEHR CDR to the national Cancer research platform 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)
I think is more than “use case dependent” it depends organizational structures, agreements and local/international legislation. I would call this “environment dependent”.
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.
One London Universal Care plan - single CDR instance - subjectID is the ‘universal’ (almost!) NHS Number, unique ehr_id for that CDR
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?
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 (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?