EHR system_id needs clarification in copy/move scenario


Section 4.4 of EHR RM spec talks about EHR creation in two scenarios, one being where an existing ehr_id is used from another system. It is not clear what the system_id should be in this case.
It may seem obvious to make it the original systems system_id, but this may cause issues within the new system and global indexing of the EHR.




Pablo Pazos
June 30, 2015, 1:51 AM

Maybe would help to have attributes to say that the EHR was copied from another system and a local_system_id to set the local system id.
If the EHR is copied several times from/to different systems, maybe we need something like AUDIT_DETAILS for EHRs.

Thomas Beale
October 27, 2015, 2:47 PM

The original intention was that EHR.system_id would always be the id of the local system, even in the clone/copy scenario. The documentation is not clear enough on this.

Pablo has a point - do we want additionally for an EHR to be able to indicate more clearly that a) it is a copy of an existing EHR and b) to point to the original system owning the original EHR?

Sebastian Iancu
October 27, 2015, 10:24 PM

It is not really necessary to add extra fields, we managed to record merge/move by using EHR_STATUS.other_details and DV_EHR_URIs (with system_id and source ehr_id) to record such meta-data.

Heath Frankel
October 27, 2015, 11:02 PM

I am not sure that the concept of the creating system id helps in this scenario. My understanding of this scenario is a distributed EHR within some domain of systems and I don't think it really matters who created it, it may not even be a system that generates the EHR ID, it could be a registery of sorts.

The key concern around the system id is that it is unclear that the system is the EHR server and not some client app. Even the use of words such as "local system" doesn't help this.


Heath Frankel




Affects versions