Currently the openEHR Common model supports Contributions whose contents may be Compositions from other systems. However, it does not cleanly support the synchronisation of Contributions from one system to another, such that the source systems and Contributions can be identified (there no problem in applying the content of a remote Contribution to a target system, just in identifying the originating Contribution).
In a distributed, caching EHR computing environment, these semantics would be needed, in a similar way to synchronisation of change-sets between instances of software configuration management software such as Subversion or BitKeeper.
A version identification system is also needed to support globally unique identification of versions in such a way that clashes are avoided when copies, moves and merges are made.
Various anomalies in the existing models can be fixed by a proper version identification scheme:
demographic model - PARTY.reverse_relationships cannot just be a uid
referencing of CONTRIBUTION from VERSION and vice-versa
how a DV_EHR_URI relates to the various identifiers
Currently the openEHR Common model supports Contributions whose
contents may be Compositions from other systems. However, it does
not cleanly support the synchronisation of Contributions from one
system to another, such that the source systems and Contributions
can be identified (there no problem in applying the content of a
remote Contribution to a target system, just in identifying the
originating Contribution).
In a distributed, caching EHR computing environment, these semantics
would be needed, in a similar way to synchronisation of change-sets
between instances of software configuration management software such
as Subversion or BitKeeper.
A version identification system is also needed to support globally
unique identification of versions in such a way that clashes are
avoided when copies, moves and merges are made.
Various anomalies in the existing models can be fixed by a proper
version identification scheme:
demographic model - PARTY.reverse_relationships cannot just be
a uid
referencing of CONTRIBUTION from VERSION and vice-versa
how a DV_EHR_URI relates to the various identifiers