Hi Ryan.
Only messages that are “putting” content to the HIE will need the traceability and, because this is such an important requirement, IHE’s ATNA log specs for those messages and the XDS repository requirements all make mandatory the doc ID tracking.
For all IHE messages where ATNA is mandatory there are strict specifications about what shall be in the audit log. ATNA is not mandatory for CSD messages because they are query only; this is true for many query-only profiles. That said, it is common practice to audit all message traffic… but the content of the log is not stipulated by IHE.
As a takeaway message: the required ATNA log content is stipulated for all IHE profiles that are submitting protected health information (PHI) to the HIE.
I hope this helps.
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
···
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.
From: Ryan Crichton [mailto:ryan@jembi.org]
Sent: Tuesday, June 17, 2014 6:07 AM
To: Derek Ritz (ecGroup)
Cc: Hannes Venter; openhie-interoperability-layer@googlegroups.com
Subject: Re: Linking transactions to registry records
Hi,
Thanks Derek and Hannes. So, it seem that for encounter data (CDA documents) we would want to store the associated uniqueID for each document as well as use the standard ATNA auditing to store audit logs.
However, we are not only transmitting encounter data through the HIE, there are various other message that we need to consider as well. Such as, PIX/PDQ and CSD messages. I’d imagine each has their own auditing requirements and we should use those. I’d think in general through we would want to store any unique identifier that are produced for those messages in the IL and require registry systems to reference this ID when changes are effected. I believe PIX and PDQ message have a unique ID however I’m not sure on CSD message?
So in summary:
-
I don’t think we should have a common way to store a transaction ID for all message
-
The IL mediators will extract and store unique message IDs for different message types as part of the transaction metadata.
-
Normal auditing requirements will be followed.
-
The registries must store a reference to the unique ID with a relationship to the data that was changed by that transaction.
Does this make sense to others?
Cheers,
Ryan
On Fri, Jun 13, 2014 at 2:10 PM, Derek Ritz (ecGroup) derek.ritz@ecgroupinc.com wrote:
Hi all.
I strongly favour having the POC generate a GUID and assign it to the outbound transmission. There are many simple, open source components which may be leveraged to do this and it represents “best practice”. Although it may not be something our POC is doing today, it is also best practice for the POC to maintain a local audit log of transmissions that have been submitted to the HIE. Without such a local audit log, it is practically impossible for a POC to “update” content that was sent previously to the HIE – and this is a common (and important) use case.
On the HIE side, it is the responsibility of the IL to persist the transaction ID in the audit log (see the XDS.b specs in IHE-ITI-TF-2b pages 143 and following). Likewise, the XDS registry and repository persist this ID. It will be a challenge for an SHR to be able to associate discrete data elements in an RDBMS with the transaction ID that is their source… but that is the last filament of this golden thread and it is a challenge our SHR will have to rise to.
For OpenHIE, the traceability of XDS.b submission sets is highly prescriptive and this, happily, means there is not really much room for discussion. To be conformant with IHE technical framework, we must follow the specifications. For RHEA, I think we need to determine how we will move along the path from where we are now to where we will need to be in order to be able to align with OpenHIE’s XDS.b-centric message exchange formats.
I would advocate for making the necessary software changes at the POC (the OpenMRS client) to enable GUIDs to be assigned to outbound transmissions. These software updates are needed in order for OpenMRS to work with OpenHIE anyway. At the same time, this approach provides us a way to solve our traceability issue on the RHEA implementation and sets the table for an eventual refresh of the HIE stack in Rwanda to the “new” OpenHIE transaction formats if/when that day comes.
Warmest regards,
Derek.
Derek Ritz, P.Eng., CPHIMS-CA
ecGroup Inc.
+1 (905) 515-0045
www.ecgroupinc.com
This communication is intended only for the party to whom it is addressed, and may contain information which is privileged or confidential. Any other delivery, distribution, copying or disclosure is strictly prohibited and is not a waiver of privilege or confidentiality. If you have received this telecommunication in error, please notify the sender immediately by return electronic mail and destroy the message and any attachments.
Le présent courriel et les documents qui y sont joints sont confidentiels et protégés et s’adressent exclusivement au destinataire mentionné ci-dessus. L’expéditeur ne renonce pas aux droits et privilèges qui s’y rapportent ni à leur caractère confidentiel. Toute prise de connaissance, diffusion, utilisation ou reproduction de ce message ou des documents qui y sont joints, ainsi que des renseignements que chacun contient, par une personne autre que le destinataire prévu est interdite. Si vous recevez ce courriel par erreur, veuillez le détruire immédiatement et m’en informer.
From: openhie-interoperability-layer@googlegroups.com [mailto:openhie-interoperability-layer@googlegroups.com] On Behalf Of Hannes Venter
Sent: Friday, June 13, 2014 7:08 AM
To: Ryan Crichton
Cc: openhie-interoperability-layer@googlegroups.com
Subject: Re: Linking transactions to registry records
Hi Ryan,
With regards to encounter data, CDA requires one to generate an unique identifier for that document. This uniqueId is also propagated in the XDS metadata.
I think this is the best field then to use as a “go-to” for any auditing.
Perhaps a good approach in the IL then would be to add the uniqueId to the transaction’s metadata?
I know in the new OpenHIM we have provision for “properties”, we could have the save encounter mediator setup the uniqueId as a property?
Cheers
Hannes
On 13 June 2014 10:32, Ryan Crichton ryan@jembi.org wrote:
Hi all,
Something that has come out the Rwandan HIE is the need to link transactions in the IL to actual records that were created in the registries. For example, we would like to be able to follow a patient’s encounter data in the SHR back to the transaction that added or effected change in the SHR.
Here are a few way to do this:
-
We could use some form of transaction identifier that the IL assigns and have the IL pass this identifier on to the registries so they can store this along side the record.
-
There is also the option of trying to generate a natural key from item in the metadata of transaction to make up this identifier.
-
Another option may be to rather use an audit service that links a transaction to a specific record in the registries.
What do others think is the best mechanism for us to linking/audit these records?
@Suranga, I know you have been thinking about this for the Rwandan HIE. Do you have some thoughts on ways in which this can be done?
Cheers,
Ryan
–
Ryan Crichton
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org
–
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.
–
Hannes Venter
Senior Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27 73 276 2848 | Office: +27 21 701 0939 | Skype: venter.johannes
E-mail: hannes@jembi.org
–
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
Software Developer, Jembi Health Systems | SOUTH AFRICA
Mobile: +27845829934 | Skype: ryan.graham.crichton
E-mail: ryan@jembi.org