I would like your help to understand the workflow when a Hospital systems updates an existing encounter (which was already synced with SHR) and sends it again to SHR? Does SHR identifies it as a duplicate and reject it or it updates the encounter in SHR?
In the current SHR that is in use in Rwanda there isn’t a mechanism to update an encounter that the SHR supports. Although, at the moment within OpenHIE we have decided to rather make use of the XDS.b interface standard to send encounter (in the form of documents) into the SHR. In this case I believe to update an encounter one would send a new document that is marked as a replacement of an older document. In this way encounters could be updated while still keep a full revision history. We are working on developing a SHR reference application that support this interface but this isn’t very far along at the moment. Other options would be to use the some of the existing open source XDS.b registries and repositories. Such as OpenXDS, HIEOS or dmc4chee.
I would like your help to understand the workflow when a Hospital systems updates an existing encounter (which was already synced with SHR) and sends it again to SHR? Does SHR identifies it as a duplicate and reject it or it updates the encounter in SHR?
On Mon, Aug 4, 2014 at 3:15 PM, Ryan Crichton ryan@jembi.org wrote:
Hi Unnat,
In the current SHR that is in use in Rwanda there isn’t a mechanism to update an encounter that the SHR supports. Although, at the moment within OpenHIE we have decided to rather make use of the XDS.b interface standard to send encounter (in the form of documents) into the SHR. In this case I believe to update an encounter one would send a new document that is marked as a replacement of an older document. In this way encounters could be updated while still keep a full revision history. We are working on developing a SHR reference application that support this interface but this isn’t very far along at the moment. Other options would be to use the some of the existing open source XDS.b registries and repositories. Such as OpenXDS, HIEOS or dmc4chee.
I would like your help to understand the workflow when a Hospital systems updates an existing encounter (which was already synced with SHR) and sends it again to SHR? Does SHR identifies it as a duplicate and reject it or it updates the encounter in SHR?
Also, to clarify on the discrete data side. There are several ways to do this in CDA which are supported by the OpenSHR CDA handler.
CDA Documents carrying a document relationship of RPLC (replace) pointing to an older version will result in the replaced document’s information being voided and then new data being recorded (i.e. this entire document replaces that entire other document). Each document has a unique ID
CDA document carrying a document relationship of APND (append) pointing to an older version will result in a new encounter within the visit (created by the original document) being added.
There is a well documented way of replacing/appending data in sections and entries. This entry level replacement is currently supported in the OpenSHR code however the section level mechanism is not currently supported (will be soon I hope). Basically on each entry you would append a which would reference the old act being replaced. PCC TF-2: 6.3.1.6.7 explains the entry replacement.
Other than that if you try to store a document/section/entry with the same ID you’ll get a discrete data import error (a collision) as you need to explicitly state whether a section/entry/document is a replacement.
Ryan is also correct at the transport level as well. Sending an XDS replacement should result in a replace operation for the document. Basically you assign a new identifier to the document / submission sets and relate them to the previous version with the relationship association having RPLC or APND as the
Cheers
-Justin
···
On Monday, August 4, 2014 5:45:46 AM UTC-4, Ryan Crichton wrote:
Hi Unnat,
In the current SHR that is in use in Rwanda there isn’t a mechanism to update an encounter that the SHR supports. Although, at the moment within OpenHIE we have decided to rather make use of the XDS.b interface standard to send encounter (in the form of documents) into the SHR. In this case I believe to update an encounter one would send a new document that is marked as a replacement of an older document. In this way encounters could be updated while still keep a full revision history. We are working on developing a SHR reference application that support this interface but this isn’t very far along at the moment. Other options would be to use the some of the existing open source XDS.b registries and repositories. Such as OpenXDS, HIEOS or dmc4chee.
I would like your help to understand the workflow when a Hospital systems updates an existing encounter (which was already synced with SHR) and sends it again to SHR? Does SHR identifies it as a duplicate and reject it or it updates the encounter in SHR?