3 ms·

Yes. In E-Health you have to be able say who and what was queried for. There's also https://en.wikipedia.org/wiki/Reliable_messaging https://en.wikipedia.org/wi

Yes. In E-Health you have to be able say who and what was queried for. There's also https://en.wikipedia.org/wiki/Reliable_messaging https://en.wikipedia.org/wiki/Reliable_messaging We store every message and every response so you can tell what query was run and when.

dogma1138 8y ago
You are confusing two concepts under HIPAA you are explicitly disallowed to log any EHR information. Record systems must be able to represent the exact EHR presented to a query e.g. to check if there was a human error like some one missreading the record. This is achieved by keeping record versions and a record history this isn’t achieved by having system logs and audit trails of queries returned. Essentially your EHR system would work like git you’ll be able to query the same commit as the original query but it doesn’t mean that your database audit trail would record any parts of the electronic health record that is simply not allowed.
- mberger 8y ago
  We're Canadian so don't fall under HIPAA. We record in a database the full request and response for each transaction submitted. We index with the UUID for the message. With that request and response I can tell you exactly what each query returned because we only return the data that goes in the message. I can't tell you what the database contained at that point but I know what is in the message.
  - saltcured 8y ago
    The approach you are describing seems to extend the same access protection and audit requirements to the audit logs themselves. Otherwise, you have created a covert channel to access the private content by examining these logs rather than the original database. The other approach, of being able to replay a historical query described in a log while disallowing the private content in the logs allows the audit logs to be stored in a way that can be biased for better storage durability, without quite the same recursive audit nightmare. The logs are much smaller and can be easily replicated and archived, without quite the same level of risk from exposure of log content. Not to say those other logs are not also worth protecting, but there are different ways to balance the risks and costs...

dogma1138 8y ago

You are confusing two concepts under HIPAA you are explicitly disallowed to log any EHR information. Record systems must be able to represent the exact EHR presented to a query e.g. to check if there was a human error like some one missreading the record. This is achieved by keeping record versions and a record history this isn’t achieved by having system logs and audit trails of queries returned. Essentially your EHR system would work like git you’ll be able to query the same commit as the original query but it doesn’t mean that your database audit trail would record any parts of the electronic health record that is simply not allowed.

mberger 8y ago
We're Canadian so don't fall under HIPAA. We record in a database the full request and response for each transaction submitted. We index with the UUID for the message. With that request and response I can tell you exactly what each query returned because we only return the data that goes in the message. I can't tell you what the database contained at that point but I know what is in the message.
- saltcured 8y ago
  The approach you are describing seems to extend the same access protection and audit requirements to the audit logs themselves. Otherwise, you have created a covert channel to access the private content by examining these logs rather than the original database. The other approach, of being able to replay a historical query described in a log while disallowing the private content in the logs allows the audit logs to be stored in a way that can be biased for better storage durability, without quite the same recursive audit nightmare. The logs are much smaller and can be easily replicated and archived, without quite the same level of risk from exposure of log content. Not to say those other logs are not also worth protecting, but there are different ways to balance the risks and costs...