Can a single CONTRIBUTION ever affect two separate EHRs?
I understand that a CONTRIBUTION normally only affects a set of
VERSIONED_OBJECTs within a single EHR, but are there any exceptions?
Technically the class CONTRIBUTION can point to any OBJECT_REF, but
what should be allowed for real?
A possible use case could be when moving some compositions between
records (e.g. due to entry mistakes or temporary records for
unidentified patients). Then one could either create a single
CONTRIBUTION describing the move or two CONTRIBUTIONs: one in the
source record indicating deletion and one in the source record
indicating addition.
I guess the last one (creatinig two CONTRIBUTIONs) is the preferred
one, but I just want to be sure if the first case is ever allowed.
Best regards,
Erik Sundvall
erik.sundvall@liu.se http://www.imt.liu.se/~erisu/ Tel: +46-13-286733
(Mail & tel. recently changed, so please update your contact lists.)
in principle your reasoning is correct, and we could solve merge & demerge problems with some kind of uber-Contribution. However, at the moment the formal modelling only allows for Contributions to be associated with single EHRs. One of the reasons is that EHRs could be separated, due to decease, archiving, one patient moving etc, so a cross-EHR Contribution would then be broken up in some way. I think that at a practical level the correct approach is simply to ensure that certain kinds of updates are handled at the database transaction layer, i.e. either they succeed or they are rolled back. In any case, if health data for person A is found in person B’s record, that has to be removed ASAP, and regardless of whether it could be added to A’s record at the same time or not…
I had the same question a while back for the same use case. I could not find anything in the specifications/models that indicates that contributions are restricted to a single EHR, as Erik says contributions can be associated with any VERSION OBJECT_REFs. I think this topic needs to be discussed further and clarified in the specifications. For the record, the Ocean EHR Server currently requires two contributions.
If we compare the EHR repository with a SVN repository, SVN allows us to commit movements of data from one folder to another to ensure integrity of repository content at any point of time and an audit trail of the operations performed to the repository. I see moving data from one EHR to another within the same repository as a similar operation and if we need to do this in two contributions then the integrity of the EHR repository is compromised and lacks the audit tracing of the move operation.
The order of the add and delete contributions will change the way the repository looks like between the two contributions, if we add the items to the target EHR before deleting them from the source we actually have duplicates of the same data, potentially affecting population queries at this intermediate state. Deleting the items from the source EHR before adding them to the target has the opposite affect but perhaps not quite as problematic. Allowing this to happen in a single contribution avoids this intermediate state and provides a better audit trace of the operation.
The other issue I found with this use case was the need to create new version UIDs for the compositions in the target EHR contribution due to the need for the source compositions to be retained and marked as deleted. This would be required no matter if this was done as 1 or 2 contributions due to the add/delete nature of the operation.
If we had a specific move operation, we could physically move the existing VERSIONED_OBJECT to the target EHR, but we would need to ensure that the repository still reflected the fact that the VERSIONED_OBJECT was part of the source EHR prior to the move contribution. This would be difficult to represent because the VERSIONED_OBJECT.owner_id would need to be changed to the target EHR as part of the move operation, which breaks the versioning model and has no means to record the fact that it used to be part of the source EHR.
I think we need some implementation guidance on this Use Case, the Wiki is probably a reasonable place to do this for now.
