Regarding update encounter workflow in SHR

Hi All,

I have a query for the group:

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?

Regards,
Unnat
Unnat GuptaSenior Consultant
Email
unnatg@thoughtworks.com

Telephone
+91 976 444 9246

ThoughtWorks

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.

Cheers,

Ryan

···

On Fri, Aug 1, 2014 at 3:24 PM, Unnat Gupta unnatg@thoughtworks.com wrote:

Hi All,

I have a query for the group:

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?

Regards,
Unnat
Unnat GuptaSenior Consultant
Email
unnatg@thoughtworks.com

Telephone
+91 976 444 9246

ThoughtWorks

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org

Thanks Ryan.

···

Regards,
Unnat
Unnat GuptaSenior Consultant
Email
unnatg@thoughtworks.com

Telephone
+91 976 444 9246

ThoughtWorks

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.

Cheers,

Ryan

On Fri, Aug 1, 2014 at 3:24 PM, Unnat Gupta unnatg@thoughtworks.com wrote:

Hi All,

I have a query for the group:

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?

Regards,
Unnat
Unnat GuptaSenior Consultant
Email
unnatg@thoughtworks.com

Telephone
+91 976 444 9246

ThoughtWorks

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton

E-mail: ryan@jembi.org

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.

  1. 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

  2. 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.

  3. 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.

Cheers,

Ryan

On Fri, Aug 1, 2014 at 3:24 PM, Unnat Gupta unn...@thoughtworks.com wrote:

Hi All,

I have a query for the group:

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?

Regards,
Unnat
Unnat GuptaSenior Consultant
Email
unn...@thoughtworks.com

Telephone
+91 976 444 9246

You received this message because you are subscribed to the Google Groups “Interoperability Layer (OpenHIE)” group.

To unsubscribe from this group and stop receiving emails from it, send an email to openhie-interoperability-layer+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.


Ryan Crichton

Lead Developer, Jembi Health Systems | SOUTH AFRICA

Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ry...@jembi.org