The EHR root object has a system_id attribute defined in EHR Information Model 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.
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).
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.
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.
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.
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.
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.
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.
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.
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?
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?
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.
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?
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.)
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?
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.